UDP Port Forward Problem on Cisco 1921

[rvidrascu]

Hi all,

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:

!

version 15.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname R2-1921

!

boot-start-marker

boot system usbflash0 c1900-universalk9-mz.SPA.151-2.T2.bin

boot-end-marker

!

!

!

no aaa new-model

!

no ipv6 cef

ip source-route

ip cef

!

!

!

!

!

no ip domain lookup

multilink bundle-name authenticated

!

!

!

!

!

interface GigabitEthernet0/0

ip address 195.90.xxx.yyy 255.255.255.128

ip nat enable

duplex auto

speed auto

!

interface GigabitEthernet0/1

ip address 192.168.1.1 255.255.255.0

ip nat enable

duplex auto

speed auto

!

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

!

!

!

control-plane

!

!

line con 0

line aux 0

line vty 0 4

login

transport input all

!

scheduler allocate 20000 1000

end

[fabios]

Hi Romeo,

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.

Fabio

Sent from Cisco Technical Support iPad App

[johnlloyd_13]

i agree with fabios. check again the server IP settings. could it be firewall blocking?

[rvidrascu]

Hi guys,

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?

[cadet alain]

Hi,

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.

Regards.

Alain.

[fabios]

Romeo,

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:

access-list 100

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

Fabio

(if useful rate)

[rvidrascu]

Hi Fabio,

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.

[rvidrascu]

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

7. Observed:

NAT: o: udp (ip_address_of_the_client, 49309) -> (public_ip_address_of_the_router, 1719) [436]

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?

[cadet alain]

Hi,

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   and debug ip pack detail as well as sh ip nat trans verbose after clearing dynamic entries with clear ip nat trans *

Regards.

Alain.

[rvidrascu]

Hi Alain,

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"

[vmiller]

Gents,

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]

Usage Guidelines

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.

[cadet alain]

Hi,

Yes there is a problem are you are doing static PAT for udp so 1719 should be the port use for inside and outside.

Regards.

Alain.

[rvidrascu]

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.

[cadet alain]

Hi Romeo,

You're right I didn't read carefully the debug output, so much for me

Regards.

Alain.

[mhattar]

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