02-03-2010 01:42 AM - edited 02-21-2020 03:51 AM
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...
Any ideas....
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-guard
dns server-group DefaultDNS
domain-name mycompany.com
policy-map global_policy
class inspection_default
inspect ftp
inspect h323 h225
inspect h323 ras
inspect netbios
inspect rsh
inspect skinny
inspect sqlnet
inspect sunrpc
inspect tftp
inspect xdmcp
inspect esmtp
inspect pptp
inspect rtsp
inspect icmp
inspect icmp error
inspect http
inspect dns preset_dns_map
class class_http
inspect http
02-03-2010 04:10 PM
Pavle,
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).
PK
02-03-2010 09:06 PM
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....
02-03-2010 09:58 PM
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.
PK
02-09-2010 08:30 AM
Hi all,
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide