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@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@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@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 <[email protected]> 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 _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
