Le mardi 15 février 2005 à 16:18 -0800, Dan Lynch a écrit :
The headers encapsulated in the ICMP message include the client's NAT
IP as the source IP address, not its native IP. I suspect that the
client therefore ignores the ICMP message.
I'm quite curious to know what product is responsible for handling the
NAT ? It seems it fails to achieve its job...
Is it a common option on firewalls to re-write encapsulated headers to
avoid this sort of thing?
It's not an option, it's a requirement ! If you don't rewrite ICMP
errors payload when NATing, then clients will ignore them and your IP
stack is broken...
How is this handled correctly?
First, how does a normal IP stack interprets an ICMP ? It reads payload.
This payload contain a citation of IP header plus at least next 8 bytes
from the packet that raised the error. This allows the IP stack to find
out which IP connection is impacted and therefore send back an error to
according socket.
Suppose this case :
A -----> R --[..]-> M -[..]--> C
NAT
If we have a connection, say A:1030->C:80, it will be NATed, to
R:1030->C:80 as an example. Suppose a router on the path (M) generates
an ICMP for whatever reason. It will send back an ICMP error M->R,
copying original packet header plus 8 bytes so you see R:1030->C:80 in
payload. R receive the packet then deNAT it, so it becomes M->A. If you
don't alter ICMP payload, A receive the ICMP, extract the header and
reads R:1030->C:80. Do I have a socket open for a connection from R:1030
to C:80 ? No. R is not even a local IP ! So I drop the ICMP.
What R _must_ do (handling ICMP is a requirement for IP communications)
is alter ICMP payload as well, according to NAT transformation, meaning
our ICMP payload must be transformed to A:1030->C:80 so A don't drop it
and handle it the way it should.
Moreover, a device that would not transform ICMP payload would be
vulnerable to information leak, such as described in [1] that is 2 years
old... Basicly, Netfilter was failing to correctly NAT an TTL Exceeded
message, allowing one to discover to which internal address a public
address was NATed to by reading the ICMP payload that was not
trasnformed back.
We've worked around it by setting the client's MTU smaller, but we'd
prefer to use path MTU discovery and keep default MTU settings.
Yes, that's the way it should be handled. Obviously, your NAT is broken.
[1] http://www.netfilter.org/security/2002-04-02-icmp-dnat.html
--
http://sid.rstack.org/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
Hi! I'm your friendly neighbourhood signature virus.
Copy me to your signature file and help me spread!
