Network Engineering Stack Exchange is a question and answer site for network engineers. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a Cisco 1811 configured with PAT:

interface FastEthernet0
 ip address dhcp
 ip nat outside       
interface Vlan1
 ip address
 ip nat inside
ip nat inside source route-map primary interface FastEthernet0 overload
route-map primary permit 10
 match ip address 9
 match interface FastEthernet0
access-list 9 permit
ip route FastEthernet0 dhcp 99

I'm also using this router as a caching DNS relay:

ip dns server

Clients on VLAN1 could send DNS query's to and the router would relay them to the DNS servers from the DHCP lease on Fas0.

However, recently my (residential) ISP began blocking inbound UDP port 53 (for good reason). This is posing a problem because the relayed packets from the Cisco router have SrcPort:53 and DestPort:53. The replies never make it back.

So my question is: Is there anyway to re-write all UDP packets output from Fas0 changing ScrPort 53 to some other fixed port, and then re-writing them back when they return. Or is there some way I could force them to send from the inside of the NAT and would that solve the problem?

All suggestions or ideas welcome.


share|improve this question
up vote 2 down vote accepted

When the routers NAT they will first check if the "correct" source address is available if so they will map that to that nat translation. If it is not available it will select a number as src port from a pool 1-512 (or 1024) for the service under port 512 (or 1024). Which ever is the first available and place that in the translation.

Going by this, and this is mainly an idea i had for a case i had with similar issue (NTP src port coming as port 1, because ntp port was taken and request denied from the ntp server as it was a non ntp port number and their firewall stopped it.) So reversing that what you can do is, if you somehow make sure that src port 53 is taken it will select another port.

So have another service take over the translation forcing your real one to be mapped differently. Probably wont work in your case cause the router is doing the requests? Or create a static dummy static nat which creates a static entry in the translation table forcing your service to use another port.

Again it's an idea haven´t really tested it but it might work. Didn't at the time really find any good way to control which services got which source port without "hacking" a bit :).

share|improve this answer
Adding the 'dummy' NAT translation seemed like the perfect solution. Sadly, it seems that the router overrides this with it's own services (maybe the static entry would have broken the DNS resolver?). Adding the static translation shows up in the NAT table, but the router still stubbornly sends out DNS requests with a source of 53. – MikelR Nov 4 '13 at 0:27
Yeah, was afraid of that since it's a local service on the box. So unless you can specifically configure the service to use another port, which i don´t think you can. You could try to move the service outside the box. Or have the client do the DNS lookup themselves, which would force them to src from another port. – Gustav Haraldsson Nov 4 '13 at 0:45

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.