[Openswan Users] iPhone both ends NATed
Rich Goodin
rich at goodin.com
Wed Nov 19 11:31:58 EST 2008
Hi All,
I'm trying to connect an iPhone to an Openswan/xl2tp VPN. The VPN
endpoint is behind a linksys WRT54G with IPSEC passthrough enabled. It
appears from the logs that the IPSEC transport connection is
established but the xl2tpd traffic is not getting through. Any idea
what I'm missing?
Rich Goodin
The setup is as follows:
iPhone <---> internet <------> 66.57.62.130 Linksys 10.33.3.1
<--------->10.33.3.2 VPN Server
/etc/ipsec.conf:
# /etc/ipsec.conf - Openswan IPsec configuration file
#
# Manual: ipsec.conf.5
#
# Please place your own config files in /etc/ipsec.d/ ending in .conf
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
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.33.3.0/24
include /etc/ipsec.d/*.conf
include /etc/ipsec.d/examples/no_oe.conf
/etc/ipsec.d/L2TP-PSK.conf:
conn L2TP-PSK
#
authby=secret
pfs=no
rekey=no
keyingtries=3
type=transport
#
# ----------------------------------------------------------
# The VPN server.
#
left=10.33.3.2
leftsourceip=66.57.62.130
leftprotoport=17/1701
leftnexthop=10.33.3.1
#
# ----------------------------------------------------------
# The remote user(s).
#
right=%any
rightsubnet=vhost:%no,%priv
rightprotoport=17/%any
#
# ----------------------------------------------------------
#
auto=add
/etc/xl2tpd/xl2tpd.conf:
;
; This is a minimal sample xl2tpd configuration file for use
; with L2TP over IPsec.
;
; The idea is to provide an L2TP daemon to which remote Windows L2TP/
IPsec
; clients connect. In this example, the internal (protected) network
; is 192.168.1.0/24. A special IP range within this network is reserved
; for the remote clients: 192.168.1.128/25
; (i.e. 192.168.1.128 ... 192.168.1.254)
;
; The listen-addr parameter can be used if you want to bind the L2TP
daemon
; to a specific IP address instead of to all interfaces. For instance,
; you could bind it to the interface of the internal LAN (e.g.
192.168.1.98
; in the example below). Yet another IP address (local ip, e.g.
192.168.1.99)
; will be used by xl2tpd as its address on pppX interfaces.
[global]
; listen-addr = 192.168.1.98
;
; requires openswan-3.1 or higher
; ipsec saref = yes
;
; debug tunnel = yes
debug avp = yes
debug network = yes
debug packet = yes
debug state = yes
debug tunnel = yes
[lns default]
ip range = 10.33.3.128-10.33.3.254
local ip = 10.33.3.99
require chap = yes
refuse pap = yes
require authentication = no
name = LinuxVPNserver
ppp debug = yes
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes
/etc/ppp/options.xl2tpd:
ipcp-accept-local
ipcp-accept-remote
ms-dns 10.33.3.2
ms-wins 10.33.3.2
noccp
auth
crtscts
idle 1800
mtu 1410
mru 1410
nodefaultroute
debug
lock
proxyarp
connect-delay 5000
/var/log/secure:
Nov 19 11:26:15 goodin pluto[9878]: packet from 166.193.133.118:500:
received Vendor ID payload [RFC 3947] method set to=109
Nov 19 11:26:15 goodin pluto[9878]: packet from 166.193.133.118:500:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike] method set
to=110
Nov 19 11:26:15 goodin pluto[9878]: packet from 166.193.133.118:500:
ignoring unknown Vendor ID payload [8f8d83826d246b6fc7a8a6a428c11de8]
Nov 19 11:26:15 goodin pluto[9878]: packet from 166.193.133.118:500:
ignoring unknown Vendor ID payload [439b59f8ba676c4c7737ae22eab8f582]
Nov 19 11:26:15 goodin pluto[9878]: packet from 166.193.133.118:500:
ignoring unknown Vendor ID payload [4d1e0e136deafa34c4f3ea9f02ec7285]
Nov 19 11:26:15 goodin pluto[9878]: packet from 166.193.133.118:500:
ignoring unknown Vendor ID payload [80d0bb3def54565ee84645d4c85ce3ee]
Nov 19 11:26:15 goodin pluto[9878]: packet from 166.193.133.118:500:
ignoring unknown Vendor ID payload [9909b64eed937c6573de52ace952fa6b]
Nov 19 11:26:15 goodin pluto[9878]: packet from 166.193.133.118:500:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108,
but already using method 110
Nov 19 11:26:15 goodin pluto[9878]: packet from 166.193.133.118:500:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107,
but already using method 110
Nov 19 11:26:15 goodin pluto[9878]: packet from 166.193.133.118:500:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106,
but already using method 110
Nov 19 11:26:15 goodin pluto[9878]: packet from 166.193.133.118:500:
received Vendor ID payload [Dead Peer Detection]
Nov 19 11:26:15 goodin pluto[9878]: "L2TP-PSK"[2] 166.193.133.118 #3:
responding to Main Mode from unknown peer 166.193.133.118
Nov 19 11:26:15 goodin pluto[9878]: "L2TP-PSK"[2] 166.193.133.118 #3:
transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Nov 19 11:26:15 goodin pluto[9878]: "L2TP-PSK"[2] 166.193.133.118 #3:
STATE_MAIN_R1: sent MR1, expecting MI2
Nov 19 11:26:16 goodin pluto[9878]: "L2TP-PSK"[2] 166.193.133.118 #3:
NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike (MacOS X): both
are NATed
Nov 19 11:26:16 goodin pluto[9878]: "L2TP-PSK"[2] 166.193.133.118 #3:
transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Nov 19 11:26:16 goodin pluto[9878]: "L2TP-PSK"[2] 166.193.133.118 #3:
STATE_MAIN_R2: sent MR2, expecting MI3
Nov 19 11:26:17 goodin pluto[9878]: "L2TP-PSK"[2] 166.193.133.118 #3:
Main mode peer ID is ID_IPV4_ADDR: '10.6.193.61'
Nov 19 11:26:17 goodin pluto[9878]: "L2TP-PSK"[2] 166.193.133.118 #3:
transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Nov 19 11:26:17 goodin pluto[9878]: "L2TP-PSK"[2] 166.193.133.118 #1:
new NAT mapping for #1, was 166.193.133.118:4500, now
166.193.133.118:4500
Nov 19 11:26:17 goodin pluto[9878]: "L2TP-PSK"[2] 166.193.133.118 #3:
new NAT mapping for #3, was 166.193.133.118:500, now
166.193.133.118:4500
Nov 19 11:26:17 goodin pluto[9878]: "L2TP-PSK"[2] 166.193.133.118 #3:
STATE_MAIN_R3: sent MR3, ISAKMP SA established
{auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha
group=modp1024}
Nov 19 11:26:17 goodin pluto[9878]: "L2TP-PSK"[2] 166.193.133.118 #3:
ignoring informational payload, type IPSEC_INITIAL_CONTACT
msgid=00000000
Nov 19 11:26:17 goodin pluto[9878]: "L2TP-PSK"[2] 166.193.133.118 #3:
received and ignored informational message
Nov 19 11:26:18 goodin pluto[9878]: "L2TP-PSK"[2] 166.193.133.118 #3:
the peer proposed: 66.57.62.130/32:17/1701 -> 10.6.193.61/32:17/49217
Nov 19 11:26:18 goodin pluto[9878]: "L2TP-PSK"[2] 166.193.133.118 #3:
alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_ar
in duplicate_state, please report to dev at openswan.org
Nov 19 11:26:18 goodin pluto[9878]: "L2TP-PSK"[2] 166.193.133.118 #3:
alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_er
in duplicate_state, please report to dev at openswan.org
Nov 19 11:26:18 goodin pluto[9878]: "L2TP-PSK"[2] 166.193.133.118 #3:
alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_pi
in duplicate_state, please report to dev at openswan.org
Nov 19 11:26:18 goodin pluto[9878]: "L2TP-PSK"[2] 166.193.133.118 #3:
alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_pr
in duplicate_state, please report to dev at openswan.org
Nov 19 11:26:18 goodin pluto[9878]: "L2TP-PSK"[3] 166.193.133.118 #4:
responding to Quick Mode proposal {msgid:b25e2a9a}
Nov 19 11:26:18 goodin pluto[9878]: "L2TP-PSK"[3] 166.193.133.118
#4: us: 66.57.62.130/32===10.33.3.2<10.33.3.2>[+S=C]:
17/1701---10.33.3.1
Nov 19 11:26:18 goodin pluto[9878]: "L2TP-PSK"[3] 166.193.133.118
#4: them: 166.193.133.118[10.6.193.61,+S=C]:17/49218===10.6.193.61/32
Nov 19 11:26:18 goodin pluto[9878]: "L2TP-PSK"[3] 166.193.133.118 #4:
transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
Nov 19 11:26:18 goodin pluto[9878]: "L2TP-PSK"[3] 166.193.133.118 #4:
STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
Nov 19 11:26:19 goodin pluto[9878]: "L2TP-PSK"[3] 166.193.133.118 #4:
transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Nov 19 11:26:19 goodin pluto[9878]: "L2TP-PSK"[3] 166.193.133.118 #4:
STATE_QUICK_R2: IPsec SA established transport mode {ESP=>0x04c243d6
<0xdbe53719 xfrm=AES_128-HMAC_SHA1 NATOA=<invalid> NATD=<invalid>:4500
DPD=enabled}
/var/log/messages:
Nov 19 11:26:26 goodin xl2tpd[9953]: Maximum retries exceeded for
tunnel 40224. Closing.
Nov 19 11:26:26 goodin xl2tpd[9953]: Connection 105 closed to
166.193.133.118, port 49218 (Timeout)
Nov 19 11:26:41 goodin xl2tpd[9953]: Maximum retries exceeded for
tunnel 11343. Closing.
Nov 19 11:26:41 goodin xl2tpd[9953]: Connection 105 closed to
166.193.133.118, port 49218 (Timeout)
Nov 19 11:26:51 goodin gnome-keyring-daemon[2210]: failed to
initialize a HAL context: (null)
More information about the Users
mailing list