cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1965
Views
0
Helpful
10
Replies

NAT icmperr problem

madflick
Level 1
Level 1

Hi everybody!

We're having problem with new router. Couple times a day one or more hosts on "inside" interface get blocked by NAT entries like the following:

icmperr x.x.x.x y.y.y.y -- --

where x.x.x.x is "outside" interface address and y.y.y.y address of host that is in source list for dynamic NAT.

Well, I have seen explanation _when_and_why_ that happens but what I actually need is _how_to_fix_ that problem.

I have already tried to change IOS three times and that problem appears once and once againg. I cannot use any IOS prior to 12.1 when that error was discovered as there is none for 3845.

Any information about _solving_ that issue is greatly appreciated.

10 Replies 10

umedryk
Level 5
Level 5

Actually, you need to check the release notes before actually upgrading your cisco box. Especially for caveats and features...

Do you mean that is a "feature" of 3845? There is no single word about icmperr on cisco.com beside two messages on this forum. Well, at least I wasn't able to find one. And there is no IOS version for 3845 that we used on 2600 previously.

Madflick,

This is what I found in: http://www.mailarchive.ca/lists/comp.dcom.sys.cisco/2005-04/

################QUOTE############################

FYI:

'icmperr' entry was introduced from 12.1(10.1). Prior to this version, if a NAT box with overload configured receives an ICMP error message, NAT tries to allocate an address (as opposed to address+port) and to create a simple entry. This means that if:

- the box is configured with interface overload or - all the addresses in the overloaded pool are used the route drops the ICMP error packet... Now: Instead of dropping the packet the route just picks any address (from the pool, or from the interface) and it creates a simple entry with a special value in the protocol field (proto=icmperr). This simple entry is used ONLY to translate ICMP errors coming from that particular Inside host. The entry times out in 1 minute. The timeout value cannot be changed from the CLI.

################unQUOTE############################

regards,

Rick

dbellaze
Level 4
Level 4

Can you post your NAT configuration, all of it.

Daniel

We had the same issue with some Polycom SIP based phones. When the session is terminated the phone sends and icmp unreachable (type code=3). The nat translation would then got to icmperr proto and would only permit one-way RTP streams until the icmperr translation timed-out. RFC 972 describes ICMP and and unreachable is considered "host-routed" .... Turning on ip host-routing in global config fixed the issue for us. It was on a 2801 v12.4.1a

Hi,

We're having a similar issue when natting customers connections on 2811 router. In our case running ip host-routing is not an option as the 2811 is running ISIS.

By the way - in the only explanation to this that I've ever seen it says there that this nat entry with icmperr protocol value times out after 1 minute. It doesn't seem to be the case here - I have an entry that is present there since at least 15 minutes. For this entry to timeout - is it required that there is no traffic coming from the inside address for the timeout period?

Does anyone have any update or did anyone manage to get more information on the icmperr issue in NAT?

We're running IOS 12.3(14)T.

Thanks a lot,

Best Regards,

mike

I got the same issue. The NAT outside traffic cannot come in to inside. The funny thing is I put 'clear arp'. It will temporary work around 1 minute and stop again.

Regards

Godwin

I have faced the same problem on 7301 router running 12.3(14)T2 with overload nat. As far as i could understand, it creates icmperr entries each time it receives the following error icmp messages from inside host - icmp unreachable, icmp time-exceeded, icmp parameter-problem, icmp redirect and icmp source-quench (with any codes).

Sometimes icmperr entry ages out in 1 minute, but sometimes it stucks in ip nat trans table forever, so the only way to remove is use "clear ip nat trans inside" command.

Anyway, no traffic is forwarding to or from inside host while icmperr-entry exists.

I have workarounded this issue with inbound access-list on inside interface, which denies some kind of icmp messages from inside hosts, the problem has disappeared.

ip access-list extended nat-bugfix

deny icmp 192.168.0.0 0.0.255.255 any unreachable

deny icmp 192.168.0.0 0.0.255.255 any time-exceeded

deny icmp 192.168.0.0 0.0.255.255 any parameter-problem

deny icmp 192.168.0.0 0.0.255.255 any redirect

deny icmp 192.168.0.0 0.0.255.255 any source-quench

permit ip any any

But i'm not sure that it's a correct solution. It seems to me, that this is a bug...

Hi there,

Cisco says that there is a bug (CSCeg83834). They say that to work around the problem, you need to create the NAT Pool of more than one IPs (I have done it with 4 IPs).

Unfortunately, in my case, the 'icmperr' entries still appear, but maybe this will work for you..

Regards,

mike

I have been having problems w/ 12.3(14)T2 regarding NAT.

I havn't contacted TAC or looked up the release notes.

We have been upgrading 831 spoke VPN routers that were running 12.2(8)YN to fix some PKI isseus we have been having and to prepare for DMVPN. I upgraded an 831 spoke to 12.3(14)T4 and it looks like NAT is working again.

When running 12.3(14)T2, I could not traceroute from an AccessPoint behind the router. I created the nat access list to log the traffic. I did not see any log entries for the AP's IP. There were no translations recorded (sh ip nat trans). Traceroute would die at the router.

After upgrading to 12.3(14)T4, when I traceroute from the AP, I see log entries for the NAT ACL, I see NAT translations recorded, and I could traceroute to the destination IP.

Here is my NAT config:

interface Ethernet0

ip address 192.168.67.241 255.255.255.240

ip nat inside

ip virtual-reassembly

ip tcp adjust-mss 1300

no cdp enable

hold-queue 32 in

hold-queue 100 out

!

interface Ethernet1

ip address dhcp

ip access-group DoS_Input_Queue_Wedge in

ip nat outside

ip virtual-reassembly

no ip route-cache

no ip mroute-cache

duplex auto

no cdp enable

crypto map HOME2-CRYPTO

!

!

ip nat inside source route-map nonat interface Ethernet1 overload

!

!

ip access-list extended DoS_Input_Queue_Wedge

remark http://www.cisco.com/warp/public/707/cisco-sa-20030717-blocked.shtml

deny 53 any any

deny 55 any any

deny 77 any any

deny pim any any

permit ip any any

access-list 110 remark --------Traffic to NAT--------

access-list 110 deny ip 192.168.67.240 0.0.0.15 192.168.0.0 0.0.255.255 log

access-list 110 deny ip 192.168.67.240 0.0.0.15 10.0.0.0 0.255.255.255 log

access-list 110 permit ip 192.168.67.240 0.0.0.15 any log

!

route-map nonat permit 10

match ip address 110

-jonathan