cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
441
Views
0
Helpful
2
Replies

Weird PIX problem accessing a specific website

fpineau
Level 1
Level 1

I have a weird problem trying to access a specific website. No client

inside the PIX can hit it (although they can all ping it). Clients

outside the firewall (on different networks) are fine. I get the

following messages on the firewall:

302001: Built outbound TCP connection 49750 for faddr <TARGET

SUBNET>.179/80 gaddr <SRC SUBNET>.174/3128 laddr 192.168.1.251/3128

106015: Deny TCP (no connection) from <TARGET SUBNET>.178/80 to <SRC

SUBNET>.174/3128 flags SYN ACK on interface outside

106015: Deny TCP (no connection) from <TARGET SUBNET>.178/80 to <SRC

SUBNET>.174/3128 flags SYN ACK on interface outside

106015: Deny TCP (no connection) from <TARGET SUBNET>.178/80 to <SRC

SUBNET>.174/3128 flags ACK on interface outside

("<TARGET SUBNET>" and "<SRC SUBNET>" are my edits)

<SRC SUBNET>.174 is a static map to 192.168.1.251

The errors seem to indicate that the syn ack is coming back from the

wrong IP address (.178), so the PIX disallows it as it is expecting it

from .179

I've tried this behind several other PIX's on different networks and

had no trouble.

Assuming for the moment that the TARGET site made no changes, is there

anything on the SRC PIX that could account for this? A bug in the FW

software, for example?

I suspect the target site made some sort of change (they said they

didn't, but they always say that, don't they?) but I need to be able

to rule out everything on this end first.

2 Replies 2

mhoda
Level 5
Level 5

Hi,

You are to the point accurate with your analysis on the log. It appears that the web server is sending a response back using a different ip which is .178 instead of .179. So, pix is simply dropping the packets as there is no xlate/conn object . I am confident that the problem is not with the PIX, and if really want to prove it, you proabably can put a sniffer on the outside of the pix to verify if pix is logging it right. Based on the pix log, the problem is definitely with the webserver.

Thanks,

Mynul

Thanks, but it doesn't really explain why it works fine from every other network, including networks behind PIX's. Why would it be answering from the wrong IP to only one site?

Review Cisco Networking for a $25 gift card