I have some problems with my Cisco 1921 router when trying to forward UDP ports. There are 2 network interfaces:
- gi0/0 [connected to the internet]
- gi0/1 [connected to the private network]
The router is suposed to do NAT and to forward TCP port 80, TCP port 1720 and UDP port 1719. The TCP ports are forwarded corectly, the problem is on UDP - router replies with ICMP destination port unreachable when internet users try to reach the inside "server". Same configuration was verified on one Cisco 892 Router and no problem was found [UDP port was correctly redirected].
Here is the config:
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
boot system usbflash0 c1900-universalk9-mz.SPA.151-2.T2.bin
no aaa new-model
no ipv6 cef
no ip domain lookup
multilink bundle-name authenticated
ip address 195.90.xxx.yyy 255.255.255.128
ip nat enable
ip address 192.168.1.1 255.255.255.0
ip nat enable
ip forward-protocol nd
no ip http server
no ip http secure-server
ip nat source list 10 interface GigabitEthernet0/0 overload
ip nat source static tcp 192.168.1.205 80 interface GigabitEthernet0/0 80
ip nat source static udp 192.168.1.205 1719 interface GigabitEthernet0/0 1719
ip nat source static tcp 192.168.1.205 1720 interface GigabitEthernet0/0 1720
ip route 0.0.0.0 0.0.0.0 195.90.xxx.yyy
access-list 10 permit 192.168.1.0 0.0.0.255
line con 0
line aux 0
line vty 0 4
transport input all
scheduler allocate 20000 1000
I do not see any problems with you configuration and it should work.
This is proven by the fact on a different platform it is working.
Recommend start some debugging like
Debug ip nat detail
Debug nat event
And should it be the case
Debug ip packet detail list 100
With access-list 100 only permits udp to those hosts.
I am fling it off my memory those command might differ slightly.
This should give you a pretty good understanding on what it is going on and why.
Sent from Cisco Technical Support iPad App
Thanks for your quick replies. I did some investigations based on your suggestions and I noticed that on the private LAN side of the router there is no UDP packet sent to the server. The router drops them and it sends the ICMP message back to the originator from the internet. I'm more than sure that there is no firewall blocking issue on the server side since the same server works fine when I replace the 1921 router with the 892 router with same config file.
Fabio, you mentioned someting about access list 100 [extended access list], but I have a basic standard access list 10 in my config. Do you say that I need to add an extra access-list on the gi0/0 to permit UDP traffic to the server? If yes, should I use the private IP address for the destination, or the public one?
The extended ACL Fabios was referring to will be applied to a debug command so as to not overwhelm CPU and to filter out only the interesting traffic.
Furthermore your standard ACL is used for NAT overload not static PAT.
Could you run the debug suggested by Fabios.
I am now at a computer and it is easier for me to be more precise ...
I notice you use ip nat enable on both interfaces instead of ip nat outside (on gi0/0) and ip nat inside (on Gi0/1)
Is there any reasons wy in such simple deplyiment you wish to use NAT Virtual interfaces?
If not please change the ip nat enable in proper ip nat inside and outside commands.
About the dignostics to run .....
As Alain said the access list I am referring to is the one limiting the packets to be debugged.
Based on yur config create an extended access list as follows:
permit udp any host (your gigabit ethernet 0/0 ip address here) eq 1719
permit udp any host 192.168.1.205
deny any any (this is implicit but better stated)
The first will allow packet coming from outside and going into Gi0/0 to be translated
the second wil start firing when translation will start to happen
Then issue the command terminal monitor if accessing the router from telnet and not console. This is to allow the debug output to be sent to your terminal.
Then the debug commands are:
debug ip nat detail
debug ip nat error
debug ip packet detailed 100
remember if the terminal starts firing lot of text and overwhelms you or the router you can rapidly issue
u all (alias for undebug all) which will turn off all debugging.
Try to do this at time of low traffic and try to connect to the host from outside to cause the NAT events to happen.
Before doing that if possible issue
clear ip nat translation *
and after a couple of attempts do a
sho ip nat translations
All of the above will give you a very clear picture of the facts.
Remember that also the ip nat debug commands accept an access list to limit the NAT debug to given traffic.
Hope this helps, lut us know how it went
(if useful rate)
When I initially configured the 892 router, when I issued the command "ip nat outside" I noticed that NVI0 became available. At that moment I started to read about the new way of configuring NAT on Cisco routers by default and about the NVI interface. With that configuration in place I had no problem. That is the main reason I also used it on the new 1921 router - it worked fine. The 1921 router will eventualy replace the 892 router if this problem is solved. Currently the setup [router and the server behind it] is not in production [I managed to isolate it from the rest of the network so it passes only interesting trafic to this scenairo] and I can debug all without the need of extended access list to filter packets and keep the CPU at a low level.
Thanks for the tip with using extended access lists combined with debuging, that would help me on a different issue I have with another router that I cannot take out from the traffic.
In 10 hours I will replace the NVI commands ["ip nat enable"] on the 1921 router with the classical ones ["ip nat inside" and "ip nat outside"] and I will let you know the results.
Looks like this is IOS version related issue.
This is what I did this morning:
1. I replaced the 1921 router with one 2600 router running C2600-IS-M 12.1(22a) release
2. Applied the modified config using "ip nat inside" and "ip nat outside" as per Fabio's suggestion
3. Observed that NAT works fine and both TCP and UDP interesting ports are forwarded
4. Upgraded the router to C2600-I-M 12.3(26)
5. The TCP ports are forwarded but the UDP port is not forwarded, similar to the issue seen on 1921. Router responds with ICMP destination unreachble, host unreachable.
6. Issued the "debug ip nat detail" command
NAT: o: udp (ip_address_of_the_client, 49309) -> (public_ip_address_of_the_router, 1719) 
NAT: translation failed (B), dropping packet s=ip_address_of_the_client d=public_ip_address_of_the_router
There must be a workaround for new IOS versions, right?
NAT: o: udp (ip_address_of_the_client, 49309) -> (public_ip_address_of_the_router, 1719)
This should be 1719 no?
Can you do the debugs again: debug ip nat detail
There is no problem with the 49309 port number. That is a random port chosen at the client side.
The format of the NAT debug trace for packets received on the "outside" interface is:
transport protocol: udp
(source ip address of the packet, source port number)
(destination ip address of the packet, destination port)
...than it should follow the next line:
s=ip_address_of_client, d=public_ip_address_of_the_router -> internal_ip_address_of_the_server
but that is for the successful case. In my case there is a problem (B), which means "Outside to inside fails before routing"
If memory serves me correctly, the ip forward-protocol may need some help.
To enable the forwarding of User Datagram Protocol (UDP) broadcasts, including BOOTP, received on an interface, use the ip helper-address command in interface configuration mode. To disable the forwarding of broadcast packets to specific addresses, use the no form of this command.
ip helper-address [vrf name | global] address [redundancy vrg-name]
Combined with the ip forward-protocol global configuration command, the ip helper-address command allows you to control which broadcast packets and which protocols are forwarded.
Yes there is a problem are you are doing static PAT for udp so 1719 should be the port use for inside and outside.
Alain, that 49309 port is the source port, it is never the destination port and it is not changed during translation. The destination ip is the only one that should be translated. I compared the traces in the successful case and in the failure case after upgrade. You are wrong in reading the NAT debug info if you think that 49303 is the destination port.
Ran into the same issue and added the inside to the statement and it resolved the issue
ip nat <inside> source static udp 192.168.1.205 1719 interface GigabitEthernet0/0 1719