It is currently Sun Aug 19, 2018 8:19 am

All times are UTC [ DST ]




Post new topic Reply to topic  [ 9 posts ] 
Author Message
 Post subject: various issues
PostPosted: Sat Oct 23, 2010 8:03 pm 

Joined: Tue Oct 19, 2010 12:01 pm
Posts: 27
After fixing the kernel trace errors by patching the pppol2tp driver, I've run into some other issues running openl2tp in Debian Squeeze on a Linksys NSLU2:

Regularly (say, 4 out of 5 attempts), a VPN connection doesn't successfully initiate with openl2tp. When running xl2tpd, no such thing happens. I've run openl2tp in debugging mode to capture the output. I cannot seem to attach any files with output here, so this is the relevant section of the failed connection attempt:
Code:
Using config file: /etc/openltpd.conf
FUNC: tunl 49031: allocated context using profile 'default', created by network request
XPRT: RX: tunl 49031/0: len=108 ns/nr=0/0, our ns/nr=0/0, peer ns/nr=0/0
XPRT: tunl 49031: peer ns/nr is 0/0
DATA: RX: tunl 49031/0: rcv 108 bytes from peer 192.168.0.1, packet ns/nr 0/0 type 0
XPRT: tunl 49031: update nr from 0 to 1
AVP: tunl 49031: SCCRQ message decode of 88 bytes started
AVPDATA: PROTOCOL_VERSION: ver=1 rev=0
AVPDATA: FRAMING_CAP: cap=1
AVPDATA: BEARER_CAP: cap=0
AVPDATA: FIRMWARE_VERSION: revision=1536
AVPDATA: HOST_NAME: name=notebook
AVPDATA: VENDOR_NAME: name=Microsoft
AVPDATA: TUNNEL_ID: id=17
AVPDATA: RX_WINDOW_SIZE: size=8
PROTO: tunl 49031: SCCRQ received from peer 17
FSM: CCE(49031) event SCCRQ_ACCEPT in state IDLE
PROTO: tunl 49031: adjust tx_window_size: peer=8, ours=10
AVP: tunl 49031: building SCCRP message, 9 AVPs
PROTO: tunl 49031: sending SCCRP to peer 17
XPRT: tunl 49031: queuing tx packet, type 2, len 153, ns/nr 0/1
XPRT: tunl 49031: update ns to 1
XPRT: tunl 49031: adding packet to ackq, type 2, len 153, ns/nr 0/1
DATA: TX: tunl 49031/0: send 153 bytes to peer 192.168.0.1, packet ns/nr 0/1 type 2, retry 0
FSM: CCE(49031) state change: IDLE --> WAITCTLCONN
XPRT: tunl 49031: send zlb ack, ns/nr=1/1
XPRT: tunl 49031: set retry interval to 2
XPRT: tunl 49031: set retry interval to 4
DATA: TX: tunl 49031/0: resend 153 bytes to peer 192.168.0.1, packet ns/nr 0/1 type 2, retry 1
XPRT: tunl 49031: set retry interval to 8
DATA: TX: tunl 49031/0: resend 153 bytes to peer 192.168.0.1, packet ns/nr 0/1 type 2, retry 2
DATA: TX: tunl 49031/0: resend 153 bytes to peer 192.168.0.1, packet ns/nr 0/1 type 2, retry 3
DATA: TX: tunl 49031/0: resend 153 bytes to peer 192.168.0.1, packet ns/nr 0/1 type 2, retry 4
DATA: TX: tunl 49031/0: resend 153 bytes to peer 192.168.0.1, packet ns/nr 0/1 type 2, retry 5
XPRT: tunl 49031: retry failure
FSM: CCE(49031) event XPRT_DOWN in state WAITCTLCONN
AVP: tunl 49031: building STOPCCN message, 3 AVPs
PROTO: tunl 49031: sending STOPCCN to peer 17
XPRT: tunl 49031: queuing tx packet, type 4, len 38, ns/nr 1/1
XPRT: tunl 49031: tx window closed
FUNC: tunl 49031: starting cleanup timer
FSM: CCE(49031) state change: WAITCTLCONN --> CLOSING
XPRT: tunl 49031: set retry interval to 2
XPRT: tunl 49031: retry failure
FSM: CCE(49031) event XPRT_DOWN in state CLOSING
FUNC: tunl 49031 deleted
FUNC: tunl 49031: deleting context

What is happening here? It seems like it does not receive response packets for the tunnel initiation from the MS Vista IPsec/L2TP client? Or maybe the client is not receiving the response of the server?


