[Openswan Users] openswan 2.6.35rc1 and xl2tpd-1.3.0rc1 pre-releases - please test

[Paul Wouters]

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

> 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