ACL's from PIX 501 not adequate on ASA 5505--huh?

[JMCraig]

Hi Folks,

I'm trying to migrate a really simple setup from a PIX 501 (that I keep having to put back into service 'cause I can't get the ASA 5505 to behave the way the PIX does).

The issue is this: on the PIX, I've got common ACL entries that allow access to some basic things like email and web servers. These work fine on the ASA: my web server's visible and email works. But, I also have some less run-of-the-mill things like database query ports or other services on particular boxes. The corresponding ACL entries on the ASA are not adequate to make these work.

As a for instance, the ACL for the PIX includes an entry that exposes TCP/port 2000 to some outside hosts (my business partners use this to get into the box remotely via HTTPS to run an application on the server via a browser). I created the same kind of ACL entry on the ASA, and even though other services work, when I try to connect to this particular service, the web browser just sits there "loading" when trying to do the HTTPS connection. It's clearly something that's different with the ASA vs. the PIX, because I can literally unplug the Internet and inside switch cables from the ASA and connect them to the PIX and everything works again; no changes to any of the servers or the client.

What's odd is that if I sniff the packets on the client machine that's trying to connect through the ASA, it does appear to have done the 3-way handshake--or sometimes 5 of the 6 packet exchanges to complete the handshake; but it doesn't actually connect to the point that the browser puts up the login dialog. I do not get anything shown on the ASA's log indicating there were denied packets.

So, where else do I look? Could this be related to the Filtering function (which the PIX does not have, right)? I'm stuck because I don't know what aspect of the PIX setup needs to be replicated on the ASA--or what aspect of the ASA setup needs attention because it has features that have no counterpart in the PIX's feature set.

This is clearly a subtle problem because we have some other services that require HTTPS that work via the ASA too. And, there are other services that do not work that use high-level TCP protocols other than HTTPS (such as database query protocols). So, the port 2000 HTTPS service that does not work is not unique, it's just one of several that do not flow through the ASA properly, despite looking like they should.

Suggestions gratefully accepted.

 

[Supergrrover]

post configs for both. we'll see what's happening.

Brent
Systems Engineer / Consultant
CCNP, CCSP

 

[JMCraig]

Thanks, but I don't know if there's a practical way to scrub the configs and still have them be close enough to what's really there to be worth looking at. At any rate, I'll wait and see if Cisco can help at all (not holding my breath).

John

 

[Supergrrover]

Scrub the passwords and just mask the 2nd and 3rd octets (middle two) of the public IPs. That shouldn't be too hard or any security risk.

Brent
Systems Engineer / Consultant
CCNP, CCSP

 

[JMCraig]

Not so simple: I have about 5 dozen names defined and some of them; with easily guessed domain names, would be pretty obvious targets. So, to make it reasonably secure, I'd have to change all the names. 60 searches and replaces is not only a pain, but highly error prone. Hence my decision to see what Cisco will do for me.

John

 

[JMCraig]

OK. I have the solution: the ASA 5505 does a bunch of protocol filtering by default (Service Policy Rules), including filtering the "Skinny" protocol--which is associated with port 2000. So, when the HTTPS traffic came through to the non-Skinny app we had listening on that port, the firewall allowed the TCP socket to set up, but then rejected the beginnings of actual traffic because it wasn't using the Skinny protocol. So, the answer was to turn off the Rule Action for the Skinny protocol (in the 6.2 ASDM this is Configuration > Firewall > Service Policy Rules; Edit inspection_defaults; Rule Actions tab). While you're there, if you need to find out about what ports are involved in any of the default protocol filtering, you can see this neatly on the Default Inspections tab: it lists the name and the port(s) involved.

In the CLI from the enable prompt, you can change these settings thusly:
# policy-map global_policy
# class inspection_default
# no inspect skinny

I'm sorry but I do not know how to see what port is associated with a given protocol name via the CLI.

The output of
# show running
does not give you any information about what ports are associated the policy-map inspections so it might not have shown enough info to make it obvious what the problem is in this particular case. But then, it took the tech an hour and a quarter on the phone/web conference with me to figure it out (he'd already reviewed the PIX and ASA's configuration dumps without getting any kind of clue at all). All in all, substantially obscure.

If I'd had a bit more insight, I might have figured this out on my own because the policy-map protocol inspection just is not something that's part of the old PIX's bag of tricks--so, I should have looked at this area as a possible source of problems. Now I know....

Hope someone reads to the end of this thread if they have the same problem!

John