Top
 Profile  
 
 Post subject: Re: various issues
PostPosted: Mon Oct 25, 2010 8:24 pm 

Joined: Tue Oct 19, 2010 12:01 pm
Posts: 27
interestingly, when I capture packets on the server's network interface, I can see the following distinction between successful and failed negotiations of the l2tp part of the vpn connection:
- on successfull connection attempts, all packets of the negotiation appear encrypted in tcpdump
- on failed attempts, the packets that openl2tp sends appear unencrypted in the log (and do not reach the client)! I also see some unencrypted udpinesp packets with NAT-T keepalive in them during these dumps (these are sent by openswan I presume).

doing a 'ip xfrm pol' shows
Code:
src 192.168.1.1/32 dst 192.168.0.1/32 proto udp sport 1701 dport 1701
        dir out priority 2080 ptype main
        tmpl src 0.0.0.0 dst 0.0.0.0
                proto esp reqid 16409 mode transport
src 192.168.0.1/32 dst 192.168.1.1/32 proto udp sport 1701 dport 1701
        dir in priority 2080 ptype main
        tmpl src 0.0.0.0 dst 0.0.0.0
                proto esp reqid 16409 mode transport

during both successful as well as failed connection attempts.

This is with Openswan IPsec U2.6.28/K2.6.32-5-ixp4xx (using NETKEY) and openl2tp-1.7.
I've tried all combinations of rightprotoport=17/1701, =17/%any and our_udp_port=1701 both enabled and not set.
our_udp_port=1701 set seems to be the only thing that matters (without it set, I never get any successful connection attempts).

