icmp unreachable - need to frag

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Gentlemen,

I'm having a perplexing problem with icmp unreachable packets.  I'm
running TaoLinux with kernel 2.4.21 and iptables v.1.2.8.

I have a network setup that includes a DSL connection to the internet, and
internal lan, and an wireless lan that can connect to the internal lan via
a PPTP VPN (due to lack of a good ipsec client for Mac OSX).

It essentially looks like this:

All wireless clients (after authenticated with PPTP): 192.168.0.0/24
All internal LAN clients: 172.16.0.0/16

A VPN server/router sits between the wireless and internal lan, with two
interfaces enabled...one that has a 192.168.0.1 address, and one that has
a 172.16.3.2 address.  The router takes traffic from the wireless clients
and masquerades it into the internal network.  If the traffic from the
wireless clients is destined for the Internet, the packets are again
MASQ'd on that outbound connection from the internal lan.

This has worked for some time with only one eMac (MacOSX) connecting from
the wireless network.  No problems whatsoever.  However, this past week, I
added a Windows XP laptop to the mix.  It appeared, at first, to be
working, and indeed it is for most sites.  However, accessing certain
sites from the laptop...slashdot, wikipedia, amazon.com, cause icmp
unreachable messages to be sent.  For example, here's an attempt to
connect to slashdot:

[root@airport scripts]# tcpdump host slashdot.org -l
tcpdump: listening on eth0
09:33:24.269454 172.16.3.2.1829 > slashdot.org.http: S
3045606506:3045606506(0)
win 16384 <mss 860,nop,nop,sackOK> (DF)
09:33:27.224869 172.16.3.2.1829 > slashdot.org.http: S
3045606506:3045606506(0)
win 16384 <mss 860,nop,nop,sackOK> (DF)
09:33:27.332020 slashdot.org.http > 172.16.3.2.1829: S
911608977:911608977(0) ac
k 3045606507 win 5840 <mss 1460,nop,nop,sackOK> (DF) [tos 0x20]
09:33:27.336360 172.16.3.2.1829 > slashdot.org.http: . ack 1 win 17200 (DF)
09:33:27.338073 172.16.3.2.1829 > slashdot.org.http: P 1:481(480) ack 1
win 1720
0 (DF)
09:33:27.457883 slashdot.org.http > 172.16.3.2.1829: . ack 481 win 6432
(DF) [to
s 0x20]
09:33:28.264668 slashdot.org.http > 172.16.3.2.1829: . 1:861(860) ack 481
win 64
32 (DF) [tos 0x20]
09:33:28.265251 172.16.3.2 > slashdot.org: icmp: 172.16.3.2 unreachable -
need t
o frag (mtu 896) [tos 0xc0]
09:33:28.269985 slashdot.org.http > 172.16.3.2.1829: . 861:1721(860) ack
481 win
 6432 (DF) [tos 0x20]
09:33:28.270114 172.16.3.2 > slashdot.org: icmp: 172.16.3.2 unreachable -
need t
o frag (mtu 896) [tos 0xc0]
09:33:31.260505 slashdot.org.http > 172.16.3.2.1829: . 1:861(860) ack 481
win 64
32 (DF) [tos 0x20]
09:33:31.260820 172.16.3.2 > slashdot.org: icmp: 172.16.3.2 unreachable -
need t
o frag (mtu 896) [tos 0xc0]
09:33:37.261652 slashdot.org.http > 172.16.3.2.1829: . 1:861(860) ack 481
win 64
32 (DF) [tos 0x20]
09:33:37.262174 172.16.3.2 > slashdot.org: icmp: 172.16.3.2 unreachable -
need t
o frag (mtu 896) [tos 0xc0]

I'm no expert regarding this sort of stuff, but logic suggested that the
problem was with the mtu somewhere on the path.  I did note that the MTU
on the ppp0 (pptp) interface was 896, so I tried increasing this value. 
No luck, same behavior.  This was also true if I tried to lower it.

I'm at a loss for what to try, and my research hasn't run across anything
substantial.  Scrapping the XP laptop is not an option, unfortunately. 
The eMac continues to function fine on these sites, and I haven't run
across anything glaringly obvious on the Windows side.

Is this likely a misconfiguration on my part?  Has anyone experienced
anything similar?

I appreciate any insight you can provide.

John



[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux