ASA: 8.3 Unusable?

[holzerb]

I have SERIOUS issues with the latest ASA software version 8.3.  I have successfully implemented it on testbed ASAs and discovered what I consider to be inherent design flaws.  Upgrading our operational ASAs was so troublesome, I downgraded.

- Migration removes all "remarks" from ACLs.  Unacceptible.

- Requiring Objects is a security risk.  We have a policy to avoid objects whenever possible, especially when multiple engineers manage a device.  With 8.3 we are forced to use them.

- I don't undertand the logic in removing NAT exemption (nat 0).  If we migrate one of our production ASAs, the few ACLs and NAT 0 command get translated into pages of nat commands that don't make sense.  It should at least be downward compatible, maybe with a deprecation message that one can ignore.

- Access lists using real IPs instead of translated IPs is a security risk and totally inflexible.  For security, ACLs should NOT use real IPs (10.1.1.1, in the example below) if the connections are being made to translated ones (1.2.3.4).

- Debugging/troubleshooting is next to impossible in 8.3:

What was:

  static (inside,outside) tcp 1.2.3.4 2222 10.1.1.1 22 netmask 255.255.255.255

  access-list outside-acl permit tcp any host 1.2.3.4 eq 2222

is now:

  object network obj-myserver

    host 10.1.1.1

    nat (inside,outside) static 1.2.3.4 service tcp 22 2222

  access-list outside-acl permit tcp any obj-myserver eq 22

Note that blocked incoming connections to port 2222 with version 8.3 are being logged with port 22.  What if one views a log for hundreds of servers each listening on a port but mapped to different external ports?  Before, one could grep for the relevant external port.

Let's troubleshoot: to see our object from above, execute:

  show run object id obj-myserver

and one would see:

  object network obj-myserver

    host 10.1.1.1

Where is the nat line related to that object???

Try:

  show run nat | begin myserver

to see:

  object network obj-myserver

    nat (inside,outside) static 1.2.3.4 service tcp 22 2222

Yep, even though they are entered together and are related, they are broken out in the running config - one grouped at the top and one grouped below the NAT commands.

And this is what I've found in only a day of testing.  Where am I possibly going to find the time to migrate all of our production ASAs to the new code, assuming I should?  Huge disappointment, but at least one doesn't have to enter "do" in front of every command, yet...

[b.julin]

Since we don't use our ASAs for NAT anymore, most of that doesn't really concern me where I work.

But I do share your concern for the "real addresses in ACLs" issue.  It has been that way for VPN pool

addresses since before 8.3 -- any VPN client needs access rules in the ACLs on the ISAKMP

interface using it's pool address.  This leaves you completely unable to see whether misconfigured

or malicious packets are entering the actual wire with these source addresses.  That means you need

additional firewall devices between your ASAs and your ISP links just to ensure sanity, if you are

in a paranoid environment.  Suckage.

(Not that the ACL counters/logging work in more than half the places you use ACLs anyway)

...and of course the documentation is never adequately explicit as to what happens when that occurs.

And even if it was, you'd then have to decide whether you can trust the documentation, which itself

can be a dicey prospect these days, considering how things change.  You'd have to have an FTE

dedicated to building a test suite to thoroughly ensure all possible ickiness gets dealt with properly

by each and every software revision to responsibly deploy and maintain this gear with untrusted peers.

Then there's the lovely "sysopt connection permit-vpn" setting which the documentation seems to

say is a single switch that allows the ISAKMP service and other IPSEC stuff to not require an ACL

entry, and also at the same time keeps the untunnelled traffic from going through the abovementioned

ACL.  Putting both those things on the same switch is pretty braindead.  However, in fact, it does

not necessarily work as documented.  It does different things on different builds, and defaults to

different values in different builds.

I'll be glad when we finally retire the ASA gear.  Not that the ASR stuff is ready for production use yet,

plenty of -- ahem -- issues there as well.