PIX and Poisoned IP address - PIX just seems to get lazy

[jkmathew77]

I think I have a pretty good idea of the culprit in the "poison IP address" mystery. I followed some packets through our network and learned that for some reason, some packets are simply ignored (or discarded) by the PIX firewall.

The PIX is supposed to be the default gateway between the 10.1.20.XXX network and the Internet. PIX is supposed to provide SIP-aware firewall.


There seems to be some relationship between the originating IP address and its tendency to ignore/discard the packets. It may be that some internal table on the PIX is overflowing, or there may be some other bug or misconfiguration. What I saw was that I could follow packets as they traveled from 10.1.20.XXX devices, through the Router and to the "inside" interface of the PIX. From there, these should have been "NAT'ed" and then sent out on its "outside" interface, where they would be directed onto the T1 line to the outside world.

I did see *SOME* packets being handled correctly. These would properly reappear on the outside interface, and then the replies to those packets would come back to the PIX on its outside interface, have the reverse NAT processing applied and then be sent out of the inside interface and back to the original client (by way of the Router).

However, at the same time, other packets just died after making the hop from the PMR to the PIX. I saw this with both DNS requests and ICMP
("ping&quot requests that I was using as tracers through the network.

The treatment of packets by the PIX *SEEMED* to depend on the IP address of the origin of the packet, which would fit well with the observation of "poison IP addresses".

We have been pulling our hairs go try and figure out why this is happening... any ideas?

 

[jkmathew77]

It also seems like the PIX is selective in what IP it lets out. At one time 10.1.20.150 can talk to anywhere in the world and any other network. But at the same time ip 10.1.20.182 cant see the public world.

 

[yizhar]

HI.

What is the pix version?
Are you using NAT, PAT or combination?
Post here your "global" statements, and the number of internal hosts.

Versions older then 6.2x have bugs in SIP implementation when it comes to PAT.
You can read about it in one of the open cavets or something like that.

In version 6.1 and below, the pix translates the encapsulated ip address in the SIP messages, so when NAT is involved it can work fine, BUT, when you have PAT, the pix only translates the ip address but not the port number (inside the sip messages), and so the packet goes out to destination but the reply comes back on the wrong port then silently dropped at the pix because it does not match the correct translation table entry.

So -
Upgrade to latest pix OS.
Try to use NAT or STATIC instead of PAT.
Let us know what happens...

Bye.
Yizhar Hurwitz

http://come.to/yizhar

http://teachers.sivan.co.il/yizhar

 

[jkmathew77]

Hello:

Here are the answers to your questions below:

Q. What is the pix version?
A.PIX Version 6.2(1)

Q. Are you using NAT, PAT or combination?
A.
nat (inside) 1 10.1.0.0 255.255.0.0 0 0

Q. Post here your "global" statements
A.
global (outside) 1 65.220.123.60-65.220.123.69
global (outside) 1 65.220.123.71-65.220.123.80

Q. The number of internal hosts.
A. <= 45 Hosts

The wierd thing is also that once we restat the PIX firewall everyting works for a short while and then it goes back to this broken state.

Thank you for your assistance...

 

[yizhar]

HI.

You have 20 registered addresses for about 40 clients, so it would be reasonable that after a while the &quot;global&quot; ranges are full.
You can troubleshoot this using the command:
show xlate
when you see the problem, and also you should use syslog messages (buffer/pdm/host/or whatever). You will probably get an error message something that say that the pix cannot create a new translation slot for ...

You might need to allow PAT (nat overload), like this:
global (outside) 1 65.220.123.61-65.220.123.69
global (outside) 1 65.220.123.71-65.220.123.80
global (outside) 1 65.220.123.60

http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_62/cmdref/gl.htm

If this is not the case here, please let us know, and also check if the internal hosts that have the problem can connect to other sites (http for example) on the Internet.
Openning a TAC case may also help you.

Bye
Yizhar Hurwitz

http://come.to/yizhar

http://teachers.sivan.co.il/yizhar

 

[jkmathew77]

YES you are right ... that seems to have solved the problem..

Thank you so much... i knew it was something simple...

But i thought the PIX can use one public address for an many internal clients as need.. is there a way to map many to one instead of one to one relation?

 

[jkmathew77]

Actually forget my last inquiry cause i found the info on the DOC you guys gave me... thanks again for your help...