[Openswan Users] Roadwarrior on OSX - "no suitable connection" for correctly configured NAT
David Young
david at prophecy.net.nz
Tue Nov 25 23:14:12 EST 2008
Hey folks,
I'm trying to setup a roadwarrior VPN, and have been following the
instructions at http://www.jacco2.dds.nl/networking/openswan-l2tp.html#NAT
(See "19.6 Procedure for enabling NAT-T (server not NATed)" for my IP
structure)
I've tried two slightly different configurations - one which I believe
is wrong but fails on L2TP, and one which I believe is correct, but
fails to even establish the IPSEC tunnel.
The following are the static config files for ipsec and xl2tpd:
== ipsec.conf ==
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:!1192.168.1.0/24
include /etc/ipsec.d/*.conf
== xl2tpd.conf ==
[global]
;listen-addr = 192.168.1.1
debug avp = yes
debug network = yes
debug state = yes
debug tunnel = yes
[lns default]
ip range = 192.168.1.100-192.168.1.200
local ip = 192.168.1.22
require chap = yes
refuse pap = yes
require authentication = yes
name = LinuxVPNserver
ppp debug = yes
pppoptfile = /etc/ppp/options.l2tpd
length bit = yes
Here's my first configuration, which results in a tunnel, but fails on
xl2tpd:
== Configuration #1 ==
conn L2TP-PSK
authby=secret
pfs=no
rekey=no
keyingtries=3
left=123.123.123.123
leftprotoport=17/1701
right=%any
rightprotoport=17/%any
rightsubnet=vhost:%priv,%no
forceencaps=yes
auto=add
== IPSEC Result #1 ==
Nov 26 16:48:20 vm3 pluto[21632]: packet from 234.234.234.234:500:
received Vendor ID payload [RFC 3947] method set to=109
Nov 26 16:48:20 vm3 pluto[21632]: packet from 234.234.234.234:500:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike] method set
to=110
Nov 26 16:48:20 vm3 pluto[21632]: packet from 234.234.234.234:500:
ignoring unknown Vendor ID payload [8f8d83826d246b6fc7a8a6a428c11de8]
Nov 26 16:48:20 vm3 pluto[21632]: packet from 234.234.234.234:500:
ignoring unknown Vendor ID payload [439b59f8ba676c4c7737ae22eab8f582]
Nov 26 16:48:20 vm3 pluto[21632]: packet from 234.234.234.234:500:
ignoring unknown Vendor ID payload [4d1e0e136deafa34c4f3ea9f02ec7285]
Nov 26 16:48:20 vm3 pluto[21632]: packet from 234.234.234.234:500:
ignoring unknown Vendor ID payload [80d0bb3def54565ee84645d4c85ce3ee]
Nov 26 16:48:20 vm3 pluto[21632]: packet from 234.234.234.234:500:
ignoring unknown Vendor ID payload [9909b64eed937c6573de52ace952fa6b]
Nov 26 16:48:20 vm3 pluto[21632]: packet from 234.234.234.234:500:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108,
but already using method 110
Nov 26 16:48:20 vm3 pluto[21632]: packet from 234.234.234.234:500:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107,
but already using method 110
Nov 26 16:48:20 vm3 pluto[21632]: packet from 234.234.234.234:500:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106,
but already using method 110
Nov 26 16:48:20 vm3 pluto[21632]: packet from 234.234.234.234:500:
received Vendor ID payload [Dead Peer Detection]
Nov 26 16:48:20 vm3 pluto[21632]: "L2TP-PSK"[1] 234.234.234.234 #1:
responding to Main Mode from unknown peer 234.234.234.234
Nov 26 16:48:20 vm3 pluto[21632]: "L2TP-PSK"[1] 234.234.234.234 #1:
transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Nov 26 16:48:20 vm3 pluto[21632]: "L2TP-PSK"[1] 234.234.234.234 #1:
STATE_MAIN_R1: sent MR1, expecting MI2
Nov 26 16:48:20 vm3 pluto[21632]: "L2TP-PSK"[1] 234.234.234.234 #1:
NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike (MacOS X): both
are NATed
Nov 26 16:48:20 vm3 pluto[21632]: "L2TP-PSK"[1] 234.234.234.234 #1:
transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Nov 26 16:48:20 vm3 pluto[21632]: "L2TP-PSK"[1] 234.234.234.234 #1:
STATE_MAIN_R2: sent MR2, expecting MI3
Nov 26 16:48:20 vm3 pluto[21632]: "L2TP-PSK"[1] 234.234.234.234 #1:
Main mode peer ID is ID_IPV4_ADDR: '192.168.0.2'
Nov 26 16:48:20 vm3 pluto[21632]: "L2TP-PSK"[1] 234.234.234.234 #1:
switched from "L2TP-PSK" to "L2TP-PSK"
Nov 26 16:48:20 vm3 pluto[21632]: "L2TP-PSK"[2] 234.234.234.234 #1:
deleting connection "L2TP-PSK" instance with peer 234.234.234.234
{isakmp=#0/ipsec=#0}
Nov 26 16:48:20 vm3 pluto[21632]: "L2TP-PSK"[2] 234.234.234.234 #1:
transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Nov 26 16:48:20 vm3 pluto[21632]: "L2TP-PSK"[2] 234.234.234.234 #1:
new NAT mapping for #1, was 234.234.234.234:500, now
234.234.234.234:4500
Nov 26 16:48:20 vm3 pluto[21632]: "L2TP-PSK"[2] 234.234.234.234 #1:
STATE_MAIN_R3: sent MR3, ISAKMP SA established
{auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha
group=modp1024}
Nov 26 16:48:20 vm3 pluto[21632]: "L2TP-PSK"[2] 234.234.234.234 #1:
ignoring informational payload, type IPSEC_INITIAL_CONTACT
msgid=00000000
Nov 26 16:48:20 vm3 pluto[21632]: "L2TP-PSK"[2] 234.234.234.234 #1:
received and ignored informational message
Nov 26 16:48:21 vm3 pluto[21632]: "L2TP-PSK"[2] 234.234.234.234 #1:
the peer proposed: 123.123.123.123/32:17/1701 -> 192.168.0.2/32:17/0
Nov 26 16:48:21 vm3 pluto[21632]: "L2TP-PSK"[2] 234.234.234.234 #1:
alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_ar
in duplicate_state, please report to dev at openswan.org
Nov 26 16:48:21 vm3 pluto[21632]: "L2TP-PSK"[2] 234.234.234.234 #1:
alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_er
in duplicate_state, please report to dev at openswan.org
Nov 26 16:48:21 vm3 pluto[21632]: "L2TP-PSK"[2] 234.234.234.234 #1:
alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_pi
in duplicate_state, please report to dev at openswan.org
Nov 26 16:48:21 vm3 pluto[21632]: "L2TP-PSK"[2] 234.234.234.234 #1:
alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_pr
in duplicate_state, please report to dev at openswan.org
Nov 26 16:48:21 vm3 pluto[21632]: "L2TP-PSK"[2] 234.234.234.234 #2:
responding to Quick Mode proposal {msgid:949d9a97}
Nov 26 16:48:21 vm3 pluto[21632]: "L2TP-PSK"[2] 234.234.234.234
#2: us: 123.123.123.123<123.123.123.123>[+S=C]:17/1701
Nov 26 16:48:21 vm3 pluto[21632]: "L2TP-PSK"[2] 234.234.234.234 #2:
them: 234.234.234.234[192.168.0.2,+S=C]:17/51118===?
Nov 26 16:48:21 vm3 pluto[21632]: "L2TP-PSK"[2] 234.234.234.234 #2:
transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
Nov 26 16:48:21 vm3 pluto[21632]: "L2TP-PSK"[2] 234.234.234.234 #2:
STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
Nov 26 16:48:21 vm3 pluto[21632]: "L2TP-PSK"[2] 234.234.234.234 #2:
transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Nov 26 16:48:21 vm3 pluto[21632]: "L2TP-PSK"[2] 234.234.234.234 #2:
STATE_QUICK_R2: IPsec SA established tunnel mode {ESP/NAT=>0x092bd777
<0x5e81e2b4 xfrm=AES_128-HMAC_SHA1 NATOA=<invalid> NATD=<invalid>:4500
DPD=enabled}
== L2TP Result #1 ==
xl2tpd[21234]: network_thread: recv packet from 234.234.234.234, size
= 60, tunnel = 0, call = 0 ref=0 refhim=0
xl2tpd[21234]: get_call: allocating new tunnel for host
234.234.234.234, port 51118.
xl2tpd[21234]: handle_avps: handling avp's for tunnel 42011, call 59597
xl2tpd[21234]: message_type_avp: message type 1 (Start-Control-
Connection-Request)
xl2tpd[21234]: protocol_version_avp: peer is using version 1, revision
0.
xl2tpd[21234]: framing_caps_avp: supported peer frames: async sync
xl2tpd[21234]: hostname_avp: peer reports hostname ''
xl2tpd[21234]: assigned_tunnel_avp: using peer's tunnel 243
xl2tpd[21234]: receive_window_size_avp: peer wants RWS of 4. Will use
flow control.
xl2tpd[21234]: control_finish: message type is Start-Control-
Connection-Request(1). Tunnel is 243, call is 0.
xl2tpd[21234]: control_finish: sending SCCRP
xl2tpd[21234]: build_fdset: closing down tunnel 52798
xl2tpd[21234]: network_thread: recv packet from 234.234.234.234, size
= 60, tunnel = 0, call = 0 ref=0 refhim=0
xl2tpd[21234]: get_call: allocating new tunnel for host
234.234.234.234, port 51118.
xl2tpd[21234]: handle_avps: handling avp's for tunnel 22533, call 62836
xl2tpd[21234]: message_type_avp: message type 1 (Start-Control-
Connection-Request)
xl2tpd[21234]: protocol_version_avp: peer is using version 1, revision
0.
xl2tpd[21234]: framing_caps_avp: supported peer frames: async sync
xl2tpd[21234]: hostname_avp: peer reports hostname ''
xl2tpd[21234]: assigned_tunnel_avp: using peer's tunnel 243
xl2tpd[21234]: receive_window_size_avp: peer wants RWS of 4. Will use
flow control.
xl2tpd[21234]: control_finish: message type is Start-Control-
Connection-Request(1). Tunnel is 243, call is 0.
xl2tpd[21234]: control_finish: Peer requested tunnel 243 twice,
ignoring second one.
xl2tpd[21234]: build_fdset: closing down tunnel 22533
xl2tpd[21234]: network_thread: recv packet from 234.234.234.234, size
= 60, tunnel = 0, call = 0 ref=0 refhim=0
xl2tpd[21234]: get_call: allocating new tunnel for host
234.234.234.234, port 51118.
xl2tpd[21234]: handle_avps: handling avp's for tunnel 61962, call 28250
xl2tpd[21234]: message_type_avp: message type 1 (Start-Control-
Connection-Request)
xl2tpd[21234]: protocol_version_avp: peer is using version 1, revision
0.
xl2tpd[21234]: framing_caps_avp: supported peer frames: async sync
xl2tpd[21234]: hostname_avp: peer reports hostname ''
xl2tpd[21234]: assigned_tunnel_avp: using peer's tunnel 243
xl2tpd[21234]: receive_window_size_avp: peer wants RWS of 4. Will use
flow control.
xl2tpd[21234]: control_finish: message type is Start-Control-
Connection-Request(1). Tunnel is 243, call is 0.
xl2tpd[21234]: control_finish: Peer requested tunnel 243 twice,
ignoring second one.
xl2tpd[21234]: build_fdset: closing down tunnel 61962
xl2tpd[21234]: network_thread: select timeout
xl2tpd[21234]: network_thread: select timeout
xl2tpd[21234]: network_thread: select timeout
xl2tpd[21234]: network_thread: select timeout
xl2tpd[21234]: network_thread: select timeout
xl2tpd[21234]: network_thread: select timeout
xl2tpd[21234]: network_thread: select timeout
xl2tpd[21234]: network_thread: recv packet from 234.234.234.234, size
= 60, tunnel = 0, call = 0 ref=0 refhim=0
xl2tpd[21234]: get_call: allocating new tunnel for host
234.234.234.234, port 51118.
xl2tpd[21234]: handle_avps: handling avp's for tunnel 10449, call 57162
xl2tpd[21234]: message_type_avp: message type 1 (Start-Control-
Connection-Request)
xl2tpd[21234]: protocol_version_avp: peer is using version 1, revision
0.
xl2tpd[21234]: framing_caps_avp: supported peer frames: async sync
xl2tpd[21234]: hostname_avp: peer reports hostname ''
xl2tpd[21234]: assigned_tunnel_avp: using peer's tunnel 243
xl2tpd[21234]: receive_window_size_avp: peer wants RWS of 4. Will use
flow control.
xl2tpd[21234]: control_finish: message type is Start-Control-
Connection-Request(1). Tunnel is 243, call is 0.
xl2tpd[21234]: control_finish: Peer requested tunnel 243 twice,
ignoring second one.
xl2tpd[21234]: build_fdset: closing down tunnel 10449
xl2tpd[21234]: network_thread: select timeout
xl2tpd[21234]: network_thread: select timeout
xl2tpd[21234]: Maximum retries exceeded for tunnel 42011. Closing.
xl2tpd[21234]: network_thread: recv packet from 234.234.234.234, size
= 60, tunnel = 0, call = 0 ref=0 refhim=0
xl2tpd[21234]: get_call: allocating new tunnel for host
234.234.234.234, port 51118.
xl2tpd[21234]: handle_avps: handling avp's for tunnel 59453, call 46580
xl2tpd[21234]: message_type_avp: message type 1 (Start-Control-
Connection-Request)
xl2tpd[21234]: protocol_version_avp: peer is using version 1, revision
0.
xl2tpd[21234]: framing_caps_avp: supported peer frames: async sync
xl2tpd[21234]: hostname_avp: peer reports hostname ''
xl2tpd[21234]: assigned_tunnel_avp: using peer's tunnel 243
xl2tpd[21234]: receive_window_size_avp: peer wants RWS of 4. Will use
flow control.
xl2tpd[21234]: control_finish: message type is Start-Control-
Connection-Request(1). Tunnel is 243, call is 0.
xl2tpd[21234]: control_finish: Peer requested tunnel 243 twice,
ignoring second one.
xl2tpd[21234]: build_fdset: closing down tunnel 59453
xl2tpd[21234]: build_fdset: closing down tunnel 42011
xl2tpd[21234]: Connection 243 closed to 234.234.234.234, port 51118
(Timeout)
xl2tpd[21234]: network_thread: select timeout
xl2tpd[21234]: network_thread: select timeout
xl2tpd[21234]: network_thread: select timeout
xl2tpd[21234]: network_thread: select timeout
xl2tpd[21234]: network_thread: select timeout
xl2tpd[21234]: network_thread: select timeout
xl2tpd[21234]: network_thread: select timeout
xl2tpd[21234]: network_thread: select timeout
xl2tpd[21234]: network_thread: select timeout
xl2tpd[21234]: network_thread: select timeout
xl2tpd[21234]: Unable to deliver closing message for tunnel 42011.
Destroying anyway.
And here's the second configuration. Under "19.2 Limitations and
requirements" (http://www.jacco2.dds.nl/networking/openswan-l2tp.html#NAT
) I read :
The NETKEY implementation does support PSKs but you will have to use
right=%any and use leftid=someservername and rightid=someclientname.
If you do specify an IP address with right=a.b.c.d without
leftid=someservername and rightid=someclientname, Openswan will
complain about "no connection authorized". If you use Windows Vista
with a PSK, and NAT is involved, you are required to use
rightsubnet=vhost:%no,%priv. This is probably true for other RFC 3947
compliant clients (such as Mac OS X) as well.
First attempting to add :
rightid=someclientname
leftid=someservername
I got this error:
Nov 26 17:05:08 vm3 pluto[24267]: "L2TP-PSK"[2] 234.234.234.234 #2:
responding to Main Mode from unknown peer 234.234.234.234
Nov 26 17:05:08 vm3 pluto[24267]: "L2TP-PSK"[2] 234.234.234.234 #2:
Can't authenticate: no preshared key found for `%any' and `%any'.
Attribute OAKLEY_AUTHENTICATION_METHOD
Nov 26 17:05:08 vm3 pluto[24267]: "L2TP-PSK"[2] 234.234.234.234 #2: no
acceptable Oakley Transform
So I changed to the following configuration:
== Configuration #2 ==
conn L2TP-PSK
authby=secret
pfs=no
rekey=no
keyingtries=3
left=123.123.123.123
leftprotoport=17/1701
right=%any
rightprotoport=17/%any
rightsubnet=vhost:%priv,%no
leftid=@someservername
rightid=@someclientname
forceencaps=yes
auto=add
== Result #2 ==
Nov 26 17:02:11 vm3 pluto[23461]: packet from 234.234.234.234:500:
received Vendor ID payload [RFC 3947] method set to=109
Nov 26 17:02:11 vm3 pluto[23461]: packet from 234.234.234.234:500:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike] method set
to=110
Nov 26 17:02:11 vm3 pluto[23461]: packet from 234.234.234.234:500:
ignoring unknown Vendor ID payload [8f8d83826d246b6fc7a8a6a428c11de8]
Nov 26 17:02:11 vm3 pluto[23461]: packet from 234.234.234.234:500:
ignoring unknown Vendor ID payload [439b59f8ba676c4c7737ae22eab8f582]
Nov 26 17:02:11 vm3 pluto[23461]: packet from 234.234.234.234:500:
ignoring unknown Vendor ID payload [4d1e0e136deafa34c4f3ea9f02ec7285]
Nov 26 17:02:11 vm3 pluto[23461]: packet from 234.234.234.234:500:
ignoring unknown Vendor ID payload [80d0bb3def54565ee84645d4c85ce3ee]
Nov 26 17:02:11 vm3 pluto[23461]: packet from 234.234.234.234:500:
ignoring unknown Vendor ID payload [9909b64eed937c6573de52ace952fa6b]
Nov 26 17:02:11 vm3 pluto[23461]: packet from 234.234.234.234:500:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108,
but already using method 110
Nov 26 17:02:11 vm3 pluto[23461]: packet from 234.234.234.234:500:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107,
but already using method 110
Nov 26 17:02:11 vm3 pluto[23461]: packet from 234.234.234.234:500:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106,
but already using method 110
Nov 26 17:02:11 vm3 pluto[23461]: packet from 234.234.234.234:500:
received Vendor ID payload [Dead Peer Detection]
Nov 26 17:02:11 vm3 pluto[23461]: "L2TP-PSK"[1] 234.234.234.234 #1:
responding to Main Mode from unknown peer 234.234.234.234
Nov 26 17:02:11 vm3 pluto[23461]: "L2TP-PSK"[1] 234.234.234.234 #1:
transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Nov 26 17:02:11 vm3 pluto[23461]: "L2TP-PSK"[1] 234.234.234.234 #1:
STATE_MAIN_R1: sent MR1, expecting MI2
Nov 26 17:02:11 vm3 pluto[23461]: "L2TP-PSK"[1] 234.234.234.234 #1:
NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike (MacOS X): both
are NATed
Nov 26 17:02:11 vm3 pluto[23461]: "L2TP-PSK"[1] 234.234.234.234 #1:
transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Nov 26 17:02:11 vm3 pluto[23461]: "L2TP-PSK"[1] 234.234.234.234 #1:
STATE_MAIN_R2: sent MR2, expecting MI3
Nov 26 17:02:11 vm3 pluto[23461]: "L2TP-PSK"[1] 234.234.234.234 #1:
Main mode peer ID is ID_IPV4_ADDR: '192.168.0.2'
Nov 26 17:02:11 vm3 pluto[23461]: "L2TP-PSK"[1] 234.234.234.234 #1: no
suitable connection for peer '192.168.0.2'
Nov 26 17:02:11 vm3 pluto[23461]: "L2TP-PSK"[1] 234.234.234.234 #1:
sending encrypted notification INVALID_ID_INFORMATION to
234.234.234.234:500
I'd really appreciate some help :)
Cheers,
David
More information about the Users
mailing list