Re: PIX / PAT / standard ports

ttorgerson · ‎01-05-2004

Hello all...

I ran into an issue today that I found kind of interesting and thought I would share and get a discussion on. I had not seen it happen before, but then again syslog has not been monitored as much as needed in the past. We have an ACL defined on our perimeter routers, where we block inbound netBIOS, TFTP, SQL, etc. etc... since we do not have these services available to the public... so we block it at the perim where we have lots of CPU power and therefore our main firewall never has to deal with the traffic.

Today, while monitoring the syslog from the perimeter routers, I noticed that there were tons of inbound frames from various legitimate IP addresses with a source port of 53 and a dest address of our PAT address with dst port of 69. This was very shocking at first since we do not allow inbound tftp, hence the blocking of the udp packets. After some analysis, it was discovered that our internal DNS server was doing its job by forwarding DNS requests out the firewall to external DNS servers. When our internal DNS server reached the firewall (outbound), the firewall gave it for example 10.10.10.10 with source port 69 and sent it on out to the external DNS server. When the frame came back, it had source port of 53 and dst port of 69. By having the deny udp tftp on the perim, we were actually denying legitimate traffic. After doing a clear xlate on the firewall, all was well. My concern is that the global command that is used to create a PAT/NAT entry does not allow you to rule out lower order (standard) ports, so this issue could pop up once again in the future, only it could be port 80, port 21, port 22 or any other common standard port.

My question is this: Is there a way to control which ports are given out to clients when utilizing a PAT address? I have glanced through the forums and have also done some searches but nothing that I found listed this item as a past discussion so I hope that this is not a repetitive question.

Thanks in advance!

Thomas

gfullage · ‎01-05-2004

you can't define specifically what source port the PIX will use when doing PAT. The PIX does use the following procedure though when choosing a source port:

- If the source port is TCP/UDP 1-511, then the PIX will PAT the SRC address to one in that range.

- If the source port is TCP/UDP 512-1023, then the PIX will PAT the SRC address to one in that range.

- If the source port is TCP/UDP 1024-65535, then the PIX will PAT the SRC address to one in that range.

So, if you can stop the source host (your DNS server) from using a low source port when it talks outbound, then the PIX will automatically use a high port also. Not sure if you can do that, most IP stacks only use >1024 as source ports as far as I was aware, so it may be an option somewhere.

ttorgerson · ‎01-05-2004

Thanks for the information!

I will investigate your suggestion...

Thanks again...

scoclayton · ‎01-06-2004

One other option you may want to look into is the use of CBAC (or equivalent if not Cisco) on your permimeter routers. What this will do is allow return packets back into the network for connections that were established from the inside. Since the traffic sourced from TCP/69 was valid in this case, CBAC would recognize this and open a dynamic hole in the ACL applied to your perimter so that this traffic could get back in. Any other traffic destined to TCP/69 and not tied to an established connection would be denied as you are currently doing. But as Glenn said, the behavior you are seeing is expected and you cannot modify it on the PIX. Hope this helps somewhat in giving you some other ideas.

Scott

ttorgerson · ‎01-08-2004

Yes, I had thought about investigating CBAC. This is definitely an option worth looking into. I am working my way through the SAFE whitepapers at this time and that is helping me with some ideas that I had...

Thanks for your time!

Thomas

ttorgerson · ‎01-08-2004

I was told about a PIX issue with an earlier version regarding DNS, similar to what I am seeing. I am trying to obtain the link to this information so that I can post here.

I noticed that this was only happening for my secondary DNS, and not the primary so I dug deeper into the config and found that the primary had a static entry in the firewall, so I added a static for the secondary so this should be resolved now for my DNS servers. However, the issue could still occur for some other system in the future. Again, I will post the link to the info. as soon as it is obtained. I believe it may have been a TAC case... not sure...

I would still like to have the 'option' of telling the PIX to hand out a port within a predetermined range... I believe that would be a nice feature allowing more control...

Thomas

ttorgerson · ‎01-09-2004

Bug # -> CSCdp48115

Here are the Release Notes to the bug:

*************

DNS server sitting behind the PIX cannot use PAT since the PIX will modify the source port to be a different port number other than 53/udp.

The root names servers do not respond to the request if the source port is not 53/udp.

Using a static prevents the PIX from modify the source port of the DNS request and all work fine.

*************

Thomas