[Openswan Users] ICMP Type 3, Code 4, MTU 0?
Peter McGill
petermcgill at goco.net
Thu Apr 13 12:33:11 CEST 2006
I'm not sure if it is Linux or OpenSWAN that's creating this problem.
I'm not sure exactly when this started, but it used to work.
I've searched around for a few days, and haven't found any fixes that
worked.
Diagram:
Window XP Pro SP2, Contivity VPN Client 4_65.18
172.21.11.254
|
Dialup Internet (Tunnelled)
|
tank Contivity VPN Switch 600
172.21.3.102, 172.21.3.103
|
eth0, 172.21.3.101
sheridan Linux 2.4.31, OpenSWAN 2.4.4
ipsec0
|
High-speed Internet (Tunnelled)
|
delenn Linux 2.4.26, OpenSWAN 2.1.5
172.21.1.49
|
172.21.1.254
graham SCO OpenServer R5
Goal:
Telnet from Windows to graham (SCO).
Problem:
Windows receives ICMP Type 3 (Destination Unreachable), Code 4 (Must
Fragment), MTU 0
Windows adjusts the routes (presumably to lower the MTU)
Contivity Client complains about route change and disconnects (for security)
sheridan (Linux) appears to be generating the ICMP messages.
They first show up on sheridan's eth0 interface, but not on the ipsec0
interface.
I have upgraded both the Kernel and OpenSWAN on sheridan since the last
known successful operation.
Now according to the documentation I've read the MTU should never be less
than 68 in the ICMP 3,4 packets.
Also the packets that these ICMP messages are generated in response two are
way under the MTU.
The lowest MTU in the path on sheridan is 1500, and the packets are only a
few bytes of telnet traffic.
The largest telnet packet is less than 80 bytes including MAC layer, and
even packets smaller than 64 bytes
are generating these ICMP messages.
I get this info from tcpdump which I ran on all Linux interfaces in the
path.
This doesn't happen on traffic from the 172.21.3.x net to the 172.21.1.x
net,
or on traffic from the 172.21.11.x net to the 172.21.3.x net,
only on traffic from the 172.21.11.x net to the 172.21.1.x net.
It happens to other traffic not just telnet, but telnet is what I used for
testing.
We also have a 172.21.13.x net which is setup the same as the 172.21.1.x
net.
It behaves in exactly the same way as the 172.21.1.x net does above.
Any where you read 172.21.1.x you can substitute 172.21.13.x.
Debug Info:
Attached tcpdump file for sheridan eth0.
ifconfig:
eth0 Link encap:Ethernet HWaddr 00:0B:CD:E7:49:6D
inet addr:172.21.3.101 Bcast:172.21.3.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1838375 errors:0 dropped:0 overruns:0 frame:0
TX packets:2408396 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:293452895 (279.8 Mb) TX bytes:1997635009 (1905.0 Mb)
Interrupt:10 Memory:e8100000-e8110000
eth1 Link encap:Ethernet HWaddr 00:50:FC:A6:11:F2
inet addr:66.x.x.x Bcast:66.x.x.x Mask:255.255.255.248
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:209382 errors:0 dropped:0 overruns:0 frame:0
TX packets:176543 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:163370810 (155.8 Mb) TX bytes:52664170 (50.2 Mb)
Interrupt:11 Base address:0x2400
ipsec0 Link encap:Ethernet HWaddr 00:50:FC:A6:11:F2
inet addr:66.x.x.x Mask:255.255.255.248
UP RUNNING NOARP MTU:16260 Metric:1
RX packets:125483 errors:0 dropped:0 overruns:0 frame:0
TX packets:132490 errors:0 dropped:4 overruns:0 carrier:0
collisions:0 txqueuelen:10
RX bytes:126443834 (120.5 Mb) TX bytes:37209468 (35.4 Mb)
ip route show table local:
local 172.21.3.101 dev eth0 proto kernel scope host src 172.21.3.101
broadcast 172.21.3.0 dev eth0 proto kernel scope link src 172.21.3.101
broadcast 66.x.x.x dev eth1 proto kernel scope link src 66.x.x.x
broadcast 66.x.x.x dev ipsec0 proto kernel scope link src 66.x.x.x
local 66.x.x.x dev eth1 proto kernel scope host src 66.x.x.x
local 66.x.x.x dev ipsec0 proto kernel scope host src 66.x.x.x
broadcast 66.x.x.x dev eth1 proto kernel scope link src 66.x.x.x
broadcast 66.x.x.x dev ipsec0 proto kernel scope link src 66.x.x.x
broadcast 172.21.3.255 dev eth0 proto kernel scope link src 172.21.3.101
ip route show table main:
69.x.x.x via 66.x.x.x dev ipsec0
209.x.x.x via 66.x.x.x dev ipsec0
66.x.x.x/29 dev eth1 proto kernel scope link src 66.x.x.x
66.x.x.x/29 dev ipsec0 proto kernel scope link src 66.x.x.x
172.21.13.0/24 via 66.x.x.x dev ipsec0
172.21.11.0/24 via 172.21.3.102 dev eth0 metric 1
172.21.3.0/24 dev eth0 proto kernel scope link src 172.21.3.101
172.21.1.0/24 via 66.11.74.94 dev ipsec0
default via 66.x.x.x dev eth1 metric 1
cat /etc/ipsec.conf:
version 2.0
config setup
interfaces=%defaultroute
uniqueids=yes
include /etc/ipsec.d/examples/no_oe.conf
conn stmarys-office-net-to-london-office-net
also=london-office
leftsubnet=172.21.0.0/16
alsoflip=stmarys-office
rightsubnet=172.21.1.0/24
auto=start
conn stmarys-office-net-to-london-office-server
also=london-office
alsoflip=stmarys-office
rightsubnet=172.21.1.0/24
auto=start
conn stmarys-office-server-to-london-office-net
also=london-office
leftsubnet=172.21.0.0/16
alsoflip=stmarys-office
auto=start
conn stmarys-office-server-to-london-office-server
also=london-office
alsoflip=stmarys-office
auto=start
conn paris-office-net-to-london-office-net
also=london-office
leftsubnet=172.21.0.0/16
alsoflip=paris-office
rightsubnet=172.21.13.0/24
auto=start
conn paris-office-net-to-london-office-server
also=london-office
alsoflip=paris-office
rightsubnet=172.21.13.0/24
auto=start
conn paris-office-server-to-london-office-net
also=london-office
leftsubnet=172.21.0.0/16
alsoflip=paris-office
auto=start
conn paris-office-server-to-london-office-server
also=london-office
alsoflip=paris-office
auto=start
conn london-office
also=sheridan
leftrsasigkey=xxx
conn sheridan
left=66.x.x.x
leftnexthop=%defaultroute
leftid=@sheridan.london.goco.net
conn stmarys-office
left=69.x.x.x
leftnexthop=%defaultroute
leftid=@delenn.stmarys.goco.net
leftrsasigkey=xxx
conn paris-office
left=209.x.x.x
leftnexthop=%defaultroute
leftid=@sinclair.paris.goco.net
leftrsasigkey=xxx
There are no OpenSWAN log messages for the time in question.
Niether /var/log/debug or /var/log/secure
Nor any related log entries for the time in any other log.
Failed "Fixes":
Reducing the MTU on Windows XP.
Disabling Path MTU Discovery on Windows XP.
Anyone experience this problem before or have any suggestions?
Peter McGill
Software Developer / Network Administrator
Gra Ham Energy Limited
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Peter McGill.vcf
Type: text/x-vcard
Size: 520 bytes
Desc: not available
Url : http://lists.openswan.org/pipermail/users/attachments/20060413/ae5c35f0/PeterMcGill.vcf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vpndbg-eth0-2.tcpdump
Type: application/octet-stream
Size: 3452 bytes
Desc: not available
Url : http://lists.openswan.org/pipermail/users/attachments/20060413/ae5c35f0/vpndbg-eth0-2.obj
More information about the Users
mailing list