Red Hat Bugzilla – Bug 191872
openswan stalls with 2.6.16 kernels
Last modified: 2015-01-04 17:27:08 EST
I am using L2TP over IPsec to connect external WinXP clients (out of the
box) to a internal lan. Therefore I run openswan 2.4.4-1.0FC4 using NETKEY ,
l2tpd 0.69-0.2.20051030 (from the extras branch), and ppp
2.4.2 on a Fedora core 4 box. The programs are the newest rpms provided for
core 4 .
The configuration using preshared keys is as shown in the tutorial
With kernel 2.5.15-1.1833_FC4 everthing works fine. But when updating to one
of the newer kernels 2.6.16-1.2069_FC4 or 2.6.16-1.2096_FC4 and leaving
everything else as is, then a VPN connection stalls reproducibly while
transfering files, e.g., downloading a 1MB file per FTP on the WinXP client
over the VPN. A single connection suffices.
Unfortunately, there is no log entry which could clarify this behaviour.
However, the connection build-up seems to work correctly and transfering small
files in most cases works. This sounds like an MTU size problem, but I am
nearly sure that it is not. I know there was a change in the IP-stack of the
new kernels which also caused stalls in NFS v4 connections.
I already tried to recompile openswan-2.4.4-184.108.40.206 from core 5 on core 4:
the same behaviour. Thus the bug(?) may also occur in core 5. Also with the
newest source 2.4.5 from www.openswan.org I had no success.
With kernels 2.6.16-1.2107_FC4 / 2.6.16-1.2108_FC4 this problem (with the same
config) seems to be solved. But only at a first glance: now there are
reproducable stalls when connecting via RDP (winxp remote desctop connection)
from an external winxp box to an internal winxp box over the VPN.
If desired, I can send my config files.
I have to correct myself: With kernel 2.6.16-1.2108_FC4 and file transfers
over the VPN there are also stalls as with prior 2.6.16 kernels.
Also I had no success with ppp 2.4.3-6.2.1 from core 5 srpm recompiled for
Here my exact config:
ip_forward activated in /etc/sysctl:
net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
myusname * "secretpw" *
ip range = 220.127.116.11-18.104.22.168
local ip = 22.214.171.124
require chap = yes
refuse pap = yes
require authentication = yes
name = InfosunVPNserver
ppp debug = yes
pppoptfile = /etc/ppp/options.l2tpd
length bit = yes
126.96.36.199 %any: PSK "secretpsk"
This is the MTU. I guess you have to set this to a lower value.
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS--clamp-mss-to-pmtu
might help... also setting the mss in the route. You may google a bit for some
(In reply to comment #3)
I am nearly sure (as already indicated in the first posting) that the problem
is not the MTU size. tracepath gives me an MTU size of 1400 through the VPN.
Setting mtu and mru to 1400 / 1300 / 1280 / 1200 in /etc/ppp/options.l2tpd
changes nothing. This is the only necessary place, since for testing purposes
I connected the roadwarrior WinXP on the 132.231.64 subnet with no firewall,
gateway, or something similar in between and tried to download files from some
ftp server. Especially, on the openswan server 188.8.131.52 there is no
Further, what has a kernel update to do with mtu sizes?
As stated earlier: the system works perfectly with kernel 2.5.15-1.1833 even
from outside over our two firewalls and behind NAT. Updating to a kernel
2.6.16-1.* on the server leads reproducable to stalls in the connection.
ok... reassigning to component kernel...
[This comment added as part of a mass-update to all open FC4 kernel bugs]
FC4 has now transitioned to the Fedora legacy project, which will continue to
release security related updates for the kernel. As this bug is not security
related, it is unlikely to be fixed in an update for FC4, and has been migrated
Please retest with Fedora Core 5.
The bug seems to be solved (at least for me) with kernels 2.6.17-*.