ASA 5510: Access rules, user error/confusion

Loxmyth · ‎08-13-2023

This seems to be a perennial problem...

I have had the ASA-5510 running pretty well for a year or two, configured to simply segregate traffic by security level of the Interface:

Management0/0, security level 100: "management", can open connections to all other interfaces/subnets (attached to the mgmt port, but not set to forbid anything but management). Address set via DHCP client.
Ethernet0/0, security level 0: "outside", can not open connection to anything (though eventually I intend to allow outside to reach DMZ). Address hardwired, attached systems' addresses set via DHCP server.
Ethernet 0/1, security level 90: "inside", development, can open connections to machines on the public or DMZ interfaces . Address hardwired, attached systems' addresses set via DHCP server.
Ethernet 0/2, security level 10: "DMZ", can only open connections to outside. (Web/mail servers, eventually). Address hardwired, attached systems' addresses set via DHCP server.
Ethernet 0/3, security level 50: "public", can only open connections to outside. (Production, printers, etc.) Address hardwired, attached systems' addresses set via DHCP server.

Unfortunately I had to

reconfigure

the network from 193. addresses to 172. addresses, due to hardwired address limits in a tool. (Sigh.) So local addresses on inside, public, and DMZ are now 172.17.i.xxx, where i is the interface number for that subnet and xxx is the individual machine's address within that range.

Should be straightforward, right? This is an absolutely canonical security-level-based firewall setup. But I've somehow messed it up again. All my local subnets can reach public servers just fine, but they can't talk to each other. From anywhere in my system I can ping, http(s), and otherwise reach machines on the Internet (connected to interface 0, outside), but I can't

ping, ssh

or otherwise connect to machines on one of my subnets from the subnet attached to a higher-security interface.

My access rules currently are as shown here. Yes, I know this doesn't explicitly mention icmp; I hadn't needed traceroute often and windows ping defaults to TCP based.

That's basically the

default setup

. And you'd expect "Any less secure network" to mean what it says, not "only the least secure network".

So I've botched something, and once again I'm honestly not sure what. I *thought* I understood the 5510's basic firewall behavior...

If someone could look at my configuration and tell me which of my own feet I've shot off to produce this "only to outside" behavior, I'd greatly appreciate it!

---

Loxmyth · ‎08-14-2023

Part of what's confusing me is that the

default ACLs

,

any, any less secure, permit, define any less secure as all of the following less secure networks

, such as

public:any,DMZ:any,outside:any

. But my connectivity to outside is working, and connectivity to public isn't.

Yet if I replace that with

any, outside, permit

, I _lose_ the connectivity to outside.

Assuming that the ACL isn't lying to me, what could affect connectivity other than the ACL? Network address translation, given that all these subnets are using a 255.255.255.0 mask? Proxy ARP? I'm really running out of ideas to try.

"It happened once. Therefore it must be possible."

Loxmyth · ‎08-14-2023

Workaround, though see response below...

I had a

NAT

rule in place for the outside network, which is why everyone could communicate outside.

When I added one for public, suddenly I could

ping and ssh

to machines on public.

This makes perfect sense in retrospect, but was NOT obvious and is not well documented. Everyone kept saying "it must be an ACL problem"... but no, the ACL was working fine, packets were moving across but they needed

NAT

before they could be recognized and responded to.

Hope this saves someone else a week of bashing their head against the wall!

Loxmyth · ‎08-15-2023

I am told "NAT is not an unreasonable workaround, but not how the Cool Kids do it. The ACLs should be enough on their own."

Well, I agree, but something is keeping that from working as expected and I still haven't found what.

I have had one person swear that he tried my 5510 profile on his 5540 and it worked as intended without the NAT. The only guess I've got is that when he loaded it, he loaded it over his existing configuration, and thus inherited something my own ACLs-only profile forgot to set. We're trying to determine whether there really is a difference in what we're running that he isn't aware of, or if my 5510 config is actually working properly and there's something else wrong with my environment.

"Such a smart piece of equipment, and a wreck like me trying to run it." -- Frances Sternhagen, as Doctor Lazarus in Outland

Loxmyth · ‎08-17-2023

More followup: Some suggested that my problem was actually the Windows firewalls. So I tried Linux on both subnets, and had the same problem; without NAT I couldn't reach from one to the other.

Running out of ideas to try other than to investigate whether if I'm pushing something unreasonable out on dhcp. Or to slap a packet-tracer on the problem and see if I can get that to tell me where the connection fails.

This really should be an Absolutely Stock Usage Example. We're all really confused that it isn't working.