• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1526
  • Last Modified:

CISCO UDP NAT Problem

Hi

I am running a Cisco 2800 Series router, and am preforming Nat over TCP just fine. I want to do some udp translations (for nameservers behind the router) and cannot for the life of me get them to work.
Does anyone know of something that I might be missing?
Cheers


Seamus
0
quantumMoose
Asked:
quantumMoose
  • 7
  • 6
1 Solution
 
Craig_200XCommented:
paste your config so we can see what you have... modify it (XXX) if needed to block out sensitive info like your public ips, passwords..
0
 
quantumMooseAuthor Commented:
version 12.4
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname router
!
boot-start-marker
boot-end-marker
!
logging buffered 52000 debugging
enable secret 5
enable password
!
no aaa new-model
!
resource policy
!
clock timezone Napier 12
clock summer-time Napier date Mar 16 2003 3:00 Oct 5 2003 2:00
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
ip subnet-zero
ip cef
!
!
no ip dhcp use vrf connected
ip dhcp excluded-address x.x.x.x x.x.x.x
ip dhcp excluded-address x.x.x.x x.x.x.x.x
!
ip dhcp pool Rheel
   import all
   network x.x.x.x 255.255.255.0
   dns-server x.x.x.x
   default-router x.x.x.x
   lease 0 6
!
!
ip flow-cache timeout active 1
ip domain name yourdomain.com
ip name-server x.x.x.x
ip name-server x.x.x.x
!
!
!
!
!
interface FastEthernet0/0
 description LAN Interface$ETH-LAN$$ETH-SW-LAUNCH$$INTF-INFO-FE 0$
 ip address x.x.x.x 255.255.255.0
 ip nat inside
 ip route-cache flow
 speed auto
 full-duplex
 no mop enabled
!
interface FastEthernet0/1
 description $ETH-LAN$
 ip address x.x.x.x 255.255.255.0
 duplex auto
 speed auto
!
interface ATM0/2/0
 no ip address
 ip nat outside
 no atm ilmi-keepalive
 dsl operating-mode auto
!
interface ATM0/2/0.1 point-to-point
 pvc 0/100
  encapsulation aal5mux ppp dialer
  dialer pool-member 1
 !
!
interface Dialer1
 ip address negotiated
 no ip redirects
 no ip unreachables
 ip nat outside
 encapsulation ppp
 dialer pool 1
 dialer-group 1
 no cdp enable
 ppp authentication pap callin optional
 ppp pap sent-username xxxxxx@xxxxxx.xx password 0 xxxxx
!
ip classless
ip route 0.0.0.0 0.0.0.0 Dialer1
!
ip flow-export source FastEthernet0/0
ip flow-export version 5
ip flow-export destination x.x.x.x 9996
!
no ip http server
ip http authentication local
ip http secure-server
ip http timeout-policy idle 5 life 86400 requests 10000
ip nat translation udp-timeout 30
ip nat inside source list 104 interface Dialer1 overload
ip nat inside source static tcp x.x.x.x 53 interface Dialer1 53
ip nat inside source static udp x.x.x.x 53 interface Dialer1 53
ip nat inside source static tcp x.x.x.x 143 interface Dialer1 143
ip nat inside source static tcp x.x.x.x 3389 interface Dialer1 3389
ip nat inside source static tcp x.x.x.x 3306 interface Dialer1 3306
ip nat inside source static tcp x.x.x.x 8088 interface Dialer1 8088
ip nat inside source static tcp x.x.x.x 5900 interface Dialer1 5900
ip nat inside source static tcp x.x.x.x 110 interface Dialer1 110
ip nat inside source static tcp x.x.x.x 21 interface Dialer1 21
ip nat inside source static tcp x.x.x.x 80 interface Dialer1 80
ip nat inside source static tcp x.x.x.x 25 interface Dialer1 25
!
!
line con 0
 login local
line aux 0
line vty 0 4
 privilege level 15
 password xxx
 login local
 transport input telnet ssh
line vty 5 15
 privilege level 15
 password xxx
 login local
 transport input telnet ssh
!
end
0
 
LANWorxCommented:
This looks fine to me. Can you post a "sho ip nat tran" to see what its doing? Also, you are NATing outbound traffic using access list 104, but I cant see that access list in your config.
0
Fill in the form and get your FREE NFR key NOW!

