Re: snat and ICMP question

[Ciaran Deignan <ciaran.deignan@netcelo.com>]

Hi Marian,

Marian Stagarescu a écrit :
> 
> for a quick test you can try to masquerade all and see if the error persists:
> 
> iptables -t nat -A POSTROUTING -o outgoing-interface -j MASQUERADE.

OK I tried with
	iptables -t nat -A POSTROUTING --out-interface eth0 \
                       -j MASQUERADE
but the result is the same.


> can you post the icmp error message ?

OK, first some details...
The remote user is a Windows-2000 PC, whose IP address is
192.168.1.4. The IPsec gateway has an internal address of
10.15.1.111. The remote user is accessing an internal
web server with the address 10.15.1.105. The TCP connection
is being S-NAT-ed to take the internal address of the
gateway. 

Here's a fragment of the trace generated by
	# tcpdump -i eth0 -lnt host 10.15.1.105

10.15.1.105.80 > 10.15.1.111.2483: tcp 399 (DF)
10.15.1.111.2483 > 10.15.1.105.80: tcp 393 (DF)
10.15.1.105.80 > 10.15.1.111.2483: tcp 0 (DF)
10.15.1.105.80 > 10.15.1.111.2483: tcp 1460 (DF)
10.15.1.111 > 10.15.1.105: icmp: 192.168.1.4 unreachable - need to frag
(mtu 1400) [tos 0xc0] 
10.15.1.105.80 > 10.15.1.111.2483: tcp 1223 (DF)
10.15.1.111.2483 > 10.15.1.105.80: tcp 0 (DF)
10.15.1.105.80 > 10.15.1.111.2483: tcp 1460 (DF)
10.15.1.111 > 10.15.1.105: icmp: 192.168.1.4 unreachable - need to frag
(mtu 1400) [tos 0xc0] 
10.15.1.105.80 > 10.15.1.111.2483: tcp 1460 (DF)
10.15.1.111 > 10.15.1.105: icmp: 192.168.1.4 unreachable - need to frag
(mtu 1400) [tos 0xc0] 
10.15.1.111.2483 > 10.15.1.105.80: tcp 0 (DF)

The remote user requests a large page from the web server,
which sends it back with the "don't fragment" bit set, in
1500-byte blocks. This packet is de-NAT-ed and routed to the
IPsec tunnel. The IPsec tunnel has an MTU size of 1400, for 
compatibility with an IPsec feature called "NAT Traversal".
The ICMP error is generated by the gateway, but contains the 
IP address of the remote PC...

The web server (linux) sees an ICMP-destinataion unreachable, 
coming from the gateway but concerning the remote PC's address.
Since it does not believe that it has a connection with 192.168.1.4,
it ignores the error...

I can send you a powerpoint presentation if you're interested in 
the general IPsec networking environments...

> an ICMP does have an outter ip hdr and an inner ip dhr
> the inner ip hdr is the ip hdr of the dgram that caused the error,
> hence should be the web server ip.

Humm, maybe you wanted an iptables-style "LOG" to see the
full contents of the icmp error? Is the tcpdump info not enough?

> the outer ip hdr should be NATed address if you do the above masquerading.

its the address on the header inside the ICMP "payload"
that needs to be re-NAT-ed.

I'm surprised this problem hasn't appeared in a more
normal environment, or with other tunneling environments.

any ideas?
Ciaran

-- 
+---------------------------------------------------------+
Ciaran Deignan                              04 38 49 87 27

Netcelo SA - IPsec VPN Solutions    http://www.netcelo.com/
18-20 rue Henri Barbusse - BP 2501, 38035 Grenoble Cedex 2
+---------------------------------------------------------+