Problem Accessing some Web Pages behind PAT on PIX

Unanswered Question
Feb 3rd, 2010

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

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Panos Kampanakis Wed, 02/03/2010 - 16:10

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

pavlosd Wed, 02/03/2010 - 21:06

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....

Panos Kampanakis Wed, 02/03/2010 - 21:58

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

pavlosd Tue, 02/09/2010 - 08:30

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.

Actions

This Discussion