[Openswan Users] openswan 2.6.35rc1 and xl2tpd-1.3.0rc1 pre-releases - please test
Curu Wong
prinbra at gmail.com
Sat Jul 23 03:18:22 EDT 2011
Thank you very much, Paul.
I used to setup l2tp-ipsec tunnels using x509, and I thought that with PSK,
only one connection can up at the same time, so I used two connection
xl2tp-gw1 and xl2tp-gw2 for test. In fact, I was wondering, if we can not
use PSK with multiple client at the same time, how can microsoft's vpn
server accomplish that?
Given your advice, I have adjust my config to this(removed all the former
conns)
=======================================================
conn l2tp-ipsec
left=S.S.S.S
leftprotoport=17/1701
right=%any
rightprotoport=17/%any
rightsubnet=vhost:%no,%priv
pfs=no
rekey=no
#for SAref + MAST
sareftrack=yes
overlapip=yes
#dead peer detection
dpddelay=30
dpdtimeout=120
dpdaction=clear
#l2tp works in transport
type=transport
authby=secret
auto=add
===================================================
In fact, the one big mistake I've made is that you pointed out.
>
>You have not fully disabled rp_filter. Please do so in /etc/sysctl.conf and
optionally
to fix the current assignments
fix it with
============================================================
for i in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 0 > $i; done
============================================================
Then, restart the tunnel, problem solved! About half year ago, when I was
playing with klips, I've noticed how important a role rp_filter plays when
use klips(my blog post
http://www.linuxplayer.org/2011/02/openswan-use-the-klips-stack/). But I
forgot this time! Forgive me for not found/saw the wiki doc:
>
https://gsoc.xelerance.com/projects/openswan/wiki/L2TPIPsec_configuration_using_openswan_and_xl2tpd
But I have a suggestion, can we add the check of rp_filter to "ipsec verify"
when running with klips/mast stack? Because that may help some newbies who
can't/doesn't find a proper doc/guide for their initial config.
Finally, I confirmed the test passed for my scenaro:
=============================================================================
xp1(192.168.9.106)------>NAT GW1(A.A.A.A)----------l2tp/ipsec VPN
GW(eth0:S.S.S.S)
| |_(eth1:192.168.6.18/24)
xp2(192.168.9.106)------>NAT GW2(B.B.B.B) ___________|
after successfully connection, xp1 get ip 192.168.6.128, xp2 get ip
192.168.6.129, I can successfully ping each
other(to confirm that the two tunnels with PSK can be up at the same time)
==============================================================================
I also tested in the following environment,with nearly the same network
topology as the above(tell the difference later)
====================================================
CentOS 6.0
vanilla kernel 2.6.35.13 with SAref patch
#ipsec verify
Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path [OK]
Linux Openswan 2.6.35rc1 (klips)
Checking for IPsec support in kernel [OK]
KLIPS: checking for NAT Traversal support [OK]
KLIPS: checking for OCF crypto offload support [OK]
Kernel: IPsec SAref kernel support [OK]
Kernel: IPsec SAref Bind kernel support [OK]
Checking that pluto is running [OK]
Pluto listening for IKE on udp 500 [OK]
Pluto listening for NAT-T on udp 4500 [OK]
Two or more interfaces found, checking IP forwarding [OK]
Checking NAT and MASQUERADEing [OK]
Checking for 'ip' command [OK]
Checking /bin/sh is not /bin/dash [OK]
Checking for 'iptables' command [OK]
Opportunistic Encryption Support [DISABLED]
====================================================
The topology difference between the centos one and the ubuntu one is that on
centos
it's eth0 is external interface, just opposite of ubuntu
========================================================================
xp1(192.168.9.106)------>NAT GW1(A.A.A.A)----------l2tp/ipsec VPN GW(*eth1*
:S.S.S.S)
| |_(*eth0*:192.168.6.18/24)
xp2(192.168.9.106)------>NAT GW2(B.B.B.B) ___________|
========================================================================
openswan and xl2tpd configuration is completely identical. However, it
failed.
check /var/log/secure, it confirms that IPSec SA can be established without
any problem.
check /var/log/messages about xl2tpd's log message
=======================================================================
Jul 23 14:37:50 localhost xl2tpd[5299]: Enabling IPsec SAref processing for
L2TP transport mode SAs
Jul 23 14:37:50 localhost xl2tpd[5299]: IPsec SAref does not work with L2TP
kernel mode yet, enabling forceuserspace=yes
Jul 23 14:37:50 localhost xl2tpd[5299]: IPsec SAref does not work with L2TP
kernel mode yet, enabling forceuserspace=yes
Jul 23 14:37:50 localhost xl2tpd[5299]: This binary does not support kernel
L2TP.
Jul 23 14:37:50 localhost xl2tpd[5299]: This binary does not support kernel
L2TP.
Jul 23 14:37:50 localhost xl2tpd[5300]: xl2tpd version xl2tpd-1.3.0rc1
started on localhost.localdomain PID:5300
Jul 23 14:37:50 localhost xl2tpd[5300]: xl2tpd version xl2tpd-1.3.0rc1
started on localhost.localdomain PID:5300
Jul 23 14:37:50 localhost xl2tpd[5300]: Written by Mark Spencer, Copyright
(C) 1998, Adtran, Inc.
Jul 23 14:37:50 localhost xl2tpd[5300]: Written by Mark Spencer, Copyright
(C) 1998, Adtran, Inc.
Jul 23 14:37:50 localhost xl2tpd[5300]: Forked by Scott Balmos and David
Stipp, (C) 2001
Jul 23 14:37:50 localhost xl2tpd[5300]: Forked by Scott Balmos and David
Stipp, (C) 2001
Jul 23 14:37:50 localhost xl2tpd[5300]: Inherited by Jeff McAdams, (C) 2002
Jul 23 14:37:50 localhost xl2tpd[5300]: Inherited by Jeff McAdams, (C) 2002
Jul 23 14:37:50 localhost xl2tpd[5300]: Forked again by Xelerance (
www.xelerance.com) (C) 2006
Jul 23 14:37:50 localhost xl2tpd[5300]: Forked again by Xelerance (
www.xelerance.com) (C) 2006
Jul 23 14:37:50 localhost xl2tpd[5300]: Listening on IP address 0.0.0.0,
port 1701
Jul 23 14:37:50 localhost xl2tpd[5300]: Listening on IP address 0.0.0.0,
port 1701
Jul 23 14:38:21 localhost xl2tpd[5300]: Maximum retries exceeded for tunnel
61483. Closing.
Jul 23 14:38:21 localhost xl2tpd[5300]: Maximum retries exceeded for tunnel
61483. Closing.
Jul 23 14:38:21 localhost xl2tpd[5300]: Connection 18 closed to
192.168.9.106, port 1701 (Timeout)
Jul 23 14:38:21 localhost xl2tpd[5300]: Connection 18 closed to
192.168.9.106, port 1701 (Timeout)
Jul 23 14:38:36 localhost xl2tpd[5300]: Maximum retries exceeded for tunnel
55277. Closing.
Jul 23 14:38:36 localhost xl2tpd[5300]: Maximum retries exceeded for tunnel
55277. Closing.
Jul 23 14:38:36 localhost xl2tpd[5300]: Connection 18 closed to
192.168.9.106, port 1701 (Timeout)
Jul 23 14:38:36 localhost xl2tpd[5300]: Connection 18 closed to
192.168.9.106, port 1701 (Timeout)
=======================================================================
Then I do a tcpdum on mast0 interface of this failed connection, and then
another tcpdump of the worked one on ubuntu, and noticed that
for the failed one:
==========================================================================
#source destination protocol info
192.168.9.106 S.S.S.S L2TP Control Message -
SCCRQ (tunnel id=0, session id=0)
192.168.6.18 192.168.9.106 L2TP Control Message - SCCRP
(tunnel id=14, session id=0)
192.168.6.18 192.168.9.106 L2TP Control Message - ZLB
(tunnel id=14, session id=0)
#seems server's reply message can't reach client, it keep resending
192.168.6.18 192.168.9.106 L2TP Control Message - SCCRP
(tunnel id=14, session id=0)
192.168.6.18 192.168.9.106 L2TP Control Message - SCCRP
(tunnel id=14, session id=0)
192.168.6.18 192.168.9.106 L2TP Control Message - SCCRP
(tunnel id=14, session id=0)
#client request again...
192.168.9.106 S.S.S.S L2TP Control Message -
SCCRQ (tunnel id=0, session id=0)
...
============================================================================
worked one:
==========================================================================
No. time source destination protocol info
2 0.995671 192.168.9.106 S.S.S.S L2TP Control Message
- SCCRQ (tunnel id=0, session id=0)
3 2.000284 S.S.S.S 192.168.9.106 L2TP Control Message
- SCCRP (tunnel id=15, session id=0)
4 2.000436 S.S.S.S 192.168.9.106 L2TP Control Message
- ZLB (tunnel id=15, session id=0)
5 2.035904 192.168.9.106 S.S.S.S L2TP Control Message
- SCCCN (tunnel id=30282, session id=0)
6 2.035969 S.S.S.S 192.168.9.106 L2TP Control Message
- ZLB (tunnel id=15, session id=0)
============================================================================
the l2tp/ipsec gateway's internal IP 192.168.6.18 is not involved here!
Then I change /etc/xl2tpd/xl2tpd.conf on centos, set
listen-addr = S.S.S.S
restart xl2tpd, then everything works fine, just like the ubuntu one.
One more thing, no matter with ubuntu or CentOS, there's always this error
message whenever ipsec service restarted
I don't know if it matters:
====================================================
Jul 23 11:27:34 tvpn pluto[13271]: ERROR: PF_KEY K_SADB_X_PLUMBIF response
for configure_mast_device included errno 17: File exists
2011/7/23 Paul Wouters <paul at xelerance.com>
> On Sat, 23 Jul 2011, Curu Wong wrote:
>
> For using xl2tpd and openswan as an L2TP/IPsec server, please see:
>
> https://gsoc.xelerance.com/**projects/openswan/wiki/**
> L2TPIPsec_configuration_using_**openswan_and_xl2tpd<https://gsoc.xelerance.com/projects/openswan/wiki/L2TPIPsec_configuration_using_openswan_and_xl2tpd>
>
>
> I can not get this work. mainly openswan issue, not xl2tpd.
>>
>
> conn xl2tp-gw1
>> right=A.A.A.A
>> rightid=@xp1
>> also=xl2tp-common
>> auto=add
>>
>> conn xl2tp-gw2
>> right=B.B.B.B
>> rightid=@vm-xpsp3
>> also=xl2tp-common
>> auto=add
>>
>> Note those will never establish because l2tp does not work like that.
>
>
>
> conn xl2tp-common
>> left=%defaultroute
>> rightprotoport=17/%any
>> rightsubnet=vhost:%no,%priv
>> leftprotoport=17/1701
>> pfs=no
>> rekey=yes
>> keyingtries=3
>> type=transport
>> sareftrack=yes
>> overlapip=yes
>> dpddelay=30
>> dpdtimeout=120
>> dpdaction=clear
>> authby=secret
>>
>
> Change left= to be the actual IP on the public interface.
> Change rekey to no.
>
>
> the problem is:
>> if I use protostack=auto or protostack=klips, then client xp1 behind
>> gw1(A.A.A.A) ( IP: 192.168.9.106), vm-xpsp3 behind
>> gw2(B.B.B.B) (IP: 192.168.9.106) can connect to the l2tp server without
>> any problem, but, the can not connect at the same time. if
>> one client connect in, the other will be kicked out because of overlapip.
>>
>> However, when I set protostack=mast, tunnel mode can't be established,
>> only transport can. Also, the command
>> ipsec -t mangle -L shows nothing about the IPSEC chain. seems that
>> _updown.mast is never get called.
>>
>
> _updown.mast is only called when a successfull tunnel has come up.
>
> Looking through the barf.....
>
> + _________________________ /proc/sys/net/ipv4/conf/star-**rp_filter
> + cd /proc/sys/net/ipv4/conf
> + egrep '^' all/rp_filter default/rp_filter eth0/rp_filter eth1/rp_filter
> ipsec0/rp_filter lo/rp_filter mast0/rp_filter
> all/rp_filter:1
> default/rp_filter:1
> eth0/rp_filter:1
> eth1/rp_filter:1
> ipsec0/rp_filter:1
> lo/rp_filter:1
> mast0/rp_filter:1
>
> You have not fully disabled rp_filter. Please do so in /etc/sysctl.conf and
> optionally
> to fix the current assignments, run:
>
> for i in /proc/sys/net/conf/*
> do
> echo 0 > $i/rp_filter
> done
>
> Jul 23 06:26:46 tvpn pluto[10304]: SAref support [enabled]
> Jul 23 06:26:46 tvpn pluto[10304]: SAbind support [enabled]
>
> good. SAref works.....
>
> Jul 23 06:27:05 tvpn pluto[10304]: | find_host_connection2 returns
> xl2tp-gw1
> Jul 23 06:27:05 tvpn pluto[10304]: "xl2tp-gw1"[1] A.A.A.A #1: responding to
> Main Mode from unknown peer A.A.A.A
>
> That worries me. I strongly recommend removing the two xl2tpd-gw
> connections and just
> have one proper connection for l2tp-ipsec. What happens now it has to
> correct
> itself later to pick the right configuration....
>
> Jul 23 06:27:05 tvpn pluto[10304]: "xl2tp-gw1"[1] A.A.A.A #1: Main mode
> peer ID is ID_FQDN: '@xp1'
>
> that is a windows box? I would not expect an ID_FQDN, but an ID_IPV4.
>
> Jul 23 06:27:05 tvpn pluto[10304]: "xl2tp-gw1"[1] A.A.A.A #1: transition
> from state STATE_MAIN_R2 to state STATE_MAIN_R3
>
> It's still on the wrong connection....
>
> Jul 23 06:27:05 tvpn pluto[10304]: "xl2tp-gw1"[1] A.A.A.A #1:
> STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY
> cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp2048}
>
> phase1 is up.
>
> Jul 23 06:27:05 tvpn pluto[10304]: "xl2tp-gw1"[1] A.A.A.A #1: IDci was
> FQDN: :@\224l, using NAT_OA=192.168.9.106/32 0 as IDci
> Jul 23 06:27:05 tvpn pluto[10304]: "xl2tp-gw1"[1] A.A.A.A #1: the peer
> proposed: S.S.S.108/32:17/1701 -> 192.168.9.106/32:17/0
>
> Hmm that FQDN looks odd...
>
> Jul 23 06:27:05 tvpn pluto[10304]: "xl2tp-gw1"[1] A.A.A.A #2:
> STATE_QUICK_R2: IPsec SA established transport mode {ESP=>0x4c86814f
> <0x8a1db925 xfrm=3DES_0-HMAC_MD5 NATOA=192.168.9.106 NATD=A.A.A.A:4500
> DPD=none}
>
> but you get phase2 up. At this point packets on udp port 1701 should be
> able to flow, though I'm not happy
> it picked xl2tp-gw1, which is not the "real" client configuration.
>
> Jul 23 06:43:47 tvpn pluto[10304]: packet from 222.96.156.23:500: ignoring
> Delete SA payload: not encrypted
>
> Then it seems your end hangs up, possible due to an L2TP auth error (or
> because no packets can flow)
>
> Try removing your 3 conns, and just have:
>
> conn xl2tp-psk
> right=%any
> left=A.A.A.A
>
> rightprotoport=17/%any
> rightsubnet=vhost:%no,%priv
> leftprotoport=17/1701
> pfs=no
> rekey=yes
> keyingtries=3
> type=transport
> sareftrack=yes
> overlapip=yes
> #dead peer detection
>
> dpddelay=30
> dpdtimeout=120
> dpdaction=clear
> authby=secret
>
> Thanks for testing!
>
> Paul
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20110723/55b1c0d6/attachment-0001.html
More information about the Users
mailing list