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 http://www.jacco2.dds.nl/networking/freeswan-l2tp.html . 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-1.1.2.1 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 core 4.
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 -- /etc/ppp/chap_secrets -- myusname * "secretpw" * -- /etc/ppp/options.l2tpd -- ipcp-accept-local ipcp-accept-remote ms-dns 132.231.1.24 ms-dns 132.231.51.4 ms-wins 132.231.64.201 noccp auth crtscts idle 1800 mtu 1410 mru 1410 nodefaultroute debug lock proxyarp connect-delay 5000 -- /etc/l2tpd -- [global] [lns default] ip range = 132.231.64.209-132.231.64.210 local ip = 132.231.64.208 require chap = yes refuse pap = yes require authentication = yes name = InfosunVPNserver ppp debug = yes pppoptfile = /etc/ppp/options.l2tpd length bit = yes -- /etc/ipsec.d/l2tp.conf -- conn L2TP-PSK authby=secret pfs=no rekey=no keyingtries=3 left=%defaultroute leftprotoport=17/1701 right=%any rightprotoport=17/1701 auto=add -- /etc/ipsec.d/l2tp.secrets -- 132.231.64.123 %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 solutions.
(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 132.231.64.123 there is no firewall. 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 to FC5. Please retest with Fedora Core 5. Thank you.
The bug seems to be solved (at least for me) with kernels 2.6.17-*.