<HTML dir=ltr><HEAD><TITLE>Re: [Openswan Users] NAT-Traversal not working with Openswan 2.6.20</TITLE>
<META http-equiv=Content-Type content="text/html; charset=unicode">
<META content="MSHTML 6.00.6000.16809" name=GENERATOR></HEAD>
<BODY>
<DIV id=idOWAReplyText94364 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>Thanks Paul,</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>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)</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>have you seen anything like this before?</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>"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 <A href="mailto:dev@openswan.org">dev@openswan.org</A>"</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>1.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2>Mar 5 15:08:37 s10-mail pluto[27287]: packet from 81.99.206.244:55000: ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000004]<BR>Mar 5 15:08:37 s10-mail pluto[27287]: packet from 81.99.206.244:55000: ignoring Vendor ID payload [FRAGMENTATION]<BR>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<BR>Mar 5 15:08:37 s10-mail pluto[27287]: packet from 81.99.206.244:55000: ignoring Vendor ID payload [Vid-Initial-Contact]<BR>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<BR>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<BR>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<BR>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<BR>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<BR>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<BR>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: <A href="mailto:'@ims-9973cb5b98c'">'@ims-9973cb5b98c'</A><BR>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"<BR>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}<BR>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<BR>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<BR>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}<BR>Mar 5 15:08:37 s10-mail pluto[27287]: "west-l2tp-psk"[30] 81.99.206.244 #29: peer client type is FQDN<BR>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<BR>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<BR>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<BR>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 <A href="mailto:dev@openswan.org">dev@openswan.org</A><BR>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 <A href="mailto:dev@openswan.org">dev@openswan.org</A><BR>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 <A href="mailto:dev@openswan.org">dev@openswan.org</A><BR>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 <A href="mailto:dev@openswan.org">dev@openswan.org</A><BR>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}<BR>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<BR>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<BR>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<BR>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<BR>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<BR>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}<BR>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<BR>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<BR>Mar 5 15:08:44 s10-mail pluto[27287]: "west-l2tp-psk"[30] 81.99.206.244 #29: received and ignored informational message<BR>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<BR>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}<BR>Mar 5 15:08:44 s10-mail pluto[27287]: "west-l2tp-psk": request to delete a unrouted policy with netkey kernel --- experimental<BR>Mar 5 15:08:44 s10-mail pluto[27287]: packet from 81.99.206.244:4500: received and ignored informational message<BR></FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>2.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2> xl2tpd -D<BR>l2tpd[29506]: This binary does not support kernel L2TP.<BR>l2tpd[29506]: xl2tpd version xl2tpd-1.1.07 started on s10-mail.lixxus.net PID:29506<BR>l2tpd[29506]: Written by Mark Spencer, Copyright (C) 1998, Adtran, Inc.<BR>l2tpd[29506]: Forked by Scott Balmos and David Stipp, (C) 2001<BR>l2tpd[29506]: Inherited by Jeff McAdams, (C) 2002<BR>l2tpd[29506]: Forked again by Xelerance (<A href="http://www.xelerance.com">www.xelerance.com</A>) (C) 2006<BR>l2tpd[29506]: Listening on IP address 84.201.191.137, port 1701<BR>packet dump:<BR>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 }<BR>ASCII: { l ims-9973cb5b98c Microsoft }<BR>l2tpd[29506]: get_call: allocating new tunnel for host 81.99.206.244, port 1701.<BR>l2tpd[29506]: ourtid = 47220, entropy_buf = b874<BR>l2tpd[29506]: check_control: control, cid = 0, Ns = 0, Nr = 0<BR>packet dump:<BR>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 }<BR>ASCII: { t s10-mail.lixxus.net xelerance.com t }<BR>packet dump:<BR>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 }<BR>ASCII: { l ims-9973cb5b98c Microsoft }<BR>l2tpd[29506]: get_call: allocating new tunnel for host 81.99.206.244, port 1701.<BR>l2tpd[29506]: ourtid = 8742, entropy_buf = 2226<BR>l2tpd[29506]: check_control: control, cid = 0, Ns = 0, Nr = 0<BR>l2tpd[29506]: control_finish: Peer requested tunnel 29 twice, ignoring second one.<BR>l2tpd[29506]: build_fdset: closing down tunnel 8742<BR>packet dump:<BR>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 }<BR>ASCII: { l ims-9973cb5b98c Microsoft }<BR>l2tpd[29506]: get_call: allocating new tunnel for host 81.99.206.244, port 1701.<BR>l2tpd[29506]: ourtid = 22526, entropy_buf = 57fe<BR>l2tpd[29506]: check_control: control, cid = 0, Ns = 0, Nr = 0<BR>l2tpd[29506]: control_finish: Peer requested tunnel 29 twice, ignoring second one.<BR>l2tpd[29506]: build_fdset: closing down tunnel 22526<BR>packet dump:<BR>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 }<BR>ASCII: { l ims-9973cb5b98c Microsoft }<BR>l2tpd[29506]: get_call: allocating new tunnel for host 81.99.206.244, port 1701.<BR>l2tpd[29506]: ourtid = 63673, entropy_buf = f8b9<BR>l2tpd[29506]: ourcid = 7121, entropy_buf = 1bd1<BR>l2tpd[29506]: check_control: control, cid = 0, Ns = 0, Nr = 0<BR>l2tpd[29506]: control_finish: Peer requested tunnel 29 twice, ignoring second one.<BR>l2tpd[29506]: build_fdset: closing down tunnel 63673<BR>l2tpd[29506]: Maximum retries exceeded for tunnel 47220. Closing.<BR>l2tpd[29506]: build_fdset: closing down tunnel 47220<BR>packet dump:<BR>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 }<BR>ASCII: { - t Timeout}<BR>l2tpd[29506]: Connection 29 closed to 81.99.206.244, port 1701 (Timeout)<BR>l2tpd[29506]: Unable to deliver closing message for tunnel 47220. Destroying anyway.<BR>l2tpd[29506]: build_fdset: closing down tunnel 47220<BR>packet dump:<BR>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 }<BR>ASCII: { l ims-9973cb5b98c Microsoft }<BR>l2tpd[29506]: get_call: allocating new tunnel for host 81.99.206.244, port 1701.<BR>l2tpd[29506]: ourtid = 33294, entropy_buf = 820e<BR>l2tpd[29506]: ourcid = 15802, entropy_buf = 3dba<BR>l2tpd[29506]: check_control: control, cid = 0, Ns = 0, Nr = 0<BR>packet dump:<BR>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 }<BR>ASCII: { t s10-mail.lixxus.net xelerance.com }<BR>l2tpd[29506]: Maximum retries exceeded for tunnel 33294. Closing.<BR>l2tpd[29506]: build_fdset: closing down tunnel 33294<BR>packet dump:<BR>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 }<BR>ASCII: { - Timeout}<BR>l2tpd[29506]: Connection 29 closed to 81.99.206.244, port 1701 (Timeout)<BR>packet dump:<BR>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 }<BR>ASCII: { l ims-9973cb5b98c Microsoft }<BR>l2tpd[29506]: get_call: allocating new tunnel for host 81.99.206.244, port 1701.<BR>l2tpd[29506]: ourtid = 51133, entropy_buf = c7bd<BR>l2tpd[29506]: check_control: control, cid = 0, Ns = 0, Nr = 0<BR>l2tpd[29506]: control_finish: Peer requested tunnel 29 twice, ignoring second one.<BR>l2tpd[29506]: build_fdset: closing down tunnel 51133<BR>l2tpd[29506]: Unable to deliver closing message for tunnel 33294. Destroying anyway.<BR>l2tpd[29506]: build_fdset: closing down tunnel 33294<BR></DIV></FONT></DIV>
<DIV dir=ltr>(3) Xl2tpd.conf<BR>[global]<BR>listen-addr = 84.201.191.137<BR>;listen-addr = 192.168.10.137<BR>;<BR>; requires openswan-3.1 or higher<BR>;ipsec saref = yes<BR>;<BR>debug tunnel = yes<BR>debug packet = yes</DIV>
<DIV dir=ltr>[lns default]<BR>ip range = 192.168.10.145 - 192.168.10.158<BR>local ip = 192.168.10.137<BR>;local ip = 84.201.191.137<BR>require chap = yes<BR>refuse pap = yes<BR>require authentication = no<BR>name = LinuxVPNserver<BR>ppp debug = yes<BR>pppoptfile = /etc/ppp/options.xl2tpd<BR>length bit = yes<BR><BR></DIV>
<DIV dir=ltr>
<HR tabIndex=-1>
</DIV>
<DIV dir=ltr><FONT face=Tahoma size=2><B>From:</B> Paul Wouters [mailto:paul@xelerance.com]<BR><B>Sent:</B> Wed 04/03/2009 19:41<BR><B>To:</B> Danny Woodruffe<BR><B>Cc:</B> users@openswan.org<BR><B>Subject:</B> Re: [Openswan Users] NAT-Traversal not working with Openswan 2.6.20<BR></FONT><BR></DIV>
<DIV>
<P><FONT size=2>On Wed, 4 Mar 2009, Danny Woodruffe wrote:<BR><BR>> Hello, I cannot get NAT-Traversal working with Openswan, but the<BR>> configuration works well when there is no natting involved.<BR>><BR>> I'm using XP SP3 and openswan-2.6.20 running on Centos-5.2<BR>><BR>> 1. The AssumeUDPEncapsulationContextOnSendRule value on the XP client is<BR>> set to 2.<BR>> 2. The client internal IP is 192.168.2.111<BR>> 3. The natted IP is 84.201.183.1<BR>> 4. The server IP is 84.201.191.137<BR><BR>> conn west-l2tp-psk<BR>> left=84.201.191.137<BR>> leftnexthop=84.201.191.129<BR>> leftprotoport=17/1701<BR>> rightprotoport=17/%any<BR>> rightsubnet=vhost:,%priv,%no<BR><BR>There is a typo there that might matter. The first comma is bogus.<BR>If that does not fix it, please try using rightprotoport=17/0 or 17/1701.<BR><BR>> right=%any<BR>> auto=add<BR>> authby=secret<BR><BR>NAT and PSK do not work well together. Try using X.509 certs instead.<BR>The ID you are using now is based on the IP, which is NATTED.<BR><BR>Paul<BR><BR>><BR>><BR>><BR>><BR>><BR>> 6. Here is the eror message:<BR>><BR>> Mar 4 10:49:01 s10-mail pluto[11001]: packet from 84.201.183.1:500:<BR>> ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000004]<BR>> Mar 4 10:49:01 s10-mail pluto[11001]: packet from 84.201.183.1:500:<BR>> ignoring Vendor ID payload [FRAGMENTATION]<BR>> Mar 4 10:49:01 s10-mail pluto[11001]: packet from 84.201.183.1:500:<BR>> received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] method set<BR>> to=106<BR>> Mar 4 10:49:01 s10-mail pluto[11001]: packet from 84.201.183.1:500:<BR>> ignoring Vendor ID payload [Vid-Initial-Contact]<BR>> Mar 4 10:49:01 s10-mail pluto[11001]: "west-l2tp-psk"[11] 84.201.183.1<BR>> #6: responding to Main Mode from unknown peer 84.201.183.1<BR>> Mar 4 10:49:01 s10-mail pluto[11001]: "west-l2tp-psk"[11] 84.201.183.1<BR>> #6: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1<BR>> Mar 4 10:49:01 s10-mail pluto[11001]: "west-l2tp-psk"[11] 84.201.183.1<BR>> #6: STATE_MAIN_R1: sent MR1, expecting MI2<BR>> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[11] 84.201.183.1<BR>> #6: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: peer<BR>> is NATed<BR>> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[11] 84.201.183.1<BR>> #6: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2<BR>> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[11] 84.201.183.1<BR>> #6: STATE_MAIN_R2: sent MR2, expecting MI3<BR>> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[11] 84.201.183.1<BR>> #6: Main mode peer ID is ID_FQDN: '@lixxus-35e4ff1a'<BR>> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[11] 84.201.183.1<BR>> #6: switched from "west-l2tp-psk" to "west-l2tp-psk"<BR>> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1<BR>> #6: deleting connection "west-l2tp-psk" instance with peer 84.201.183.1<BR>> {isakmp=#0/ipsec=#0}<BR>> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1<BR>> #6: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3<BR>> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1<BR>> #6: new NAT mapping for #6, was 84.201.183.1:500, now 84.201.183.1:4500<BR>> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1<BR>> #6: STATE_MAIN_R3: sent MR3, ISAKMP SA established<BR>> {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha<BR>> group=modp2048}<BR>> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1<BR>> #6: peer client type is FQDN<BR>> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1<BR>> #6: Applying workaround for MS-818043 NAT-T bug<BR>> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1<BR>> #6: IDci was FQDN: T\311\277\211, using NAT_OA=192.168.2.111/32 as IDci<BR>> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1<BR>> #6: the peer proposed: 84.201.191.137/32:17/1701 -><BR>> 192.168.2.111/32:17/0<BR>> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1<BR>> #6: cannot respond to IPsec SA request because no connection is known<BR>> for<BR>> 84.201.191.137<84.201.191.137>[+S=C]:17/1701...84.201.183.1[@lixxus-35e4<BR>> ff1a,+S=C]:17/%any===192.168.2.111/32<BR>> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1<BR>> #6: sending encrypted notification INVALID_ID_INFORMATION to<BR>> 84.201.183.1:4500<BR>> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1<BR>> #6: peer client type is FQDN<BR>> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1<BR>> #6: Applying workaround for MS-818043 NAT-T bug<BR>> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1<BR>> #6: IDci was FQDN: T\311\277\211, using NAT_OA=192.168.2.111/32 as IDci<BR>> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1<BR>> #6: the peer proposed: 84.201.191.137/32:17/1701 -><BR>> 192.168.2.111/32:17/0<BR>> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1<BR>> #6: cannot respond to IPsec SA request because no connection is known<BR>> for<BR>> 84.201.191.137<84.201.191.137>[+S=C]:17/1701...84.201.183.1[@lixxus-35e4<BR>> ff1a,+S=C]:17/%any===192.168.2.111/32<BR>> Mar 4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1<BR>> #6: sending encrypted notification INVALID_ID_INFORMATION to<BR>> 84.201.183.1:4500<BR>> Mar 4 10:49:04 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1<BR>> #6: peer client type is FQDN<BR>> Mar 4 10:49:04 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1<BR>> #6: Applying workaround for MS-818043 NAT-T bug<BR>> Mar 4 10:49:04 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1<BR>> #6: IDci was FQDN: T\311\277\211, using NAT_OA=192.168.2.111/32 as IDci<BR>> Mar 4 10:49:04 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1<BR>> #6: the peer proposed: 84.201.191.137/32:17/1701 -><BR>> 192.168.2.111/32:17/0<BR>> Mar 4 10:49:04 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1<BR>> #6: cannot respond to IPsec SA request because no connection is known<BR>> for<BR>> 84.201.191.137<84.201.191.137>[+S=C]:17/1701...84.201.183.1[@lixxus-35e4<BR>> ff1a,+S=C]:17/%any===192.168.2.111/32<BR>> Mar 4 10:49:04 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1<BR>> #6: sending encrypted notification INVALID_ID_INFORMATION to<BR>> 84.201.183.1:4500<BR>> Mar 4 10:49:08 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1<BR>> #6: peer client type is FQDN<BR>> Mar 4 10:49:08 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1<BR>> #6: Applying workaround for MS-818043 NAT-T bug<BR>> Mar 4 10:49:08 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1<BR>> #6: IDci was FQDN: T\311\277\211, using NAT_OA=192.168.2.111/32 as IDci<BR>> Mar 4 10:49:08 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1<BR>> #6: the peer proposed: 84.201.191.137/32:17/1701 -><BR>> 192.168.2.111/32:17/0<BR>> Mar 4 10:49:08 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1<BR>> #6: cannot respond to IPsec SA request because no connection is known<BR>> for<BR>> 84.201.191.137<84.201.191.137>[+S=C]:17/1701...84.201.183.1[@lixxus-35e4<BR>> ff1a,+S=C]:17/%any===192.168.2.111/32<BR>> Mar 4 10:49:08 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1<BR>> #6: sending encrypted notification INVALID_ID_INFORMATION to<BR>> 84.201.183.1:4500<BR>> Mar 4 10:49:16 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1<BR>> #6: peer client type is FQDN<BR>> Mar 4 10:49:16 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1<BR>> #6: Applying workaround for MS-818043 NAT-T bug<BR>> Mar 4 10:49:16 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1<BR>> #6: IDci was FQDN: T\311\277\211, using NAT_OA=192.168.2.111/32 as IDci<BR>> Mar 4 10:49:16 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1<BR>> #6: the peer proposed: 84.201.191.137/32:17/1701 -><BR>> 192.168.2.111/32:17/0<BR>> Mar 4 10:49:16 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1<BR>> #6: cannot respond to IPsec SA request because no connection is known<BR>> for<BR>> 84.201.191.137<84.201.191.137>[+S=C]:17/1701...84.201.183.1[@lixxus-35e4<BR>> ff1a,+S=C]:17/%any===192.168.2.111/32<BR>> Mar 4 10:49:16 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1<BR>> #6: sending encrypted notification INVALID_ID_INFORMATION to<BR>> 84.201.183.1:4500<BR>> Mar 4 10:49:30 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1<BR>> #6: received Delete SA payload: deleting ISAKMP State #6<BR>> Mar 4 10:49:30 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1:<BR>> deleting connection "west-l2tp-psk" instance with peer 84.201.183.1<BR>> {isakmp=#0/ipsec=#0}<BR>> Mar 4 10:49:30 s10-mail pluto[11001]: packet from 84.201.183.1:4500:<BR>> received and ignored informational message<BR>><BR>><BR>> Any advice would be greatly appreciated.<BR>><BR>> Thanks<BR>><BR>> Danny<BR>> _______________________________________________<BR>> Users@openswan.org<BR>> <A href="http://lists.openswan.org/mailman/listinfo/users">http://lists.openswan.org/mailman/listinfo/users</A><BR>> Building and Integrating Virtual Private Networks with Openswan:<BR>> <A href="http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155">http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155</A><BR>><BR></FONT></P></DIV></BODY></HTML>