Bug 191872 - openswan stalls with 2.6.16 kernels
openswan stalls with 2.6.16 kernels
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
5
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-05-16 04:59 EDT by Christian Bachmaier
Modified: 2015-01-04 17:27 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-17 10:19:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Christian Bachmaier 2006-05-16 04:59:21 EDT
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.
Comment 1 Christian Bachmaier 2006-05-17 02:15:50 EDT
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.
Comment 2 Christian Bachmaier 2006-05-17 03:12:30 EDT
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"
Comment 3 Harald Hoyer 2006-05-17 03:38:29 EDT
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.
Comment 4 Christian Bachmaier 2006-05-18 02:38:22 EDT
(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.
Comment 5 Harald Hoyer 2006-05-18 03:43:22 EDT
ok... reassigning to component kernel...
Comment 6 Dave Jones 2006-09-16 23:19:12 EDT
[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.
Comment 7 Christian Bachmaier 2006-09-17 03:14:18 EDT
The bug seems to be solved (at least for me) with kernels 2.6.17-*.

Note You need to log in before you can comment on or make changes to this bug.