[Openswan Users] NAT-Traversal not working with Openswan 2.6.20
Danny Woodruffe
Danny.Woodruffe at lixxus.co.uk
Thu Mar 5 10:22:59 EST 2009
Thanks Paul,
changing this rightsubnet=vhost:%priv,%no seemed to enable a tunnel to be created but I'm getting bug error messages (1) and Anb xl2tpd messages don't seem to be getting back to my client (2), config below (3)
have you seen anything like this before?
"Mar 5 15:08:37 s10-mail pluto[27287]: "west-l2tp-psk"[30] 81.99.206.244 #29: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_ar in duplicate_state, please report to dev at openswan.org"
1.
Mar 5 15:08:37 s10-mail pluto[27287]: packet from 81.99.206.244:55000: ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000004]
Mar 5 15:08:37 s10-mail pluto[27287]: packet from 81.99.206.244:55000: ignoring Vendor ID payload [FRAGMENTATION]
Mar 5 15:08:37 s10-mail pluto[27287]: packet from 81.99.206.244:55000: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] method set to=106
Mar 5 15:08:37 s10-mail pluto[27287]: packet from 81.99.206.244:55000: ignoring Vendor ID payload [Vid-Initial-Contact]
Mar 5 15:08:37 s10-mail pluto[27287]: "west-l2tp-psk"[29] 81.99.206.244 #29: responding to Main Mode from unknown peer 81.99.206.244
Mar 5 15:08:37 s10-mail pluto[27287]: "west-l2tp-psk"[29] 81.99.206.244 #29: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Mar 5 15:08:37 s10-mail pluto[27287]: "west-l2tp-psk"[29] 81.99.206.244 #29: STATE_MAIN_R1: sent MR1, expecting MI2
Mar 5 15:08:37 s10-mail pluto[27287]: "west-l2tp-psk"[29] 81.99.206.244 #29: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: peer is NATed
Mar 5 15:08:37 s10-mail pluto[27287]: "west-l2tp-psk"[29] 81.99.206.244 #29: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Mar 5 15:08:37 s10-mail pluto[27287]: "west-l2tp-psk"[29] 81.99.206.244 #29: STATE_MAIN_R2: sent MR2, expecting MI3
Mar 5 15:08:37 s10-mail pluto[27287]: "west-l2tp-psk"[29] 81.99.206.244 #29: Main mode peer ID is ID_FQDN: '@ims-9973cb5b98c'
Mar 5 15:08:37 s10-mail pluto[27287]: "west-l2tp-psk"[29] 81.99.206.244 #29: switched from "west-l2tp-psk" to "west-l2tp-psk"
Mar 5 15:08:37 s10-mail pluto[27287]: "west-l2tp-psk"[30] 81.99.206.244 #29: deleting connection "west-l2tp-psk" instance with peer 81.99.206.244 {isakmp=#0/ipsec=#0}
Mar 5 15:08:37 s10-mail pluto[27287]: "west-l2tp-psk"[30] 81.99.206.244 #29: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Mar 5 15:08:37 s10-mail pluto[27287]: "west-l2tp-psk"[30] 81.99.206.244 #29: new NAT mapping for #29, was 81.99.206.244:55000, now 81.99.206.244:4500
Mar 5 15:08:37 s10-mail pluto[27287]: "west-l2tp-psk"[30] 81.99.206.244 #29: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp2048}
Mar 5 15:08:37 s10-mail pluto[27287]: "west-l2tp-psk"[30] 81.99.206.244 #29: peer client type is FQDN
Mar 5 15:08:37 s10-mail pluto[27287]: "west-l2tp-psk"[30] 81.99.206.244 #29: Applying workaround for MS-818043 NAT-T bug
Mar 5 15:08:37 s10-mail pluto[27287]: "west-l2tp-psk"[30] 81.99.206.244 #29: IDci was FQDN: T\311\277\211, using NAT_OA=192.168.1.3/32 as IDci
Mar 5 15:08:37 s10-mail pluto[27287]: "west-l2tp-psk"[30] 81.99.206.244 #29: the peer proposed: 84.201.191.137/32:17/1701 -> 192.168.1.3/32:17/1701
Mar 5 15:08:37 s10-mail pluto[27287]: "west-l2tp-psk"[30] 81.99.206.244 #29: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_ar in duplicate_state, please report to dev at openswan.org
Mar 5 15:08:37 s10-mail pluto[27287]: "west-l2tp-psk"[30] 81.99.206.244 #29: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_er in duplicate_state, please report to dev at openswan.org
Mar 5 15:08:37 s10-mail pluto[27287]: "west-l2tp-psk"[30] 81.99.206.244 #29: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_pi in duplicate_state, please report to dev at openswan.org
Mar 5 15:08:37 s10-mail pluto[27287]: "west-l2tp-psk"[30] 81.99.206.244 #29: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_pr in duplicate_state, please report to dev at openswan.org
Mar 5 15:08:37 s10-mail pluto[27287]: "west-l2tp-psk"[30] 81.99.206.244 #30: responding to Quick Mode proposal {msgid:84a5be95}
Mar 5 15:08:37 s10-mail pluto[27287]: "west-l2tp-psk"[30] 81.99.206.244 #30: us: 84.201.191.137<84.201.191.137>[+S=C]:17/1701---84.201.191.129
Mar 5 15:08:37 s10-mail pluto[27287]: "west-l2tp-psk"[30] 81.99.206.244 #30: them: 81.99.206.244[@ims-9973cb5b98c,+S=C]:17/1701===192.168.1.3/32
Mar 5 15:08:37 s10-mail pluto[27287]: "west-l2tp-psk"[30] 81.99.206.244 #30: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
Mar 5 15:08:37 s10-mail pluto[27287]: "west-l2tp-psk"[30] 81.99.206.244 #30: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
Mar 5 15:08:37 s10-mail pluto[27287]: "west-l2tp-psk"[30] 81.99.206.244 #30: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Mar 5 15:08:37 s10-mail pluto[27287]: "west-l2tp-psk"[30] 81.99.206.244 #30: STATE_QUICK_R2: IPsec SA established transport mode {ESP=>0xfa6a70fe <0x14cc4a96 xfrm=3DES_0-HMAC_MD5 NATOA=192.168.1.3 NATD=81.99.206.244:4500 DPD=none}
Mar 5 15:08:44 s10-mail pluto[27287]: "west-l2tp-psk"[30] 81.99.206.244 #29: received Delete SA(0xfa6a70fe) payload: deleting IPSEC State #30
Mar 5 15:08:44 s10-mail pluto[27287]: "west-l2tp-psk"[30] 81.99.206.244 #30: request to replace with shunt a prospective erouted policy with netkey kernel --- experimental
Mar 5 15:08:44 s10-mail pluto[27287]: "west-l2tp-psk"[30] 81.99.206.244 #29: received and ignored informational message
Mar 5 15:08:44 s10-mail pluto[27287]: "west-l2tp-psk"[30] 81.99.206.244 #29: received Delete SA payload: deleting ISAKMP State #29
Mar 5 15:08:44 s10-mail pluto[27287]: "west-l2tp-psk"[30] 81.99.206.244: deleting connection "west-l2tp-psk" instance with peer 81.99.206.244 {isakmp=#0/ipsec=#0}
Mar 5 15:08:44 s10-mail pluto[27287]: "west-l2tp-psk": request to delete a unrouted policy with netkey kernel --- experimental
Mar 5 15:08:44 s10-mail pluto[27287]: packet from 81.99.206.244:4500: received and ignored informational message
2.
xl2tpd -D
l2tpd[29506]: This binary does not support kernel L2TP.
l2tpd[29506]: xl2tpd version xl2tpd-1.1.07 started on s10-mail.lixxus.net PID:29506
l2tpd[29506]: Written by Mark Spencer, Copyright (C) 1998, Adtran, Inc.
l2tpd[29506]: Forked by Scott Balmos and David Stipp, (C) 2001
l2tpd[29506]: Inherited by Jeff McAdams, (C) 2002
l2tpd[29506]: Forked again by Xelerance (www.xelerance.com) (C) 2006
l2tpd[29506]: Listening on IP address 84.201.191.137, port 1701
packet dump:
HEX: { 02 C8 6C 00 00 00 00 00 00 00 00 00 80 08 00 00 00 00 00 01 80 08 00 00 00 02 01 00 80 0A 00 00 00 03 00 00 00 01 80 0A 00 00 00 04 00 00 00 00 00 08 00 00 00 06 05 00 80 15 00 00 00 07 69 6D 73 2D 39 39 37 33 63 62 35 62 39 38 63 00 0F 00 00 00 08 4D 69 63 72 6F 73 6F 66 74 80 08 00 00 00 09 00 1D 80 08 00 00 00 0A 00 08 }
ASCII: { l ims-9973cb5b98c Microsoft }
l2tpd[29506]: get_call: allocating new tunnel for host 81.99.206.244, port 1701.
l2tpd[29506]: ourtid = 47220, entropy_buf = b874
l2tpd[29506]: check_control: control, cid = 0, Ns = 0, Nr = 0
packet dump:
HEX: { C8 02 00 74 00 1D 00 00 00 00 00 01 80 08 00 00 00 00 00 02 80 08 00 00 00 02 01 00 80 0A 00 00 00 03 00 00 00 03 80 0A 00 00 00 04 00 00 00 00 80 08 00 00 00 06 06 90 80 19 00 00 00 07 73 31 30 2D 6D 61 69 6C 2E 6C 69 78 78 75 73 2E 6E 65 74 80 13 00 00 00 08 78 65 6C 65 72 61 6E 63 65 2E 63 6F 6D 80 08 00 00 00 09 B8 74 80 08 00 00 00 0A 00 04 }
ASCII: { t s10-mail.lixxus.net xelerance.com t }
packet dump:
HEX: { 02 C8 6C 00 00 00 00 00 00 00 00 00 80 08 00 00 00 00 00 01 80 08 00 00 00 02 01 00 80 0A 00 00 00 03 00 00 00 01 80 0A 00 00 00 04 00 00 00 00 00 08 00 00 00 06 05 00 80 15 00 00 00 07 69 6D 73 2D 39 39 37 33 63 62 35 62 39 38 63 00 0F 00 00 00 08 4D 69 63 72 6F 73 6F 66 74 80 08 00 00 00 09 00 1D 80 08 00 00 00 0A 00 08 }
ASCII: { l ims-9973cb5b98c Microsoft }
l2tpd[29506]: get_call: allocating new tunnel for host 81.99.206.244, port 1701.
l2tpd[29506]: ourtid = 8742, entropy_buf = 2226
l2tpd[29506]: check_control: control, cid = 0, Ns = 0, Nr = 0
l2tpd[29506]: control_finish: Peer requested tunnel 29 twice, ignoring second one.
l2tpd[29506]: build_fdset: closing down tunnel 8742
packet dump:
HEX: { 02 C8 6C 00 00 00 00 00 00 00 00 00 80 08 00 00 00 00 00 01 80 08 00 00 00 02 01 00 80 0A 00 00 00 03 00 00 00 01 80 0A 00 00 00 04 00 00 00 00 00 08 00 00 00 06 05 00 80 15 00 00 00 07 69 6D 73 2D 39 39 37 33 63 62 35 62 39 38 63 00 0F 00 00 00 08 4D 69 63 72 6F 73 6F 66 74 80 08 00 00 00 09 00 1D 80 08 00 00 00 0A 00 08 }
ASCII: { l ims-9973cb5b98c Microsoft }
l2tpd[29506]: get_call: allocating new tunnel for host 81.99.206.244, port 1701.
l2tpd[29506]: ourtid = 22526, entropy_buf = 57fe
l2tpd[29506]: check_control: control, cid = 0, Ns = 0, Nr = 0
l2tpd[29506]: control_finish: Peer requested tunnel 29 twice, ignoring second one.
l2tpd[29506]: build_fdset: closing down tunnel 22526
packet dump:
HEX: { 02 C8 6C 00 00 00 00 00 00 00 00 00 80 08 00 00 00 00 00 01 80 08 00 00 00 02 01 00 80 0A 00 00 00 03 00 00 00 01 80 0A 00 00 00 04 00 00 00 00 00 08 00 00 00 06 05 00 80 15 00 00 00 07 69 6D 73 2D 39 39 37 33 63 62 35 62 39 38 63 00 0F 00 00 00 08 4D 69 63 72 6F 73 6F 66 74 80 08 00 00 00 09 00 1D 80 08 00 00 00 0A 00 08 }
ASCII: { l ims-9973cb5b98c Microsoft }
l2tpd[29506]: get_call: allocating new tunnel for host 81.99.206.244, port 1701.
l2tpd[29506]: ourtid = 63673, entropy_buf = f8b9
l2tpd[29506]: ourcid = 7121, entropy_buf = 1bd1
l2tpd[29506]: check_control: control, cid = 0, Ns = 0, Nr = 0
l2tpd[29506]: control_finish: Peer requested tunnel 29 twice, ignoring second one.
l2tpd[29506]: build_fdset: closing down tunnel 63673
l2tpd[29506]: Maximum retries exceeded for tunnel 47220. Closing.
l2tpd[29506]: build_fdset: closing down tunnel 47220
packet dump:
HEX: { C8 02 00 2D 00 1D 00 00 00 01 00 01 80 08 00 00 00 00 00 04 80 08 00 00 00 09 B8 74 80 11 00 00 00 01 00 01 00 00 54 69 6D 65 6F 75 74 }
ASCII: { - t Timeout}
l2tpd[29506]: Connection 29 closed to 81.99.206.244, port 1701 (Timeout)
l2tpd[29506]: Unable to deliver closing message for tunnel 47220. Destroying anyway.
l2tpd[29506]: build_fdset: closing down tunnel 47220
packet dump:
HEX: { 02 C8 6C 00 00 00 00 00 00 00 00 00 80 08 00 00 00 00 00 01 80 08 00 00 00 02 01 00 80 0A 00 00 00 03 00 00 00 01 80 0A 00 00 00 04 00 00 00 00 00 08 00 00 00 06 05 00 80 15 00 00 00 07 69 6D 73 2D 39 39 37 33 63 62 35 62 39 38 63 00 0F 00 00 00 08 4D 69 63 72 6F 73 6F 66 74 80 08 00 00 00 09 00 1D 80 08 00 00 00 0A 00 08 }
ASCII: { l ims-9973cb5b98c Microsoft }
l2tpd[29506]: get_call: allocating new tunnel for host 81.99.206.244, port 1701.
l2tpd[29506]: ourtid = 33294, entropy_buf = 820e
l2tpd[29506]: ourcid = 15802, entropy_buf = 3dba
l2tpd[29506]: check_control: control, cid = 0, Ns = 0, Nr = 0
packet dump:
HEX: { C8 02 00 74 00 1D 00 00 00 00 00 01 80 08 00 00 00 00 00 02 80 08 00 00 00 02 01 00 80 0A 00 00 00 03 00 00 00 03 80 0A 00 00 00 04 00 00 00 00 80 08 00 00 00 06 06 90 80 19 00 00 00 07 73 31 30 2D 6D 61 69 6C 2E 6C 69 78 78 75 73 2E 6E 65 74 80 13 00 00 00 08 78 65 6C 65 72 61 6E 63 65 2E 63 6F 6D 80 08 00 00 00 09 82 0E 80 08 00 00 00 0A 00 04 }
ASCII: { t s10-mail.lixxus.net xelerance.com }
l2tpd[29506]: Maximum retries exceeded for tunnel 33294. Closing.
l2tpd[29506]: build_fdset: closing down tunnel 33294
packet dump:
HEX: { C8 02 00 2D 00 1D 00 00 00 01 00 01 80 08 00 00 00 00 00 04 80 08 00 00 00 09 82 0E 80 11 00 00 00 01 00 01 00 00 54 69 6D 65 6F 75 74 }
ASCII: { - Timeout}
l2tpd[29506]: Connection 29 closed to 81.99.206.244, port 1701 (Timeout)
packet dump:
HEX: { 02 C8 6C 00 00 00 00 00 00 00 00 00 80 08 00 00 00 00 00 01 80 08 00 00 00 02 01 00 80 0A 00 00 00 03 00 00 00 01 80 0A 00 00 00 04 00 00 00 00 00 08 00 00 00 06 05 00 80 15 00 00 00 07 69 6D 73 2D 39 39 37 33 63 62 35 62 39 38 63 00 0F 00 00 00 08 4D 69 63 72 6F 73 6F 66 74 80 08 00 00 00 09 00 1D 80 08 00 00 00 0A 00 08 }
ASCII: { l ims-9973cb5b98c Microsoft }
l2tpd[29506]: get_call: allocating new tunnel for host 81.99.206.244, port 1701.
l2tpd[29506]: ourtid = 51133, entropy_buf = c7bd
l2tpd[29506]: check_control: control, cid = 0, Ns = 0, Nr = 0
l2tpd[29506]: control_finish: Peer requested tunnel 29 twice, ignoring second one.
l2tpd[29506]: build_fdset: closing down tunnel 51133
l2tpd[29506]: Unable to deliver closing message for tunnel 33294. Destroying anyway.
l2tpd[29506]: build_fdset: closing down tunnel 33294
(3) Xl2tpd.conf
[global]
listen-addr = 84.201.191.137
;listen-addr = 192.168.10.137
;
; requires openswan-3.1 or higher
;ipsec saref = yes
;
debug tunnel = yes
debug packet = yes
[lns default]
ip range = 192.168.10.145 - 192.168.10.158
local ip = 192.168.10.137
;local ip = 84.201.191.137
require chap = yes
refuse pap = yes
require authentication = no
name = LinuxVPNserver
ppp debug = yes
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes
________________________________
From: Paul Wouters [mailto:paul at xelerance.com]
Sent: Wed 04/03/2009 19:41
To: Danny Woodruffe
Cc: users at openswan.org
Subject: Re: [Openswan Users] NAT-Traversal not working with Openswan 2.6.20
On Wed, 4 Mar 2009, Danny Woodruffe wrote:
> Hello, I cannot get NAT-Traversal working with Openswan, but the
> configuration works well when there is no natting involved.
>
> I'm using XP SP3 and openswan-2.6.20 running on Centos-5.2
>
> 1. The AssumeUDPEncapsulationContextOnSendRule value on the XP client is
> set to 2.
> 2. The client internal IP is 192.168.2.111
> 3. The natted IP is 84.201.183.1
> 4. The server IP is 84.201.191.137
> conn west-l2tp-psk
> left=84.201.191.137
> leftnexthop=84.201.191.129
> leftprotoport=17/1701
> rightprotoport=17/%any
> rightsubnet=vhost:,%priv,%no
There is a typo there that might matter. The first comma is bogus.
If that does not fix it, please try using rightprotoport=17/0 or 17/1701.
> right=%any
> auto=add
> authby=secret
NAT and PSK do not work well together. Try using X.509 certs instead.
The ID you are using now is based on the IP, which is NATTED.
Paul
>
>
>
>
>
> 6. Here is the eror message:
>
> Mar 4 10:49:01 s10-mail pluto[11001]: packet from 84.201.183.1:500:
> ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000004]
> Mar 4 10:49:01 s10-mail pluto[11001]: packet from 84.201.183.1:500:
> ignoring Vendor ID payload [FRAGMENTATION]
> Mar 4 10:49:01 s10-mail pluto[11001]: packet from 84.201.183.1:500:
> received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] method set
> to=106
> Mar 4 10:49:01 s10-mail pluto[11001]: packet from 84.201.183.1:500:
> ignoring Vendor ID payload [Vid-Initial-Contact]
> Mar 4 10:49:01 s10-mail pluto[11001]: "west-l2tp-psk"[11] 84.201.183.1
> #6: responding to Main Mode from unknown peer 84.201.183.1
> Mar 4 10:49:01 s10-mail pluto[11001]: "west-l2tp-psk"[11] 84.201.183.1
> #6: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
> Mar 4 10:49:01 s10-mail pluto[11001]: "west-l2tp-psk"[11] 84.201.183.1
> #6: STATE_MAIN_R1: sent MR1, expecting MI2
> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[11] 84.201.183.1
> #6: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: peer
> is NATed
> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[11] 84.201.183.1
> #6: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[11] 84.201.183.1
> #6: STATE_MAIN_R2: sent MR2, expecting MI3
> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[11] 84.201.183.1
> #6: Main mode peer ID is ID_FQDN: '@lixxus-35e4ff1a'
> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[11] 84.201.183.1
> #6: switched from "west-l2tp-psk" to "west-l2tp-psk"
> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: deleting connection "west-l2tp-psk" instance with peer 84.201.183.1
> {isakmp=#0/ipsec=#0}
> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: new NAT mapping for #6, was 84.201.183.1:500, now 84.201.183.1:4500
> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: STATE_MAIN_R3: sent MR3, ISAKMP SA established
> {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha
> group=modp2048}
> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: peer client type is FQDN
> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: Applying workaround for MS-818043 NAT-T bug
> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: IDci was FQDN: T\311\277\211, using NAT_OA=192.168.2.111/32 as IDci
> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: the peer proposed: 84.201.191.137/32:17/1701 ->
> 192.168.2.111/32:17/0
> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: cannot respond to IPsec SA request because no connection is known
> for
> 84.201.191.137<84.201.191.137>[+S=C]:17/1701...84.201.183.1[@lixxus-35e4
> ff1a,+S=C]:17/%any===192.168.2.111/32
> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: sending encrypted notification INVALID_ID_INFORMATION to
> 84.201.183.1:4500
> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: peer client type is FQDN
> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: Applying workaround for MS-818043 NAT-T bug
> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: IDci was FQDN: T\311\277\211, using NAT_OA=192.168.2.111/32 as IDci
> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: the peer proposed: 84.201.191.137/32:17/1701 ->
> 192.168.2.111/32:17/0
> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: cannot respond to IPsec SA request because no connection is known
> for
> 84.201.191.137<84.201.191.137>[+S=C]:17/1701...84.201.183.1[@lixxus-35e4
> ff1a,+S=C]:17/%any===192.168.2.111/32
> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: sending encrypted notification INVALID_ID_INFORMATION to
> 84.201.183.1:4500
> Mar 4 10:49:04 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: peer client type is FQDN
> Mar 4 10:49:04 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: Applying workaround for MS-818043 NAT-T bug
> Mar 4 10:49:04 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: IDci was FQDN: T\311\277\211, using NAT_OA=192.168.2.111/32 as IDci
> Mar 4 10:49:04 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: the peer proposed: 84.201.191.137/32:17/1701 ->
> 192.168.2.111/32:17/0
> Mar 4 10:49:04 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: cannot respond to IPsec SA request because no connection is known
> for
> 84.201.191.137<84.201.191.137>[+S=C]:17/1701...84.201.183.1[@lixxus-35e4
> ff1a,+S=C]:17/%any===192.168.2.111/32
> Mar 4 10:49:04 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: sending encrypted notification INVALID_ID_INFORMATION to
> 84.201.183.1:4500
> Mar 4 10:49:08 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: peer client type is FQDN
> Mar 4 10:49:08 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: Applying workaround for MS-818043 NAT-T bug
> Mar 4 10:49:08 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: IDci was FQDN: T\311\277\211, using NAT_OA=192.168.2.111/32 as IDci
> Mar 4 10:49:08 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: the peer proposed: 84.201.191.137/32:17/1701 ->
> 192.168.2.111/32:17/0
> Mar 4 10:49:08 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: cannot respond to IPsec SA request because no connection is known
> for
> 84.201.191.137<84.201.191.137>[+S=C]:17/1701...84.201.183.1[@lixxus-35e4
> ff1a,+S=C]:17/%any===192.168.2.111/32
> Mar 4 10:49:08 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: sending encrypted notification INVALID_ID_INFORMATION to
> 84.201.183.1:4500
> Mar 4 10:49:16 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: peer client type is FQDN
> Mar 4 10:49:16 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: Applying workaround for MS-818043 NAT-T bug
> Mar 4 10:49:16 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: IDci was FQDN: T\311\277\211, using NAT_OA=192.168.2.111/32 as IDci
> Mar 4 10:49:16 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: the peer proposed: 84.201.191.137/32:17/1701 ->
> 192.168.2.111/32:17/0
> Mar 4 10:49:16 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: cannot respond to IPsec SA request because no connection is known
> for
> 84.201.191.137<84.201.191.137>[+S=C]:17/1701...84.201.183.1[@lixxus-35e4
> ff1a,+S=C]:17/%any===192.168.2.111/32
> Mar 4 10:49:16 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: sending encrypted notification INVALID_ID_INFORMATION to
> 84.201.183.1:4500
> Mar 4 10:49:30 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: received Delete SA payload: deleting ISAKMP State #6
> Mar 4 10:49:30 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1:
> deleting connection "west-l2tp-psk" instance with peer 84.201.183.1
> {isakmp=#0/ipsec=#0}
> Mar 4 10:49:30 s10-mail pluto[11001]: packet from 84.201.183.1:4500:
> received and ignored informational message
>
>
> Any advice would be greatly appreciated.
>
> Thanks
>
> Danny
> _______________________________________________
> Users at openswan.org
> http://lists.openswan.org/mailman/listinfo/users
> Building and Integrating Virtual Private Networks with Openswan:
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20090305/146a74a0/attachment-0001.html
More information about the Users
mailing list