[Openswan Users] Openswan establishes IPSec, won't route to l2tpd
Joe Rhodes
lists at joerhodes.com
Mon Jul 22 00:48:48 UTC 2013
Hey all!
I realize this gets asked a lot, but none of the answers seem to be clearing things up for me.
I've got a CentOS 6.3 server (several of them, actually). I'm trying to setup an OpenSwan IPSec/L2TP VPN server for Mac, iOS, and Windows clients. I can get the IPSec part established, but using OpenSwan and NETKEY, I cannot get get any traffic to the L2TP server.
If I switch over to a racoon based IPSec (ipsec-tools), then it works fine. I'd like to use OpenSwan so I can, hopefully, have multiple VPN clients behind the same NAT device using SARef's.
I've read more than a few posts suggesting that it's often a firewall issue, but I cannot seem to figure out what might be blocking or not forwarding. And it's not clear why the same firewall would be working fine with racoon IPSec, but not with OpenSwan. I've even tried opening the firewall up completely. No change.
The machine has a public, static IP address. It serves as the firewall and router to the network I'd like to VPN into (private IP's of 10.1.1.0/24). The clients I'm using (OS X, Win 7, and iOS) are behind a standard home NAT firewall.
I'd appreciate any insights. I just can't seem to figure out what I'm missing here. Thanks!
-Joe Rhodes
The specifics:
CentOS 6.3
Kernel 2.6.32-279.11.1.el6.x86_64
openswan-2.6.32-20.el6_4.x86_64 (Though I've also complied the most recent from source and got the same results)
xl2tpd-1.3.1-7.el6.x86_64
The interesting bits of the logs.
/var/log/pluto.log
packet from 99.224.181.54:500: received Vendor ID payload [RFC 3947] method set to=109
packet from 99.224.181.54:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike] method set to=110
packet from 99.224.181.54:500: ignoring unknown Vendor ID payload [8f8d83826d246b6fc7a8a6a428c11de8]
packet from 99.224.181.54:500: ignoring unknown Vendor ID payload [439b59f8ba676c4c7737ae22eab8f582]
packet from 99.224.181.54:500: ignoring unknown Vendor ID payload [4d1e0e136deafa34c4f3ea9f02ec7285]
packet from 99.224.181.54:500: ignoring unknown Vendor ID payload [80d0bb3def54565ee84645d4c85ce3ee]
packet from 99.224.181.54:500: ignoring unknown Vendor ID payload [9909b64eed937c6573de52ace952fa6b]
packet from 99.224.181.54:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but already using method 110
packet from 99.224.181.54:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107, but already using method 110
packet from 99.224.181.54:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 110
packet from 99.224.181.54:500: ignoring Vendor ID payload [FRAGMENTATION 80000000]
packet from 99.224.181.54:500: received Vendor ID payload [Dead Peer Detection]
"L2TP-PSK-NAT"[5] 99.224.181.54 #5: responding to Main Mode from unknown peer 99.224.181.54
"L2TP-PSK-NAT"[5] 99.224.181.54 #5: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
"L2TP-PSK-NAT"[5] 99.224.181.54 #5: STATE_MAIN_R1: sent MR1, expecting MI2
"L2TP-PSK-NAT"[5] 99.224.181.54 #5: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike (MacOS X): peer is NATed
"L2TP-PSK-NAT"[5] 99.224.181.54 #5: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
"L2TP-PSK-NAT"[5] 99.224.181.54 #5: STATE_MAIN_R2: sent MR2, expecting MI3
"L2TP-PSK-NAT"[5] 99.224.181.54 #5: ignoring informational payload, type IPSEC_INITIAL_CONTACT msgid=00000000
"L2TP-PSK-NAT"[5] 99.224.181.54 #5: Main mode peer ID is ID_IPV4_ADDR: '192.168.200.18'
"L2TP-PSK-NAT"[5] 99.224.181.54 #5: switched from "L2TP-PSK-NAT" to "L2TP-PSK-NAT"
"L2TP-PSK-NAT"[6] 99.224.181.54 #5: deleting connection "L2TP-PSK-NAT" instance with peer 99.224.181.54 {isakmp=#0/ipsec=#0}
"L2TP-PSK-NAT"[6] 99.224.181.54 #5: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
"L2TP-PSK-NAT"[6] 99.224.181.54 #5: new NAT mapping for #5, was 99.224.181.54:500, now 99.224.181.54:4500
"L2TP-PSK-NAT"[6] 99.224.181.54 #5: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_256 prf=oakley_sha group=modp1024}
"L2TP-PSK-NAT"[6] 99.224.181.54 #5: Dead Peer Detection (RFC 3706): enabled
"L2TP-PSK-NAT"[6] 99.224.181.54 #5: the peer proposed: 50.50.21.66/32:17/1701 -> 192.168.200.18/32:17/0
"L2TP-PSK-NAT"[6] 99.224.181.54 #6: responding to Quick Mode proposal {msgid:126803ec}
"L2TP-PSK-NAT"[6] 99.224.181.54 #6: us: 50.50.21.66<50.50.21.66>[+S=C]:17/1701
"L2TP-PSK-NAT"[6] 99.224.181.54 #6: them: 99.224.181.54[192.168.200.18,+S=C]:17/62099===192.168.200.18/32
"L2TP-PSK-NAT"[6] 99.224.181.54 #6: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
"L2TP-PSK-NAT"[6] 99.224.181.54 #6: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
"L2TP-PSK-NAT"[6] 99.224.181.54 #6: Dead Peer Detection (RFC 3706): enabled
"L2TP-PSK-NAT"[6] 99.224.181.54 #6: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
"L2TP-PSK-NAT"[6] 99.224.181.54 #6: STATE_QUICK_R2: IPsec SA established transport mode {ESP=>0x02e99cda <0xd25bb5ee xfrm=AES_256-HMAC_SHA1 NATOA=none NATD=99.224.181.54:4500 DPD=enabled}
This last line leads me to believe that the IPSec part of things is established and working. After the OS X client gives up because it cannot contact the L2TP server, I see the following lines:
"L2TP-PSK-NAT"[6] 99.224.181.54 #5: received Delete SA(0x02e99cda) payload: deleting IPSEC State #6
"L2TP-PSK-NAT"[6] 99.224.181.54 #5: ERROR: netlink XFRM_MSG_DELPOLICY response for flow eroute_connection delete included errno 2: No such file or directory
"L2TP-PSK-NAT"[6] 99.224.181.54 #5: received and ignored informational message
"L2TP-PSK-NAT"[6] 99.224.181.54 #5: received Delete SA payload: deleting ISAKMP State #5
"L2TP-PSK-NAT"[6] 99.224.181.54: deleting connection "L2TP-PSK-NAT" instance with peer 99.224.181.54 {isakmp=#0/ipsec=#0}
packet from 99.224.181.54:4500: received and ignored informational message
and output from xl2tpd running in the foreground:
xl2tpd[18046]: IPsec SAref does not work with L2TP kernel mode yet, enabling forceuserspace=yes
xl2tpd[18046]: setsockopt recvref[30]: Protocol not available
xl2tpd[18046]: L2TP kernel support not detected (try modprobing l2tp_ppp and pppol2tp)
xl2tpd[18046]: xl2tpd version xl2tpd-1.3.1 started on server.adams PID:18046
xl2tpd[18046]: Written by Mark Spencer, Copyright (C) 1998, Adtran, Inc.
xl2tpd[18046]: Forked by Scott Balmos and David Stipp, (C) 2001
xl2tpd[18046]: Inherited by Jeff McAdams, (C) 2002
xl2tpd[18046]: Forked again by Xelerance (www.xelerance.com) (C) 2006
xl2tpd[18046]: Listening on IP address 0.0.0.0, port 1701
Complete silence after this. Nothing shows up. I've tried several options in the config file, as noted below. But same results. (If I use racoon/ipsec-tools, then I see the expected traffic.)
My ipsec.conf file:
version 2.0 # conforms to second version of ipsec.conf specification
config setup
protostack=netkey
nat_traversal=yes
virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!10.1.1.0/24
oe=off
plutostderrlog=/var/log/pluto.log
conn L2TP-PSK-NAT
rightsubnet=vhost:%priv,%no
also=L2TP-PSK-noNAT
conn L2TP-PSK-noNAT
authby=secret
pfs=no
auto=add
keyingtries=3
rekey=no
ikelifetime=8h
keylife=1h
type=transport
left=50.50.21.66
leftprotoport=udp/1701
right=%any
rightprotoport=udp/%any
dpddelay=40
dpdtimeout=130
dpdaction=clear
The internal IP address behind my server is 10.1.1.0/24. I've tried some derivations of the "rightprotoport=" line, including "udp/0" , "17/0", and "17/any".
The xl2tpd.conf file. Lines with a ";" have been tried, but with no change in results.
[global]
;listen-addr = 50.50.21.66
ipsec saref = yes
;force userspace = yes
debug tunnel = yes
[lns default]
ip range = 10.1.1.70-10.1.1.99
local ip = 10.1.1.5
require authentication = yes
name = LinuxVPNserver
ppp debug = yes
pppoptfile = /etc/ppp/options.xl2tpd
My firewall ruleset, including some experimental lines commented out:
#/sbin/iptables --table nat --append POSTROUTING -o $EXT -j MASQUERADE
#/sbin/iptables --table nat --append POSTROUTING -m policy --dir out --pol none -j MASQUERADE
/sbin/iptables --table nat --insert POSTROUTING -s 10.1.1.0/24 -m policy --dir out --pol ipsec -j ACCEPT
/sbin/iptables --table nat --append POSTROUTING -o $EXT -s 10.1.1.0/24 -j MASQUERADE
/sbin/iptables -A INPUT -i lo -p all -j ACCEPT
#Allow access by internal interface
/sbin/iptables -A INPUT -i $INT -p all -j ACCEPT
#Accept established connections
/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow VPN Traffic
/sbin/iptables -A INPUT -p udp --dport 4500 -j ACCEPT
/sbin/iptables -A INPUT -p udp --dport 500 -j ACCEPT
# Allow packets in to our L2TP server if they've been encrypted.
/sbin/iptables -IINPUT -p udp -m policy --strict --dir in --pol ipsec --proto esp -m udp --dport 1701 -j ACCEPT
#/sbin/iptables -I INPUT -p udp --dport 1701 -j ACCEPT
# Drop all other encrypted packets
#/sbin/iptables -A INPUT -m policy --strict --dir in --pol ipsec --proto esp -j REJECT
# Allow packets in that have come through a PPP interface (that is, through IPSec/L2TP)
/sbin/iptables -A INPUT -i ppp+ -j ACCEPT
######################################################################
# Default policy for all other traffic
######################################################################
#Make the default policy for all other packets DROP
#/sbin/iptables -P INPUT ACCEPT
/sbin/iptables -P INPUT DROP
#Turn on syn-cookies DOS protection
/bin/echo 1 > /proc/sys/net/ipv4/tcp_syncookies
For good measure, output from "ipsec verify"
[root at server ~]# ipsec verify
Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path [OK]
Linux Openswan U2.6.32/K2.6.32-279.11.1.el6.x86_64 (netkey)
Checking for IPsec support in kernel [OK]
SAref kernel support [N/A]
NETKEY: Testing for disabled ICMP send_redirects [OK]
NETKEY detected, testing for disabled ICMP accept_redirects [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]
Just to be thorough, here are the lines I use when using racoon/ipsec-tools to make L2TP traffic go over the VPN, and this works. I've omitted the racoon configuration, as it's not relevant. L2tp configuration is the same for both. Firewall rules are the same for both.
#!/bin/bash
# set security policies
echo -e "flush;\n\
spdflush;\n\
spdadd 0.0.0.0/0[0] 0.0.0.0/0[1701] udp -P in ipsec esp/transport//require;\n\
spdadd 0.0.0.0/0[1701] 0.0.0.0/0[0] udp -P out ipsec esp/transport//require;\n"\
| setkey -c
But I don't know if they're needed, necessary, or even looked at when using OpenSwan.
More information about the Users
mailing list