Re: [Openswan dev] Openswan 2.3.1/2.4.0rc1 instability with L2TP
We have a similar configuration. I can confirm this behaviour for 2.4.0rc1 with KLIPS and the actual version of freeradius. Former versions without KLIPS seem not to be affected. As freeradius is also involved here, I post this message to freeradius-devel. Norbert Dirk Nehring wrote:
Hi,
we use Openswan with l2tpd (or rp-l2tp) and a RADIUS server (Freeradius or Microsoft IAS) as IPSec/L2TP-Server. There are no issues with password authentification. We have a patch for ppp which allows us to authentificate via EAP/TLS, so you can use a smartcard to establish a VPN. There is a EAP-TLS connection between client and RADIUS server. Unfortunately, with Freeradius, we have perhaps an MTU problem. After successful authentification, packets are sent by pppd to the client, but you do not see any packet there. If I change to Microsoft IAS (which generates packets with another size), I works without any problems. When I switch to strongswan, there is also no problem with Freeradius (same config). I assume Openswan is handling MTU in another way than Strongswan. Here is my config:
ipsec.conf --------------------------------------------------------- version 2.0
config setup # klipsdebug=none plutodebug=control plutostderrlog=/var/log/pluto.log nat_traversal=yes virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16
conn %default left=a.b.c.d
include /etc/ipsec.d/examples/no_oe.conf
conn L2TP right=%any rightsubnet=vhost:%no,%priv rightprotoport=17/1701 leftprotoport=17/1701 pfs=no keyingtries=3 authby=secret dpddelay=30 dpdtimeout=60 dpdaction=clear ike=3des-md5 esp=3des-md5,3des-sha1 auto=add ---------------------------------------------------------
l2tpd.conf --------------------------------------------------------- [global] listen-addr = a.b.c.d
[lns default] ip range = 10.x.y.2-10.x.y.126 local ip = 10.x.y.1 require chap = yes refuse pap = yes require authentication = yes name = l2tpd ppp debug = yes pppoptfile = /etc/ppp/options.l2tpd length bit = yes ---------------------------------------------------------
options.l2tpd --------------------------------------------------------- name l2tpd plugin /usr/lib/pppd/2.4.3/radius.so plugin /usr/lib/pppd/2.4.3/radattr.so debug lock proxyarp ipcp-accept-local ipcp-accept-remote ms-dns 10.1.1.101 ms-wins 10.1.1.101 mtu 1376 mru 1376 require-eap lcp-echo-failure 3 lcp-echo-interval 10 ---------------------------------------------------------
Unfortunately, I have no clue how to give more hints to track down the problem.
Dirk _______________________________________________ Dev mailing list Dev@openswan.org http://lists.openswan.org/mailman/listinfo/dev
Norbert Wegener <nw@sbs.de> wrote:
I can confirm this behaviour for 2.4.0rc1 with KLIPS and the actual version of freeradius. ...
FreeRADIUS uses the Framed-MTU attribute to calculate how much data to send to the client. Unfortunately, the calculation is probably a little wrong. In the short term set the "fragment_size" in eap.conf to a smaller value, and it should work. I think a patch for 1.0.5 would be good. Alan DeKok.
Alan DeKok wrote:
Norbert Wegener <nw@sbs.de> wrote:
I can confirm this behaviour for 2.4.0rc1 with KLIPS and the actual version of freeradius.
...
FreeRADIUS uses the Framed-MTU attribute to calculate how much data to send to the client. Unfortunately, the calculation is probably a little wrong.
In the short term set the "fragment_size" in eap.conf to a smaller value, and it should work.
I think a patch for 1.0.5 would be good.
Alan DeKok.
Maybe this solves one part of the problem, but that alone does not help. I have tried different fragment_sizes. The results differs, but in no case I do get the l2tp/ppp session authenticated. I put the logs at http://www.wegener-net.de/freeradius, where you can see the differences. The filename ends with the involved fragment size. Which more information should I provide? Norbert Wegener
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Norbert Wegener wrote:
Alan DeKok wrote:
Norbert Wegener <nw@sbs.de> wrote:
I can confirm this behaviour for 2.4.0rc1 with KLIPS and the actual version of freeradius.
...
FreeRADIUS uses the Framed-MTU attribute to calculate how much data to send to the client. Unfortunately, the calculation is probably a little wrong.
In the short term set the "fragment_size" in eap.conf to a smaller value, and it should work.
I think a patch for 1.0.5 would be good.
Alan DeKok.
Maybe this solves one part of the problem, but that alone does not help. I have tried different fragment_sizes. The results differs, but in no case I do get the l2tp/ppp session authenticated. I put the logs at http://www.wegener-net.de/freeradius, where you can see the differences. The filename ends with the involved fragment size. Which more information should I provide?
Norbert Wegener
Further analysis showed, that when using a netkey kernel instead of KLIPS and openswan-2.4.0rc1 , everything worked as expected. So the problem seems to be only partially causes by the fragment_size miscalculation. The main reason seems to be related to KLIPS. Norbert Wegener
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
_______________________________________________ Dev mailing list Dev@openswan.org http://lists.openswan.org/mailman/listinfo/dev
Norbert Wegener <nw@sbs.de> wrote:
I have tried different fragment_sizes. The results differs, but in no case I do get the l2tp/ppp session authenticated. I put the logs at http://www.wegener-net.de/freeradius, where you can see the differences. The filename ends with the involved fragment size.
The logs don't show fragment size being a problem. The RADIUS packets are very small. What I do see is that the serve starts PEAP, the client NAK's it, and asks for EAP-TLS. The server starts TLS, and the client never responds. Alan DeKok.
participants (2)
-
Alan DeKok -
Norbert Wegener