[Swan] Help configuring libreswan with XAUTH, NSS and remote clients (road warriors)

[Enrico Brunetta]

Paul,

I suspect it’s a routing/firewall issue, but I’m stuck trying to figure it out. 

As I stated originally, I had configured the VPN gateway on AWS to use pre-shared key like this:

my machine’s IP is 172.31.48.104

I wanted the l2tp to use 172.31.48.129 for the local IP and an IP range pool of 172.31.48.130-172.31.48.254


conn vpnpsk
  connaddrfamily=ipv4
  auto=add
  left=172.31.48.104
  leftid=54.84.104.104
  leftsubnet=172.31.48.104/32
  leftnexthop=%defaultroute
  leftprotoport=17/1701
  rightprotoport=17/%any
  right=%any
  rightsubnetwithin=0.0.0.0/0
  forceencaps=yes
  authby=secret
  pfs=no
  type=transport
  auth=esp
  ike=3des-sha1,aes-sha1
  phase2alg=3des-sha1,aes-sha1
  rekey=no
  keyingtries=5
  dpddelay=30
  dpdtimeout=120
  dpdaction=clear

root at ip-172-31-48-104:/etc# cat /etc/xl2tpd/xl2tpd.conf
[global]
port = 1701

[lns default]
ip range = 172.31.48.130-172.31.48.254
local ip = 172.31.48.129
require chap = yes
refuse pap = yes
require authentication = yes
name = l2tpd
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes

and these are my routes and iptables rules:

root at ip-172-31-48-104:/etc# netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         172.31.48.1     0.0.0.0         UG        0 0          0 eth0
172.31.48.0     0.0.0.0         255.255.240.0   U         0 0          0 eth0

root at ip-172-31-48-104:/etc# cat /etc/iptables.rules 
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:ICMPALL - [0:0]
:ZREJ - [0:0]
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp --icmp-type 255 -j ICMPALL
-A INPUT -p udp --dport 67:68 --sport 67:68 -j ACCEPT
-A INPUT -p tcp --dport 22 -j ACCEPT
-A INPUT -p udp -m multiport --dports 500,4500 -j ACCEPT
-A INPUT -p udp --dport 1701 -m policy --dir in --pol ipsec -j ACCEPT
-A INPUT -p udp --dport 1701 -j DROP
-A INPUT -j ZREJ
-A FORWARD -i eth+ -o ppp+ -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i ppp+ -o eth+ -j ACCEPT
-A FORWARD -j ZREJ
-A ICMPALL -p icmp --fragment -j DROP        
-A ICMPALL -p icmp --icmp-type 0 -j ACCEPT
-A ICMPALL -p icmp --icmp-type 3 -j ACCEPT
-A ICMPALL -p icmp --icmp-type 4 -j ACCEPT
-A ICMPALL -p icmp --icmp-type 8 -j ACCEPT
-A ICMPALL -p icmp --icmp-type 11 -j ACCEPT
-A ICMPALL -p icmp -j DROP
-A ZREJ -p tcp -j REJECT --reject-with tcp-reset 
-A ZREJ -p udp -j REJECT --reject-with icmp-port-unreachable
-A ZREJ -j REJECT --reject-with icmp-proto-unreachable
COMMIT
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 172.31.48.129/25 -o eth+ -j SNAT --to-source 172.31.48.104
COMMIT



I think now that l2tp is out of the question, I might have to change my fw rules?


Enrico.


On Sep 18, 2014, at 8:25 AM, Paul Wouters <paul at nohats.ca> wrote:

> On Thu, 18 Sep 2014, Enrico Brunetta wrote:
> 
>> Now it looks like the connection is found but it fails differently:
>> 
>> Sep 18 11:53:58 ip-172-31-48-104 pluto[2054]: Starting Pluto (Libreswan Version 3.10 XFRM(netkey) KLIPS NSS DNSSEC LIBCAP_NG XAUTH_PAM NETWORKMANAGER KLIPS_MAST CURL(non-NSS)) pid:2054
> 
>> Sep 18 11:54:07 ip-172-31-48-104 pluto[2054]: packet from 70.117.100.63:500: received Vendor ID payload [XAUTH]
>> Sep 18 11:54:07 ip-172-31-48-104 pluto[2054]: packet from 70.117.100.63:500: received Vendor ID payload [Cisco-Unity]
>> Sep 18 11:54:07 ip-172-31-48-104 pluto[2054]: packet from 70.117.100.63:500: received Vendor ID payload [FRAGMENTATION 80000000]
>> Sep 18 11:54:07 ip-172-31-48-104 pluto[2054]: packet from 70.117.100.63:500: received Vendor ID payload [Dead Peer Detection]
>> Sep 18 11:54:07 ip-172-31-48-104 pluto[2054]: "xauth-rsa"[1] 70.117.100.63 #1: enabling possible NAT-traversal with method RFC 3947 (NAT-Traversal)
>> Sep 18 11:54:07 ip-172-31-48-104 pluto[2054]: "xauth-rsa"[1] 70.117.100.63 #1: responding to Main Mode from unknown peer 70.117.100.63
>> Sep 18 11:54:07 ip-172-31-48-104 pluto[2054]: "xauth-rsa"[1] 70.117.100.63 #1: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
>> Sep 18 11:54:07 ip-172-31-48-104 pluto[2054]: "xauth-rsa"[1] 70.117.100.63 #1: STATE_MAIN_R1: sent MR1, expecting MI2
>> Sep 18 11:54:07 ip-172-31-48-104 pluto[2054]: "xauth-rsa"[1] 70.117.100.63 #1: NAT-Traversal: Result using RFC 3947 (NAT-Traversal) sender port 500: I am behind NAT+peer behind NAT
>> Sep 18 11:54:07 ip-172-31-48-104 pluto[2054]: "xauth-rsa"[1] 70.117.100.63 #1: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
>> Sep 18 11:54:07 ip-172-31-48-104 pluto[2054]: "xauth-rsa"[1] 70.117.100.63 #1: STATE_MAIN_R2: sent MR2, expecting MI3
>> Sep 18 11:54:17 ip-172-31-48-104 pluto[2054]: ERROR: asynchronous network error report on eth0 (sport=500) for message to 70.117.100.63 port 500, complainant 70.117.100.63: Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)]
> 
> This looks like a fragmentation issue, or MTU/firewall issue. Try
> ike-frag=force, as the cisco you are talking to seems to support
> FRAGMENTATION. If that fails, you can try to lower the mtu of your
> interface a little.
> 
> Paul