We are experiencing some problems lately with a small number of webpages in the internet while accessing them behind a PAT address (many to one). The same web pages work fine if accessed behind a NAT address (one-to-one Translation).
We are using PIX 535 version 8.0(4), while we also tried it by "downgrading" to 7.2(4).
At the begining we suspected problem with DNS, but doesn'e make much sense since, the pages work well if behind NAT. Another assuption is to do with ICMP error that some web pages send back to source, but not handled if behind PAT by PIX, but we couldn't find anything in the capture...
The NAT/PAT we are using is.....
nat (USERS) 10 10.10.0.0 255.255.0.0
global (OUTSIDE) 10 X.X.X.0-X.X.X.X.61 netmask 255.255.255.224
global (OUTSIDE) 10 X.X.X.X.62 netmask 255.255.255.224
global (OUTSIDE) 10 X.X.X.X.63 netmask 255.255.255.224
And the following (default) policy....
dns server-group DefaultDNS
inspect h323 h225
inspect h323 ras
inspect icmp error
inspect dns preset_dns_map
Can you remove the http inspections?
Does it help these pages?
It could be that the pages embed some port info inside the http data and the ASA does not overwrite that payload, so it all works when the port is not changed (statics) byt the ASA and the payload does not need to be overwritten. Just a thought. If that is the case I don't think you can do anything rather than 1-1 nat (doubt if that is a viable solution).
I tried to remove both http and dns inspects just in case, but nothing changed.
1-1 NAT is not an option since I will need many more addresses....
Only captures will prove what is wrong. Pay attention to payload to see if there are embedded fields.
Also you can do an asp type drop to capture dropped packets to see if something from either side is blocked.
We managed to find the problem. To tell you the truth we couldn't even thought of the reasons......
a) Some Web Hosting Service Providers filter addresses ending with X.X.X.0 and X.X.X.255 due to smurf attacks
b) Some other Web Hosting service Providers filter using DNSBL Database to protect from http DDos attacks (http://sourceforge.net/projects/mod-spamhaus/). This is not as common though as with reason a.
So in our case the PAT address was ending in .255 and was also listed in spamhaus blacklist... go figure out... merphy's law.