[Openswan Users] Amazon EC2 , Openswan , L2TP/IPSec

[Paul Wouters]

On Sun, 27 Feb 2011, Troy X wrote:

> Amazon Linux version 2.6.34.7-56.40.amzn1.x86_64  on EC2
> Linux Openswan U2.6.27
> xl2tpd version xl2tpd-1.2.8
> in addtion I modified Amazon security group settings to allow required UDP traffic

> config setup
>         protostack=netkey
>         nat_traversal=yes
>         virtual_private=%v4:192.168.2.0/24,%v4:!192.168.1.0/24

That's most certainly incomplete, as Amazon uses the 10.* range? You should use the
example from the man page for virtual_private that includes all of RFC1918 and
only exclude what you use inside yourself. If you are assigning 192.168.2.0/24 on
l2tp you want it to be not in virtual_private (eg using %v4:!192.168.2.0/24)


>         nhelpers=0
>         interfaces=%defaultroute
> 
> conn tons
>          auto=add
>          left=##EC2_IP##
>          leftid=##EC2_ELASTIC_IP##
>          leftsubnet=##EC2_IP##/32
>          leftnexthop=%defaultroute
>          leftprotoport=17/1701

The 1701 might not be true now since you are also behind some kind of NAT. Lets
hope the elastic ip keesp the port, because you cannot have both ends be 17/%any

>          rightprotoport=17/%any
>          right=%any
>          rightsubnet=vhost:%priv,%no
>          forceencaps=yes
>          authby=secret
>          pfs=no

> cat /etc/ipsec.secrets
> ---------------------------------------
> ##EC2_ELASTIC_IP## %any: PSK "MYPSKKEY"

I would also put your EC2_IP in there.

> cat /etc/xl2tpd/xl2tpd.conf
> ---------------------------------------
> [global]
>

Bind it to the amazon EC2_IP, I heard people have issues if not binding it
specifically.

> [lns default]
> ip range = 192.168.2.2-192.168.2.254
> local ip = 192.168.2.1
> require chap = yes
> refuse pap = yes
> require authentication = yes
> name = openSwanVPNserver
> ppp debug = yes
> pppoptfile = /etc/ppp/options.xl2tpd
> length bit = yes
> 
> 
> cat /etc/ppp/options.xl2tpd
> ---------------------------------------
> ipcp-accept-local
> ipcp-accept-remote
> noccp
> auth
> crtscts
> idle 1800
> mtu 1410
> mru 1410

I would make these 1200, not 1410.

> Feb 27 15:38:30 domU-XXXXX pluto[5598]: Starting Pluto (Openswan Version 2.6.27; Vendor ID OEnTNwILvV~\134)

> Feb 27 15:38:30 domU-XXXXX pluto[5598]: NAT-Traversal: Trying new style NAT-T
> Feb 27 15:38:30 domU-XXXXX pluto[5598]: NAT-Traversal: ESPINUDP(1) setup failed for new style NAT-T family
> IPv4 (errno=19)
> Feb 27 15:38:30 domU-XXXXX pluto[5598]: NAT-Traversal: Trying old style NAT-T

There were bugs in the NAT-T detection fixed in 2.6.33. Try to upgrade?

> Feb 27 16:04:46 domU-XXXXX pluto[5598]: "tons"[6] ##LAPTOP_IP## #16: STATE_QUICK_R2: IPsec SA established
> tunnel mode {ESP/NAT=>0x3c103329 <0xfdafa178 xfrm=AES_128-HMAC_SHA1 NATOA=192.168.2.3 NATD=##LAPTOP_IP##:4500
> DPD=none}

It looks like you come from 192.168.2.3 on your lpatop, then you can never assign l2tp addresses
from that range, because an IP can only live on one side of the tunnel.

> Feb 27 16:04:46 domU-XXXXX pluto[5598]: "tons"[6] ##LAPTOP_IP## #17: STATE_QUICK_R2: IPsec SA established
> tunnel mode {ESP/NAT=>0xf7ab2e5e <0x0e00bfa3 xfrm=AES_128-HMAC_SHA1 NATOA=192.168.2.3 NATD=##LAPTOP_IP##:4500
> DPD=none}
> Feb 27 16:04:46 domU-XXXXX pluto[5598]: "tons"[6] ##LAPTOP_IP## #15: received Delete SA(0x3c103329) payload:
> deleting IPSEC State #16

here ipsec works and immediately the clients hangs up. Likely due to failing to send packets due
to the clashing ip range.

Paul