[c-nsp] Source-IP based NAT pickiness.

Brett Looney brett at looney.id.au
Thu Feb 9 19:21:27 EST 2006


At 23:20 9/02/2006, you wrote:
>Essentially, there's a router at one of our offices with three
>interfaces, one DMZ (GbitEthernet), one ATM where a BT Leased line
>terminates, and one internal/office (also GbitEthernet), NATted network.
>   Everything is working fine, however, three devices on the Internal/NAT
>network cannot reach the outside world (anywhere that their traffic
>needs to be NATted).  If their source-ip address changes, they can see
>the outside world just fine.  If we put a working device on the
>source-ip that was affected, then this other device can't see out.  More
>below :
<snip>
>On the router, we see :
>howden-c2821-atm#sh ip nat translations
>Pro Inside global         Inside local          Outside local Outside global
>[...]
>icmperr 194.73.16.246     10.22.10.83           ---                   --

I had this problem last year with 12.3(11-13ish)T (sorry - can't 
remember the exact version number). I didn't get a detailed dump of 
it but as per your experience the router receives some type of ICMP 
packet from the host, doesn't like it and blocks the host from further access.

My initial solution (because the customer was desperate) was to drop 
all ICMP from the affected host at the router. That stopped the 
"icmperr" coming up and everything was good. As it happened, blocking 
ICMP for that host wasn't a big deal so we were fine. I haven't touch 
that customer's router since so the problem is probably still there.

The same problem showed up somewhere else and upgrading to 12.4 fixed 
it as well - we needed to do the upgrade for some feature anyway.

Last time I checked I couldn't find any bug matching this so I don't 
really know. Probably not helping much but there you go...

B. 



More information about the cisco-nsp mailing list