Subject: Re: IPNAT confusion...
To: None <email@example.com>
From: Frederick Bruckman <firstname.lastname@example.org>
Date: 09/29/1999 05:06:40
On Wed, 29 Sep 1999, Feico Dillema wrote:
> I think I'm a bit confused, so here's another question. I'm running
> IPNAT translating for a `10.0.x.x' network to the real world. My
> ipnat.conf looks like:
> map ex1 10.0.0.0/8 -> 126.96.36.199/32 portmap tcp/udp 10000:40000
> map ex1 10.0.0.0/8 -> 188.8.131.52/32
> Now the question: Even though this config only lists tcp/udp, does
> ipnat in this case also map ICMP traffic, e.g. ping
> packets in some way?
Yes, the second line does the remaining protocols, but without port
mapping. That is, every outgoing packet whose protocol is neither tcp
or udp has it's source address re-written, but not it's port. Certain
services, like echo (ping) wouldn't work if you tried to portmap them.
> I noticed that after a ping *through* the NAT, a ping from the NAT
> box seems to stop working for some time (waiting for the mapping
> to timeout maybe?).
In so many words, yes. Once you initiate a ping from behind the NAT,
the ipnat now knows that every packet coming in to port 7 (echo) is
really for the 10.* address. At least until the state timer has
expired. There's not enough information in the echo reply to
distinguish the intended destination, except with a timer.
> What is the right way to handle this (or Best Current Practice?). I'd
> like to be able to ping from the NAT box itself at least.
Realistically, I should think you'd do most of your network
troubleshooting on the NAT gateway, or telnet'ed into it.