UDP Packets dropping

Hi ,

My PIX 535 firewall is dropping UDP packets, when I make the UDP sessions. I have a global PAT address assigned for the Inside users. The are less than 1000 users in the insside network. Any Idea what could be the cause ??? All TCP sessions are working fine

How many globals are you using? I would create a pool of 5 IPs if you have them to use. If not try using what you have. But translations may be getting messed up due to a single IP.

"a pool of 5 IPs" could be interpreted as

global (outside) 1 IP1-IP5 global (outside) 1 interface

The first of these statements would mean that the first five requestors of UDP will get a complete IP address translation of their own; the second would mean that everything left over will be mapped through the single outside interface address.

When you have 1000 inside users, those 5 one-to-one-NAT IPs are effectively always going to be in use (except maybe in the middle of the night); that probably won't fix whatever the original problem is.

One could also instead configure,

global (outside) 1 IP1 global (outside) 1 IP2 global (outside) 1 IP3 global (outside) 1 IP4 global (outside) 1 IP5 global (outside) 1 interface

This would PAT to the first IP address, and if that IP ran out of available ports then the second would be used, then the third, and so on.

The PIX reserves ranges of ports; in particular, it PATs source ports < 1024 into a port < 1024. If one happened to require

1024 or more UDP connections with reserved source ports (plausible if one is VPN'ing NETBIOS to talk to an Exchange or NT server) then using more than one individual global would at least postpone the inevitable.

The PIX syslogs would have messages about being unable to create a translation if this is the problem.

Thanks guys . I did use a secon PAT address , it looks like its working ok. But there are drops from time to time. Could u please explain about the PIX reserve PAT addresses.= little more, I didnt quite get the idea.

The IP standards break udp and tcp port numbers down into several ranges with different purposes.

- port 0 is reserved and not to be used.

- ports 1 thru 1023 are "privileged" ports. The intent is that these ports are to be reserved for use by operating system utilities, and that users will not be able to create sockets with port numbers in this range.

Some services use the source port number as an aspect of authentication. "rsh" and "rlogin" are probably the best known of these. The idea at the time was that mere users would not be able to initiate sockets with ports in the reserved range, so that if the connection came from a reserved port then you could trust that the remote user was who the passed data said they were, without requiring a password.

- The ports from 1024 to 49151 are the "registered" ports. These are destination port numbers of "well-known" (in some sense) services. Not every machine will support even a fraction of these services, and it is allowed to use any given port in this range for some other service completely, but if you are allowing a particular service to run on a machine, then the "best practice" is to have it run on the port registered for that service, so that other systems can find the service more easily (e.g., without having to ask you which port you put the service on.)

- The ports from 49152 to 65535 are "dynamic and/or private ports". No official registrations will be accepted for these ports. The idea is that if you are putting up a private service (perhaps one with temporary port numbers) then you should use this range as the destination, and if you are allocating a port number dynamically as the source port for a connection, then you should use a port in this range.

In practice, a lot of systems (especially Windows) ignore the 49151 boundary, and use everything from 1024 to 65535 as a mix of registered and dynamic and private ports. Some firewalls pay attention to the

49151 boundary, but as far as I can recall, the PIX does not.

Firewalls do, though, still pay attention to the 1023 boundary. When they see that the source port number is 1 to 1023, firewalls will attempt to allocate a port number in the same range, so that services which check to see if the source port is reserved will still work. Different firewalls have different strategies about -which- port number in the range will be used, but they all have in common the difficulty that if you have more than 1023 active sessions that use source ports in that range, then they will run out of port numbers to allocate.

How they handle running out of reserved ports varies between firewalls: some will just drop the packets; some will bother to return an icmp message as well as dropping the packets; some will use a non-reserved port instead, knowing that if the other side cares then it will complain at the protocol level, and if the other side turns out not to care then the firewall has successfully mediated a connection that would otherwise have failed.

On the PIX, if you are using PAT and you run out of ports from

1 to 1023 on one IP address, the PIX will look to see if there are more PAT IPs available, and if so will try them in sequence.

Thanks a lot its very clear.