Problem allowing port 80 through to DMZ

Unanswered Question
Mar 27th, 2007

I am having a strange problem. I have a new web server located in the DMZ off my PIX 515e firewall. I set up the access list and static mappings the same as I have for all of my other web servers in the DMZ. From outside, I can telnet to port 80 on the external IP addresses, but when I try to access the web page, it gives me a "Page cannot be displayed" error. I have tried to access the web page from the localhost on the server as well as from a server on the INSIDE network and I am able to connect so I know that the web server is serving pages properly. I have verified the accuracy of my access lists and static mappings and can't see anything that would cause this problem. Here is the config for one of the servers:

static (DMZ1,outside) netmask

access-list outside_acl extended permit tcp any host eq www

I have other servers with the same static and access list statements (with different IPs) and they are working fine.

Any thoughts? The software version is 7.1(1)

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
gecko2207 Tue, 03/27/2007 - 09:25

I have attached a scrubbed version of my config.

As for DNS, I am trying to access by IP address so that shouldn't be a factor, but it is resolving correctly when I try to ping the URL.

gecko2207 Tue, 03/27/2007 - 10:32

I tried clear xlate and even reloaded the PIX. Neither worked. As for logs, I have found a difference between the problem web page and the working one (both on the same server, different IPs). The working one builds the outside interface and then serves the URL. The one that isn't working build the outside and DMZ interfaces and then tries to access the URL. It then does something strange in that it gives an error of portmap translation creation failed for tcp src inside:(my pc's private IP). This is strange because my PC is on a different network behind another PIX 515e running NAT so it should only show the source address of the outside interface of that PIX (which it does when it builds the initial connection on the outside.

Here are some lines from the log showing the process:

6|Mar 26 2007 15:41:02|609002: Teardown local-host inside: duration 0:00:00

3|Mar 26 2007 15:41:02|305006: portmap translation creation failed for tcp src inside: dst DMZ1:

6|Mar 26 2007 15:41:02|609001: Built local-host inside:

5|Mar 26 2007 15:41:02|304001: Accessed URL

6|Mar 26 2007 15:41:01|302013: Built inbound TCP connection 1396326 for outside: ( to DMZ1: (

6|Mar 26 2007 15:41:01|609001: Built local-host DMZ1:

6|Mar 26 2007 15:41:01|609001: Built local-host outside:

The IPs have been changed. They are as follows: - NATd IP from the PIX that my PC sits behind. - Private IP for my PC - Private IP of server in DMZ - Static NAT translation outside address for server in DMZ

acomiskey Tue, 03/27/2007 - 10:40

do you have something like

static (inside,DMZ1) netmask

gecko2207 Tue, 03/27/2007 - 12:22

I guess I could try that.... if that was the problem though, wouldn't it be across the board for all web servers?

hoogen_82 Tue, 03/27/2007 - 23:35

static (DMZ1,outside) netmask

THe above is your statement, instead try this(assuming is your outside interface address

static (DMZ1,outside) interface netmask

This should probably solve the problem.


gecko2207 Wed, 03/28/2007 - 08:19

Hoogen, thanks for the response. Unfortunately, the outside IP address for the static statement is a different address than the interface address.

David White Wed, 03/28/2007 - 10:46

There isn't quite enough information here. However, the issue is with the following message:

3|Mar 26 2007 15:41:02|305006: portmap translation creation failed for tcp src inside: dst DMZ1:

This means that the PIX received a packet sourced from on the inside interface, and destined to on the DMZ1 interface. The packet matched a nat statement (most likely: nat (inside) 10, however upon matching the nat, it could not find a corresponding global statement on the DMZ1 interface.

Now, from your messages so far you seem to indicate that this packet should not have been received by this PIX on the inside interface. Is that correct? Or did I misunderstand something?



This Discussion