Veeam is happy to provide a FREE NFR server license to certified engineers, trainers, and bloggers.  It allows for the non‑production use of Veeam Agent for Microsoft Windows. This license is valid for five workstations and two servers.

 
quantumMooseAuthor Commented:
Appropriate Bits:

tcp y.y.y.y:53  x.x.x.x:53   ---                ---
udp y.y.y.y:53  x.x.x.x:53   210.54.168.35:50435 210.54.168.35:50435
udp y.y.y.y:53  x.x.x.x:53   210.54.168.35:50439 210.54.168.35:50439
udp y.y.y.y:53  x.x.x.x:53   ---                ---
Pro Inside global      Inside local       Outside local      Outside global
udp y.y.y.y:1025 x.x.x.x:1025 192.42.93.32:53   192.42.93.32:53
udp y.y.y.y:1025 x.x.x.x:1025 202.12.29.25:53   202.12.29.25:53
udp y.y.y.y:1025 x.x.x.x:1025 202.30.124.100:53 202.30.124.100:53
udp y.y.y.y:1025 x.x.x.x:1025 216.39.90.5:53    216.39.90.5:53
udp y.y.y.y:1025 x.x.x.x:1025 221.139.108.196:53 221.139.108.196:53

y.y.y.y external Ip address of network
x.x.x.x internal Ip address of nameserver

Thing is, that TCP translations work really well, the UDP just doesn't seem to work.


Cheers

Seamus
0
 
LANWorxCommented:
Hi Seamus

It looks like the DNS requests are getting to the nameserver as the line "udp y.y.y.y:53  x.x.x.x:53   210.54.168.35:50435 210.54.168.35:50435" shows. So my guess is that the return packets arent matching the NAT for some reason. Does the name server have 2 network cards or IP addresses? Also, the access-list 104 that you have: can you tell me what that NATs?

Cheers
0
 
quantumMooseAuthor Commented:
the nameserver has only one network card, and this worked fined behind another router.
Access list 104 allows access on udp and tcp to any destination.

Hope this sheds some light

Cheers
0
 
LANWorxCommented:
From the name server, can you name resolve from an external server (does DNS from the name server work going out)?
If that does work, can you try adding a line at the top of your 104 list that says "access-list 104 deny udp any 53 any". The open NATs that you posted here dont make me think this needs to be done, but it is work a go in case you have trunkated the output. It will mean that the DNS responces form the outside dont get matched but the 104 list.

Thanks
0
 
quantumMooseAuthor Commented:
Yes, the nameserver can resove addresses using an external server (forcing non-vc mode, so it is udp).
When I change list 104 to deny udp, i am unable to resolve servers, and could when set to allow again, so the access list is working fine.

argh, its so simple, yet seems so tricky.

Cheers


Seamus
0
 
LANWorxCommented:
Its very frustrating isnt it!

The change in access list as I discribed should only stop DNS UDP packets with a source port 53 (as response to a DNS from the outside) so it shouldnt break anything. Can you do 2 things:
 - type "clear ip nat tran *" (this clear all ative NAT sessions), get a DNS request from the outside to your server, post a complete "sho ip nat tran" with only 1 octet replaced with an X (its easier for me to work it out in my head)
 - change the access-list to drop only udp with source port 53 (like I asked before), type "clear ip nat tran *" (this clear all ative NAT sessions), do one request to a name server outside from the inside and one from the outside coming in, post a complete "sho ip nat tran" with only 1 octet replaced with an X

Cheers
0
 
