[Openswan Users] Openswan 2.6.14 Netkey xl2tpd not establishing tunnel
Joe Rhodes
lists at joerhodes.com
Mon Jul 21 19:32:43 EDT 2008
Hello everyone!
I'm trying to get a L2TP/IPsec setup working as described here:
http://www.jacco2.dds.nl/networking/freeswan-l2tp.html
Essentially, I've got an OpenSwan setup with a road warrior client.
In this case, it's a Mac OS X laptop. Unfortunately, the only option
I have is with the laptop (or an iPhone) behind a NAT router. The VPN
server is on the internet with no NAT between. I'm trying to get this
setup so I do not have to make any serious changes to remote client.
I'd like to use the built-in Windows or OS X VPN client software.
When I try to connect to the VPN server, I get a IPSec connection.
Well, it appears that I do from the log:
(/var/log/secure)
21 18:31:01 24-159-243-145 pluto[25270]: packet from
32.138.34.208:500: received Vendor ID payload [RFC 3947] method set
to=109
Jul 21 18:31:01 24-159-243-145 pluto[25270]: packet from
32.138.34.208:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-
ike] method set to=110
Jul 21 18:31:01 24-159-243-145 pluto[25270]: packet from
32.138.34.208:500: ignoring unknown Vendor ID payload
[8f8d83826d246b6fc7a8a6a428c11de8]
Jul 21 18:31:01 24-159-243-145 pluto[25270]: packet from
32.138.34.208:500: ignoring unknown Vendor ID payload
[439b59f8ba676c4c7737ae22eab8f582]
Jul 21 18:31:01 24-159-243-145 pluto[25270]: packet from
32.138.34.208:500: ignoring unknown Vendor ID payload
[4d1e0e136deafa34c4f3ea9f02ec7285]
Jul 21 18:31:01 24-159-243-145 pluto[25270]: packet from
32.138.34.208:500: ignoring unknown Vendor ID payload
[80d0bb3def54565ee84645d4c85ce3ee]
Jul 21 18:31:01 24-159-243-145 pluto[25270]: packet from
32.138.34.208:500: ignoring unknown Vendor ID payload
[9909b64eed937c6573de52ace952fa6b]
Jul 21 18:31:01 24-159-243-145 pluto[25270]: packet from
32.138.34.208:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-
ike-03] meth=108, but already using method 110
Jul 21 18:31:01 24-159-243-145 pluto[25270]: packet from
32.138.34.208:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-
ike-02] meth=107, but already using method 110
Jul 21 18:31:01 24-159-243-145 pluto[25270]: packet from
32.138.34.208:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-
ike-02_n] meth=106, but already using method 110
Jul 21 18:31:01 24-159-243-145 pluto[25270]: packet from
32.138.34.208:500: received Vendor ID payload [Dead Peer Detection]
Jul 21 18:31:01 24-159-243-145 pluto[25270]: "L2TP-PSK"[9]
32.138.34.208 #17: responding to Main Mode from unknown peer
32.138.34.208
Jul 21 18:31:01 24-159-243-145 pluto[25270]: "L2TP-PSK"[9]
32.138.34.208 #17: transition from state STATE_MAIN_R0 to state
STATE_MAIN_R1
Jul 21 18:31:01 24-159-243-145 pluto[25270]: "L2TP-PSK"[9]
32.138.34.208 #17: STATE_MAIN_R1: sent MR1, expecting MI2
Jul 21 18:31:01 24-159-243-145 pluto[25270]: "L2TP-PSK"[9]
32.138.34.208 #17: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-
ike (MacOS X): peer is NATed
Jul 21 18:31:01 24-159-243-145 pluto[25270]: "L2TP-PSK"[9]
32.138.34.208 #17: transition from state STATE_MAIN_R1 to state
STATE_MAIN_R2
Jul 21 18:31:01 24-159-243-145 pluto[25270]: "L2TP-PSK"[9]
32.138.34.208 #17: STATE_MAIN_R2: sent MR2, expecting MI3
Jul 21 18:31:02 24-159-243-145 pluto[25270]: "L2TP-PSK"[9]
32.138.34.208 #17: Main mode peer ID is ID_IPV4_ADDR: '10.149.152.83'
Jul 21 18:31:02 24-159-243-145 pluto[25270]: "L2TP-PSK"[9]
32.138.34.208 #17: transition from state STATE_MAIN_R2 to state
STATE_MAIN_R3
Jul 21 18:31:02 24-159-243-145 pluto[25270]: "L2TP-PSK"[2]
32.138.34.208 #3: new NAT mapping for #3, was 32.138.34.208:4500, now
32.138.34.208:4500
Jul 21 18:31:02 24-159-243-145 pluto[25270]: "L2TP-PSK"[4]
32.138.34.208 #8: new NAT mapping for #8, was 32.138.34.208:4500, now
32.138.34.208:4500
Jul 21 18:31:02 24-159-243-145 pluto[25270]: "L2TP-PSK"[5]
32.138.34.208 #11: new NAT mapping for #11, was 32.138.34.208:4500,
now 32.138.34.208:4500
Jul 21 18:31:02 24-159-243-145 pluto[25270]: "L2TP-PSK"[3]
32.138.34.208 #5: new NAT mapping for #5, was 32.138.34.208:4500, now
32.138.34.208:4500
Jul 21 18:31:02 24-159-243-145 pluto[25270]: "L2TP-PSK"[9]
32.138.34.208 #17: new NAT mapping for #17, was 32.138.34.208:500, now
32.138.34.208:4500
Jul 21 18:31:02 24-159-243-145 pluto[25270]: "L2TP-PSK"[8]
32.138.34.208 #13: new NAT mapping for #13, was 32.138.34.208:4500,
now 32.138.34.208:4500
Jul 21 18:31:02 24-159-243-145 pluto[25270]: "L2TP-PSK"[2]
32.138.34.208 #1: new NAT mapping for #1, was 32.138.34.208:4500, now
32.138.34.208:4500
Jul 21 18:31:02 24-159-243-145 pluto[25270]: "L2TP-PSK"[6]
32.138.34.208 #15: new NAT mapping for #15, was 32.138.34.208:4500,
now 32.138.34.208:4500
Jul 21 18:31:02 24-159-243-145 pluto[25270]: "L2TP-PSK"[9]
32.138.34.208 #17: STATE_MAIN_R3: sent MR3, ISAKMP SA established
{auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha
group=modp1024}
Jul 21 18:31:03 24-159-243-145 pluto[25270]: "L2TP-PSK"[9]
32.138.34.208 #17: ignoring informational payload, type
IPSEC_INITIAL_CONTACT msgid=00000000
Jul 21 18:31:03 24-159-243-145 pluto[25270]: "L2TP-PSK"[9]
32.138.34.208 #17: received and ignored informational message
Jul 21 18:31:04 24-159-243-145 pluto[25270]: "L2TP-PSK"[9]
32.138.34.208 #17: the peer proposed: 24.159.243.145/32:17/1701 ->
10.149.152.83/32:17/49181
Jul 21 18:31:04 24-159-243-145 pluto[25270]: "L2TP-PSK"[9]
32.138.34.208 #17: alloc_bytes1() was mistakenly asked to malloc 0
bytes for st_skey_ar in duplicate_state, please report to dev at openswan.org
Jul 21 18:31:04 24-159-243-145 pluto[25270]: "L2TP-PSK"[9]
32.138.34.208 #17: alloc_bytes1() was mistakenly asked to malloc 0
bytes for st_skey_er in duplicate_state, please report to dev at openswan.org
Jul 21 18:31:04 24-159-243-145 pluto[25270]: "L2TP-PSK"[9]
32.138.34.208 #17: alloc_bytes1() was mistakenly asked to malloc 0
bytes for st_skey_pi in duplicate_state, please report to dev at openswan.org
Jul 21 18:31:04 24-159-243-145 pluto[25270]: "L2TP-PSK"[9]
32.138.34.208 #17: alloc_bytes1() was mistakenly asked to malloc 0
bytes for st_skey_pr in duplicate_state, please report to dev at openswan.org
Jul 21 18:31:04 24-159-243-145 pluto[25270]: "L2TP-PSK"[10]
32.138.34.208 #18: responding to Quick Mode proposal {msgid:e0932a8d}
Jul 21 18:31:04 24-159-243-145 pluto[25270]: "L2TP-PSK"[10]
32.138.34.208 #18: us: 24.159.243.145[+S=C]:17/1701
Jul 21 18:31:04 24-159-243-145 pluto[25270]: "L2TP-PSK"[10]
32.138.34.208 #18: them: 32.138.34.208[10.149.152.83,+S=C]:
17/49182===10.149.152.83/32
Jul 21 18:31:04 24-159-243-145 pluto[25270]: "L2TP-PSK"[10]
32.138.34.208 #18: transition from state STATE_QUICK_R0 to state
STATE_QUICK_R1
Jul 21 18:31:04 24-159-243-145 pluto[25270]: "L2TP-PSK"[10]
32.138.34.208 #18: STATE_QUICK_R1: sent QR1, inbound IPsec SA
installed, expecting QI2
Jul 21 18:31:05 24-159-243-145 pluto[25270]: "L2TP-PSK"[10]
32.138.34.208 #18: transition from state STATE_QUICK_R1 to state
STATE_QUICK_R2
Jul 21 18:31:05 24-159-243-145 pluto[25270]: "L2TP-PSK"[10]
32.138.34.208 #18: STATE_QUICK_R2: IPsec SA established transport mode
{ESP=>0x02ce1055 <0x873b3538 xfrm=AES_128-HMAC_SHA1 NATOA=<invalid>
NATD=<invalid>:4500 DPD=enabled}
The L2TPD server seems to get a request from the client to establish a
tunnel, but it's as though the answer never gets the client. The
client just keeps requesting the tunnel over and over and eventually
gives up:
(from the xl2tpd debug log)
xl2tpd[25432]: network_thread: recv packet from 32.138.34.208, size =
60, tunnel = 0, call = 0 ref=0 refhim=0
xl2tpd[25432]: get_call: allocating new tunnel for host 32.138.34.208,
port 49181.
xl2tpd[25432]: network_thread: recv packet from 32.138.34.208, size =
60, tunnel = 0, call = 0 ref=0 refhim=0
xl2tpd[25432]: get_call: allocating new tunnel for host 32.138.34.208,
port 49181.
xl2tpd[25432]: control_finish: Peer requested tunnel 30 twice,
ignoring second one.
xl2tpd[25432]: build_fdset: closing down tunnel 37757
xl2tpd[25432]: network_thread: recv packet from 32.138.34.208, size =
60, tunnel = 0, call = 0 ref=0 refhim=0
xl2tpd[25432]: get_call: allocating new tunnel for host 32.138.34.208,
port 49181.
xl2tpd[25432]: control_finish: Peer requested tunnel 30 twice,
ignoring second one.
xl2tpd[25432]: build_fdset: closing down tunnel 24854
xl2tpd[25432]: network_thread: recv packet from 32.138.34.208, size =
60, tunnel = 0, call = 0 ref=0 refhim=0
xl2tpd[25432]: get_call: allocating new tunnel for host 32.138.34.208,
port 49181.
xl2tpd[25432]: control_finish: Peer requested tunnel 30 twice,
ignoring second one.
xl2tpd[25432]: build_fdset: closing down tunnel 8902
xl2tpd[25432]: Maximum retries exceeded for tunnel 58740. Closing.
xl2tpd[25432]: build_fdset: closing down tunnel 58740
xl2tpd[25432]: Connection 30 closed to 32.138.34.208, port 49181
(Timeout)
Below are my relevant config files. Does anyone have any ideas?
I'm running CentOS 5.2 with a custom compiled 2.6.25.2 kernel with the
IPSec and NAT-T options enabled.
version 2.0 # conforms to second version of ipsec.conf specification
# basic configuration
config setup
# Debug-logging controls: "none" for (almost) none, "all" for lots.
#klipsdebug=none
# plutodebug="control parsing"
# For Red Hat Enterprise Linux and Fedora, leave protostack=netkey
protostack=netkey
#plutodebug="all"
interfaces=%defaultroute
#forwardcontrol=yes
nat_traversal=yes
virtual_private=
%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16,%v4:!10.0.6.0/24
# My private subnet behind the VPN is 10.0.6.0/24
conn %default
keyingtries=1
compress=no
disablearrivalcheck=no
authby=secret
conn L2TP-PSK
#
authby=secret
pfs=no
rekey=no
keyingtries=3
#
# ----------------------------------------------------------
# The VPN server.
#
# Allow incoming connections on the external network interface.
# If you want to use a different interface or if there is no
# defaultroute, you can use: left=your.ip.addr.ess
#
left=%defaultroute
#
leftprotoport=17/1701
# If you insist on supporting non-updated Windows clients,
# you can use: leftprotoport=17/%any
#
# ----------------------------------------------------------
# The remote user(s).
#
# Allow incoming connections only from this IP address.
right=%any
# If you want to allow multiple connections from any IP
address,
# you can use: right=%any
#
rightprotoport=17/%any
auto=add
rightsubnet=vhost:%no,%priv
type=transport # I've tried this both with and without the transport
type. Without I get a tunnel, but the same results
My xl2tpd.conf file:
debug tunnel = yes
; debug avp = yes
debug network = yes
[lns default]
ip range = 10.0.6.200-10.0.6.250
local ip = 10.0.6.2
require chap = yes
refuse pap = yes
require authentication = yes
name = LinuxVPNserver
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes
And my firewall settings:
######################################################################
# Variables
######################################################################
# $EXT is the untrusted external interface from our ISP
# $INT is the trusted internal interface
INT="eth0"
EXT="eth1"
INT_IP="10.0.6.1"
######################################################################
# Setup
######################################################################
#Tell the kernel to forward packets
/bin/echo 1 > /proc/sys/net/ipv4/ip_forward
#Install FTP helper module
/sbin/modprobe nf_nat_ftp
#Delete and flush. Default table is "filter". Others like "nat" must
be
#explicity stated.
/sbin/iptables --flush
/sbin/iptables --table nat --flush
/sbin/iptables --table mangle --flush
/sbin/iptables --delete-chain
/sbin/iptables --table nat --delete-chain
######################################################################
# Basic Network Address Translation
######################################################################
/sbin/iptables --table nat --append POSTROUTING -s 10.0.6.0/24 -d
10.149.153.0/24 -j ACCEPT
/sbin/iptables --table nat --append POSTROUTING -o $EXT -d !
10.0.0.0/255.0.0.0 -j MASQUERADE
######################################################################
# Allowing/Disallowing Traffic
######################################################################
# Here we allow certain traffic in. All other traffic is blocked
# by the default action specified below.
# Note: We are ONLY talking about incoming traffic (from the server's
# point of view).
#Allow ping packets in through all interfaces
/sbin/iptables -A INPUT -p icmp -j ACCEPT
#Allow self access by loopback interface
/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
# Allow access by packets that have been through PPTP VPN interface
/sbin/iptables -A INPUT -i ppp+ -p all -j ACCEPT
# Allow access by packets that have gone through IPSEC
/sbin/iptables -A INPUT -m policy --dir in --pol ipsec -j ACCEPT
#Accept established connections
/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
#Open secure shell port
/sbin/iptables -A INPUT -p tcp --dport 22 -j ACCEPT
#Open IPSEC traffic
/sbin/iptables -A INPUT -p 50 -j ACCEPT
/sbin/iptables -A INPUT -p 51 -j ACCEPT
/sbin/iptables -A INPUT -p udp --dport 500 -j ACCEPT
/sbin/iptables -A INPUT -p udp --dport 4500 -j ACCEPT
######################################################################
# Default policy for all other traffic
######################################################################
#Make the default policy for all other packets DROP
/sbin/iptables -P INPUT ACCEPT #For testing purposes, I've
essentially opened up the firewall entirely
/sbin/iptables -P FORWARD ACCEPT
Any help would be greatly appreciated!
Thanks!
-Joe Rhodes
More information about the Users
mailing list