Hide-Nat will never clash...

In article , Stephane Leonard wrote: :Can anybody tell me why a PIX is not clashing the source ports of tcp :connections intitiated from inside hosts being hide-nated to the :external IP for browsing? Can anyone tell me for sure the PIX is :randomizing the source ports to make sure no clashes could happen?

When you are using PAT, PIX 5.x and 6.x always use the next available port number in sequence within the same logical grouping (privileged ports and non-priviledged are handled seperately.)

:Typically, windows XP machines use 1024/tcp for high-port. The issue is :that, if you've got 20 machines inside going to

how the :PIX manage the fact that most likely more than 2 machines inside will :come to the PIX with a source port or 1024/tcp?

No matter what the {non-priviledged} source port was, the first outward tcp connection will be assigned 1024, the second 1025, and so on. No port number will be reused until it wraps from 65535 to 1024 -- and even then it will check to be sure that the mapping port isn't already in use before assigning it.

:Please, let me know how I can retrieve logs from the PIX to see it works ok.

logging host LOGHOSTIP logging trap info

Then you need to be running a syslog server on the system with address LOGHOSTIP. If you are using a Windows machine and you aren't using a really high volume of traffic, Kiwi Syslog is well regarded.

:Now, talking about another scenario.

: >> VPN site to site

:Regardless what is the inside network ip addressing which can be really :funky. Anyone from this funky network going to a remote private IP :through a VPN is getting hide-nated to a "virtual" private IP not :leading to any networks attached to the PIX.

That is a bit unusual but not unknown.

:Once hide-nated, this :"virtual IP" is the source for tcp connection to the DB server at the :other side of the VPN. It looks, if we've got for example 3 Windows XP :machines talking to this "special hide-nat" that sometimes the last :machine make clashing the other machines already connected... Like, I :believe there is like a fight !

That can't happen if you are using Port Address Translation and the traffic is TCP or UDP. You can, though, run into problems with PAT and PPTP traffic (not the PPTP packets themselves, but the GRE packets that PPTP also uses.)

:Please, let me know how I can get logs to make sure this source port :"game" is ok in this scenario...

The quick way, without even setting up a syslog server, is to configure

logging buffered info

and then

show log when you want to see the latest few log messages.