I assume that openl2tp doesn't need to do anything special for openswan to direct the L2TP packets through EPS to the client, but it's rather peculiar that xl2tpd works fine (or maybe xl2tp is the one that does something special? as it's written by the same company they know of any weird openswan stuff after all?).
My problem appears very similar to this one


Top
 Profile  
 
 Post subject: Re: various issues
PostPosted: Wed Nov 17, 2010 5:09 pm 

Joined: Tue Oct 19, 2010 12:01 pm
Posts: 27
FrankL wrote:
interestingly, when I capture packets on the server's network interface, I can see the following distinction between successful and failed negotiations of the l2tp part of the vpn connection:
- on successfull connection attempts, all packets of the negotiation appear encrypted in tcpdump
- on failed attempts, the packets that openl2tp sends appear unencrypted in the log (and do not reach the client)! I also see some unencrypted udpinesp packets with NAT-T keepalive in them during these dumps (these are sent by openswan I presume).

doing a 'ip xfrm pol' shows
Code:
src 192.168.1.1/32 dst 192.168.0.1/32 proto udp sport 1701 dport 1701
        dir out priority 2080 ptype main
        tmpl src 0.0.0.0 dst 0.0.0.0
                proto esp reqid 16409 mode transport
src 192.168.0.1/32 dst 192.168.1.1/32 proto udp sport 1701 dport 1701
        dir in priority 2080 ptype main
        tmpl src 0.0.0.0 dst 0.0.0.0
                proto esp reqid 16409 mode transport

during both successful as well as failed connection attempts.

This is with Openswan IPsec U2.6.28/K2.6.32-5-ixp4xx (using NETKEY) and openl2tp-1.7.
I've tried all combinations of rightprotoport=17/1701, =17/%any and our_udp_port=1701 both enabled and not set.
our_udp_port=1701 set seems to be the only thing that matters (without it set, I never get any successful connection attempts).

I assume that openl2tp doesn't need to do anything special for openswan to direct the L2TP packets through EPS to the client, but it's rather peculiar that xl2tpd works fine (or maybe xl2tp is the one that does something special? as it's written by the same company they know of any weird openswan stuff after all?).
My problem appears very similar to this one


I tried on a different hardware (Marvell Kirkwood) setup with the same software configuration and the same issue appears. However, failed connection attempts don't appear as often as they do on the Linksys NSLU2 (about 2 out of 5 attempts fail on Kirkwood, while 3-4 out of 5 on the NSLU2). Is this a known problem with OpenSwan and openl2tpd ?

Another issue on the Kirkwood box is, that every time I connect successfully, the connection drops after 2 minutes with the following message in the logs
Nov 17 14:18:49 nas pppd[2725]: Terminating on signal 15
Nov 17 14:18:49 nas pppd[2725]: Connect time 2.0 minutes.


Top
 Profile  
 
 Post subject: Re: various issues
PostPosted: Wed Nov 17, 2010 10:38 pm 
Site Admin

Joined: Sun Jul 27, 2008 1:39 pm
Posts: 122
These problems sound like you haven't configured the IPSec policy in the kernel for L2TP packets. Also, if you are using ephemeral UDP ports for each connection, are you running openl2tpd with the ipsec.so plugin? And is setkey installed and working?

The big difference between xl2tpd and openl2tpd is that the former handles all data packets in userspace. Since openl2tpd uses the kernel for such stuff, it is important to configure the kernel's IPSec policies if you want to use IPSec with openl2tpd.

When you say occasional connections work, do they pass data?

Have you tried setting this up on a typical PC first, before trying to move the config over to the embedded boxes? It might give you better access to debugging facilities.

Regarding attachments, I remember our network admin guy disabled them a while ago when the forum was attacked by spammers. I'll see if we can enable it again.


Top
 Profile  
 
 Post subject: Re: various issues
PostPosted: Thu Nov 18, 2010 1:16 am 

Joined: Tue Oct 19, 2010 12:01 pm
Posts: 27
I'm using the 2.6 kernel's NETKEY ipsec support. If I understand correctly, ipsec.so plugin and setkey is only relevant to KLIPS; correct me if I'm wrong.

I'm not using ephemeral UDP ports, as I have included
tunnel profile modify profile_name=default \
our_udp_port=1701
in my /etc/open2ltpd.conf

When connections do initiate, all works fine. I'd be more than willing to post any debug information you need to pinpoint the cause of these initiation failures (where the L2TP response does not get tunneled through IPsec, but is send unencrypted to the peer).

As far as the other problem (disconnects after 2-3 minutes), I've found out it is correlated to disabling RPC support in open2ltpd (with L2TP_FEATURE_RPC_MANAGEMENT=n in Makefile). Recompiling with L2TP_FEATURE_RPC_MANAGEMENT=y fixes these. Seems to be a bug?


Top
 Profile  
 
 Post subject: Re: various issues
PostPosted: Thu Nov 18, 2010 2:27 pm 

Joined: Tue Oct 19, 2010 12:01 pm
Posts: 27
ok, my mistake on the ipsec.so part. Installing it fixes the connection initialisation failures. Connections now always initialise properly. To make ipsec.so work properly in debian, the
#define IPSEC_SETKEY_CMD "/sbin/setkey"
line in ./plugins/ipsec.c needs to be changed to
#define IPSEC_SETKEY_CMD "/usr/sbin/setkey"

even better would be if this location could be set through Makefile and overridden for Debian in ./debian/rules

ipsec-tools should be added as a package dependency in ./debian/control

and maybe it might be an idea to load ipsec.so by default by setting the following lines in ./debian/openl2tp-default
OPENL2TPD_ARGS="-p ipsec.so"
#OPENL2TPD_ARGS=

Still can't get ephemeral ports to work though! Should those work with the combination
2.6.32 kernel + openswan 2.6.28 + openl2tp 1.7 ?

Further more, I now see an additional issue:
- when I saturate the l2tp/ipsec connection, e.g. by doing a ftp transfer, the ipsec connection drops after a couple of minutes (and re-initialises). Might the saturating traffic over L2TP 'drown out' ipsec packets that check if the connection is still alive? Please tell me how I should check if this is the case! Thanks


Top
 Profile  
 
 Post subject: Re: various issues
PostPosted: Fri Nov 19, 2010 6:54 pm 

Joined: Tue Oct 19, 2010 12:01 pm
Posts: 27
al right, I did some more testing today. I got the following results:

without the ipsec.so plugin:
- when not configuring routing policies with setkey as described on the online manual, connections only initiate sporadically
- when using the following setkey rules, connections seem to always initiate properly:
spdadd 0.0.0.0/0 0.0.0.0/0[1701] udp -P out ipsec
esp/transport//require;

Further more, while the online manual (at http://www.openl2tp.org/doc/quick_start ) also recommends using the following setkey policy, it does not seem to be needed:
spdadd 192.168.1.4[1701] 0.0.0.0/0 udp -P in ipsec
esp/transport//require;

During connection initiations, the following always pops up in setkey -P -D automatically (does not need ipsec.so):
192.168.1.4[1701] 192.168.0.1[1701] udp
out prio high + 1073739744 ipsec
esp/transport//unique#16577
created: Nov 19 18:00:08 2010 lastused: Nov 19 18:00:09 2010
lifetime: 0(s) validtime: 0(s)
spid=3377 seq=1 pid=16406
refcnt=2
192.168.0.1[1701] 192.168.1.4[1701] udp
in prio high + 1073739744 ipsec
esp/transport//unique#16577
created: Nov 19 18:00:08 2010 lastused: Nov 19 18:00:12 2010
lifetime: 0(s) validtime: 0(s)
spid=3368 seq=2 pid=16406
refcnt=2

Is this due to how I configured openswan ?

with the ipsec.so plugin and not using ephemeral ports:
- when not configuring policies with setkey as described on the online manual, connections always seem to initiate properly

with the ipsec.so plugin and with ephemeral ports:
- no successful connections, whatever I try! I've tried using no manual setkey policies, as well as the following setkey rules:
spdadd 192.168.1.4[1701] 0.0.0.0/0 udp -P in ipsec
esp/transport//require;

spdadd 0.0.0.0/0 0.0.0.0/0[1701] udp -P out ipsec
esp/transport//require;

where 192.168.1.4 is the internal IP of the VPN server.


Top
 Profile  
 
 Post subject: Re: various issues
PostPosted: Fri Nov 19, 2010 7:09 pm 

Joined: Tue Oct 19, 2010 12:01 pm
Posts: 27
This is the output of /tmp/openl2tpd-tmp on such a failed ephemeral connection attempt:
spdadd -4n 192.168.1.4[53724] 192.168.0.1[1701] udp -P out ipsec esp/transport//require;
spdadd -4n 192.168.0.1[1701] 192.168.1.4[53724] udp -P in ipsec esp/transport//require;

And this is the output of setkey -P -D:
192.168.0.1[1701] 192.168.1.4[53724] udp
fwd prio def ipsec
esp/transport//require
created: Nov 19 18:18:41 2010 lastused:
lifetime: 0(s) validtime: 0(s)
spid=4122 seq=1 pid=17361
refcnt=2
192.168.0.1[1701] 192.168.1.4[53724] udp
in prio def ipsec
esp/transport//require
created: Nov 19 18:18:41 2010 lastused:
lifetime: 0(s) validtime: 0(s)
spid=4112 seq=2 pid=17361
refcnt=2
192.168.1.4[53724] 192.168.0.1[1701] udp
out prio def ipsec
esp/transport//require
created: Nov 19 18:18:41 2010 lastused: Nov 19 18:18:41 2010
lifetime: 0(s) validtime: 0(s)
spid=4105 seq=3 pid=17361
refcnt=3
192.168.1.4[1701] 192.168.0.1[1701] udp
out prio high + 1073739744 ipsec
esp/transport//unique#16649
created: Nov 19 18:18:40 2010 lastused:
lifetime: 0(s) validtime: 0(s)
spid=4097 seq=4 pid=17361
refcnt=2
192.168.0.1[1701] 192.168.1.4[1701] udp
in prio high + 1073739744 ipsec
esp/transport//unique#16649
created: Nov 19 18:18:40 2010 lastused: Nov 19 18:18:40 2010
lifetime: 0(s) validtime: 0(s)
spid=4088 seq=5 pid=17361
refcnt=3
0.0.0.0/0[any] 0.0.0.0/0[1701] udp
out prio def ipsec
esp/transport//require
created: Nov 19 18:16:54 2010 lastused: Nov 19 18:18:40 2010
lifetime: 0(s) validtime: 0(s)
spid=3921 seq=6 pid=17361
refcnt=1

Does this give any clue on why the ephemeral connections fail?


Top
 Profile  
 
 Post subject: Re: various issues
PostPosted: Mon Nov 22, 2010 12:20 am 

Joined: Tue Oct 19, 2010 12:01 pm
Posts: 27
scratch that, ephemeral ports seem to require a patched kernel, and patched ipsec-tools. The included patches are for very old versions, and they never seem to have been incorporated upstream :(
Further more I've noticed that both Windows Vista as well as the XP L2TP/IPsec client always connect from port 1701.

I'll focus on getting openl2tp to work reliably with just a single connection at a time for now...

I'm still insistent that OpenSwan should handle the ipsec policies through xfrm (no need for ipsec.so or setkey). They get added automatically on connection initiations, but don't always seem to work reliably; maybe the kernel is a bit buggy dealing with ipsec policies while using pppol2tp.
update: just a quick glance, might openswan need this patch too (it is based on the same code as StrongSwan)?
https://lists.strongswan.org/pipermail/ ... 00200.html
edit: seems like that patch did not get accepted either for merging with the upstream.

Consider this thread closed, as I'll try to summarize what's going on in a new one.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group