quantumMooseAuthor Commented:
This is the "should be fully working" output (truncated to just DNS queries - theres pages of stuff otherwise)
tcp 210.54.168.x:53  192.168.1.x:53   ---                ---
udp 210.54.168.x:53  192.168.1.x:53   8.10.179.128:1815  8.10.179.128:1815
udp 210.54.168.x:53  192.168.1.x:53   ---                ---
udp 210.54.168.x:1025 192.168.1.x:1025 63.251.129.1:53   63.251.129.1:53
udp 210.54.168.x:1025 192.168.1.x:1025 64.68.11.11:53    64.68.11.11:53
udp 210.54.168.x:1025 192.168.1.x:1025 64.73.128.23:53   64.73.128.23:53
udp 210.54.168.x:1025 192.168.1.x:1025 64.92.164.186:53  64.92.164.186:53
udp 210.54.168.x:1025 192.168.1.x:1025 64.94.123.4:53    64.94.123.4:53
udp 210.54.168.x:1025 192.168.1.x:1025 64.95.61.36:53    64.95.61.36:53
Pro Inside global      Inside local       Outside local      Outside global
udp 210.54.168.x:1025 192.168.1.x:1025 64.142.124.69:53  64.142.124.69:53
udp 210.54.168.x:1025 192.168.1.x:1025 69.9.180.118:53   69.9.180.118:53
udp 210.54.168.x:1025 192.168.1.x:1025 69.20.95.4:53     69.20.95.4:53
udp 210.54.168.x:1025 192.168.1.x:1025 69.28.95.114:53   69.28.95.114:53
udp 210.54.168.x:1025 192.168.1.x:1025 171.66.2.21:53    171.66.2.21:53
udp 210.54.168.x:1025 192.168.1.x:1025 192.5.6.32:53     192.5.6.32:53
udp 210.54.168.x:1025 192.168.1.x:1025 192.33.14.30:53   192.33.14.30:53
udp 210.54.168.x:1025 192.168.1.x:1025 200.204.0.139:53  200.204.0.139:53
udp 210.54.168.x:1025 192.168.1.x:1025 200.209.30.5:53   200.209.30.5:53
udp 210.54.168.x:1025 192.168.1.x:1025 203.87.48.4:53    203.87.48.4:53
udp 210.54.168.x:1025 192.168.1.x:1025 203.111.10.225:53 203.111.10.225:53
udp 210.54.168.x:1025 192.168.1.x:1025 205.178.190.12:53 205.178.190.12:53
udp 210.54.168.x:1025 192.168.1.x:1025 206.253.194.65:53 206.253.194.65:53
udp 210.54.168.x:1025 192.168.1.x:1025 209.92.188.201:53 209.92.188.201:53
udp 210.54.168.x:1025 192.168.1.x:1025 210.10.112.130:53 210.10.112.130:53
udp 210.54.168.x:1025 192.168.1.x:1025 216.122.4.81:53   216.122.4.81:53

And heres the output with 53udp denied in list 104

Pro Inside global      Inside local       Outside local      Outside global
tcp 210.54.168.x:53  192.168.1.x:53   ---                ---
udp 210.54.168.x:53  192.168.1.x:53   8.10.179.128:2001  8.10.179.128:2001
udp 210.54.168.x:53  192.168.1.x:53   66.193.20.30:1040  66.193.20.30:1040
udp 210.54.168.x:53  192.168.1.x:53   200.192.140.21:33350 200.192.140.21:33350
udp 210.54.168.x:53  192.168.1.x:53   ---                ---


The dig I performed from the server to the outside world dig not work in the latter case either, which is inconsistent to what you suggested above too.


Cheers

Seamus
0
 
LANWorxCommented:
Hey, you're in NZ too!! :-D

I will try this on my router at home tonight and see what happens. I cant see how this isnt working :-)
Sorry to labour this point... but when you put the access-list on are you sure the list was for a source port of 53 not a destination port 53? I am very suprised this broke your outgoing DNS. (Sorry about that)
0
 
quantumMooseAuthor Commented:
Uh.. yeah.. even more retarded than that.
The access list is for any source and any destination on udp. It was originally made broad so that I could work out why this wasn't working.

So that acl should be set for destination 53. I will try setting that, and retrying the above.

Cheers

Seamus
0
 
quantumMooseAuthor Commented:
Oh my goodness. I think you have solved a problem that has been bothering me for a very long time.

I changed the acl 104 so that the udp entry was for a specific port, and it seems that it is working now!

I will perform a few further tests, and if its fixed (which I am confident that it is) then I'll award the points.

Cheers

Seamus
Rheel Electronics Ltd
Christchurch
New Zealand
0
 
LANWorxCommented:
Thank goodness. I was sure it wasnt rocket science. Thanks for making my day :-)
0

Featured Post

VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

  • 7
  • 6
Tackle projects and never again get stuck behind a technical roadblock.
Join Now