[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