1. Home
  2. Cisco Systems
  3. PIX 515 Rejection happens before port translation ???

PIX 515 Rejection happens before port translation ???

Hi all a PIX 515E here at work. It has recently been upgraded from 6.3 to 7.21.

Seems to me that it's since this upgrade that i encounter some strange problems.

PIX has three interfaces : 1 for the Web (level 100), one for our intranet (level 0) IPs 192.168.0.0 and one for a DMZ (level 4) IPs 10.10.10.0.

in the DMZ is a Web server (it's the only server in the DMZ).

Last night, at home i recieved a newsletter from this web server (our web site) and just to test, i clicked the "unregister to the newsletter" link. I was under firefox ... the page never showed ... Instead there was a blank page : no message .... I tested the same link under IE6 and it did the same. I tested the site's index page but nothing showed. Nslookup found the site's IP without problem. I could surf every web site i could think of, but not this one ...

After rebooting my PC, i could surf the site's index and other pages without a prob. So i thought it was a local problem. Nevermind, i noted my IP so that i could watch the PIX's log the next day.

I found many lines about rejecting my connection and here we are, i don't understand what's happening. The fact is that, searching to the log, there are many people encoutering the same problems, but also many people surfing the site without probs at the same time.

So here's some of the log lines i found

Nov 27 10:56:44 192.168.1.254 %PIX-4-106023: Deny tcp src dmz:10.10.10.220/80 dst outside:81.51.10.184/1910 by access-group "dmz_access_in" [0x3e19d1ab, 0x0]

Nov 27 11:55:42 192.168.1.254 %PIX-4-106023: Deny tcp src dmz:10.10.10.220/80 dst outside:86.204.128.134/3549 by access-group "dmz_access_in" [0x3e19d1ab, 0x0]

Nov 27 11:56:55 192.168.1.254 %PIX-4-106023: Deny tcp src dmz:10.10.10.220/80 dst outside:86.204.128.134/3568 by access-group "dmz_access_in" [0x3e19d1ab, 0x0]

Nov 27 11:56:58 192.168.1.254 %PIX-4-106023: Deny tcp src dmz:10.10.10.220/80 dst outside:86.204.128.134/3569 by access-group "dmz_access_in" [0x3e19d1ab, 0x0]

Nov 27 11:57:53 192.168.1.254 %PIX-4-106023: Deny tcp src dmz:10.10.10.220/80 dst outside:86.204.128.134/3593 by access-group "dmz_access_in" [0x3e19d1ab, 0x0]

Nov 27 11:58:05 192.168.1.254 %PIX-4-106023: Deny tcp src dmz:10.10.10.220/80 dst outside:86.204.128.134/3594 by access-group "dmz_access_in" [0x3e19d1ab, 0x0]

Nov 27 11:58:12 192.168.1.254 %PIX-4-106023: Deny tcp src dmz:10.10.10.220/80 dst outside:86.204.128.134/3595 by access-group "dmz_access_in" [0x3e19d1ab, 0x0]

Nov 27 11:58:29 192.168.1.254 %PIX-4-106023: Deny tcp src dmz:10.10.10.220/80 dst outside:86.204.128.134/3596 by access-group "dmz_access_in" [0x3e19d1ab, 0x0]

Nov 27 11:59:28 192.168.1.254 %PIX-4-106023: Deny tcp src dmz:10.10.10.220/80 dst outside:86.204.128.134/3620 by access-group "dmz_access_in" [0x3e19d1ab, 0x0]

What i don't understand is the outside port number (3620 for the last line here), cause there is a translation rule that should translate every DMZ-Outside 10.10.10.220/80 to my_public_ip/80 Here's the rule : static (dmz,outside) tcp my_public_ip www 10.10.10.220 www netmask

255.255.255.255

As i understand it, it's like the rejection happend before the port translation, but i'm certanly wrong ;-)

Any help/comment is greatly appreciated.

Thanks for reading.

Bye. Fred

Reply to
fred.fm
Loading thread data ...

86.204.128.134 port 3620 initiated a connection from outside to my_public_ip port 80, which was translated to 10.10.10.220 port 80 and reached that machine. That server then replied, and some traffic might have flowed. Eventually, the PIX mis-tracked the connection and thought it had been closed down and so the PIX deleted the translation that had been put in place automatically when the connection had come in. When the server next replied, the PIX saw the packets arriving from the DMZ interface, but it did not realize they were part of the flow and so it thought they were -new- connection attempts from the DMZ to the outside. The dmz_access_in is set up to block most (thought-to-be-) new connections to elsewhere, so the dmz_access_in blocked the packets, generating the log message you see.

The question now becomes "Why did the PIX think it should close down an existing connection"? Try looking more closely in the log for related messages such as a regular end of connection message (which probably requires logging at level 6 (debugging) to see.) Possibly you will see a connection close log message, possibly mentioning an RST flag.

PIX 6.2 and afterwards tend to close down translations too early. Once they see a RST from either side, those versions tend to discard the translation without waiting long enough to harvest reply packets (including, e.g., RST ACK) that are "in flight".

If you turn on "connection pipelining" in your browser client, you might possibly get fewer of these issues. And -possibly- 7.x has a 'timeout' that can be increased to allow more harvesting time (I haven't checked.)

But it wouldn't surprise me if you are hitting a 7.2(1) bug. Try looking through the Bug Navigator using your CCO account.

[You've probably heard the saying, "Never use a dot-zero or dot-one software release on production equipment; wait for someone else to find the major bugs that were introduced in the software rewrite!" ]
Reply to
Walter Roberson

Hi, and thanks very much for your interest in my problem.

Walter Robers>

Well that's what i sort of "guessed" ;-)

Here's the logs :

4|Nov 28 2006|14:19:58|106023|10.10.10.220|86.213.247.160|Deny tcp src dmz:10.10.10.220/80 dst outside:86.213.247.160/1308 by access-group "dmz_access_in" [0x3e19d1ab, 0x0]

6|Nov 28 2006|14:19:42|302014|86.213.247.160|10.10.10.220|Teardown TCP connection 594006 for outside:86.213.247.160/1308 to dmz:10.10.10.220/80 duration 0:00:30 bytes 0 SYN Timeout

6|Nov 28 2006|14:19:12|302013|86.213.247.160|10.10.10.220|Built inbound TCP connection 594006 for outside:86.213.247.160/1308 (86.213.247.160/1308) to dmz:10.10.10.220/80 (83.206.17.186/80)

Seems the timeout idea's the good one ;-)

Cisco's doc says syn timeout is now (7.0 -->) 30 secs by default, but it was

2 mins before (6.x)

The question is why are we reaching the timeout ...

30 secs should be more than enough for 3 IP packets to travel.

I've searched and found no "unresolved" bug concerning this kind of timeout.

Thanks for your inputs.

Things are clearer for me now, even though i don't know why this is happening. I'll continue searching, and will tell you if there's something new.

Please, if somone's got an idea ... just tell me.

Bye. Fred

Reply to
fred.fm

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.