From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ciaran Deignan Subject: Re: snat and ICMP question Date: Thu, 10 Oct 2002 12:23:00 +0200 Sender: netfilter-devel-admin@lists.netfilter.org Message-ID: <3DA55504.CA368D45@netcelo.com> References: <3DA30D48.3EA0E56E@netcelo.com> <3DA400B9.390A17F7@netcelo.com> <3DA4100B.79866BC0@netcelo.com> <200210090934.03315.marian@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: netfilter-devel@lists.netfilter.org, Matthieu Marc Return-path: To: Marian Stagarescu Errors-To: netfilter-devel-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Id: netfilter-devel.vger.kernel.org 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 +---------------------------------------------------------+