Hi,<br><br>Jacco, thank you for your answer. Please find my answers in-line.<br><br><div class="gmail_quote">On Mon, Apr 7, 2008 at 2:54 PM, Jacco de Leeuw <<a href="mailto:jacco2@dds.nl">jacco2@dds.nl</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
Alan Whinery wrote:<br>
<br>
> The XP SP2 NAT patch is necessary for your client to do NAT. The "server<br>
> behind Nat" scenario is merely the reason they turned off NAT in SP2.<br>
<br>
</div>Microsoft did not turned off NAT in SP2. If the server is really not behind<br>
NAT then the patch should not be necessary. But I would really like to see<br>
Peter's Openswan log to make any conclusions. Or better yet, an 'ipsec barf'.<br><div class="Ih2E3d"></div></blockquote><div><br>At the bottom of the message I pasted the log. It shows the starting of openswan, a connection attempt, and eventually the time-out and disconnection from the client side.<br>
<br>What is an 'ipsec barf'?<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">
>> the server unencrypted. I confirmed this by sniffing the traffic on<br>
>> both the server and the client.<br>
</div><div class="Ih2E3d">>> This confirms for me that the capture results on the<br>
>> server are not due to some NETKEY vs. sniffer artifact, but indeed,<br>
>> the packets are not encrypted by IPSEC.<br>
<br>
</div>I would recommend using a third computer to do the sniffing. (Just like<br>
an attacker would do :-).</blockquote><div><br>Sure, but I didn't have the chance to sniff in the middle. I'm pretty sure this is the case, the packets leave unencrypted.<br> - I think it's unlikely that libpcap on the linux server would sniff them before encryption, while the winpcap version on the winxp PC would sniff them after decryption (from client to server I only see NAT-T encapsulated ESP packets on both hosts) <br>
- Even if this was the case, the fact that the NAT-T packets never make it through the NAT is suspicious - I guess the source and destination ports aren't 4500, rather 1701<br> - But suppose it is only the NAT blocking the packets. Then, when in a demilitarized zone, the Windows PC do get the packets and should build up the L2TP connection but it doesn't.<br>
<br>I wrote a "fake L2TP server", to rule out any OpenL2TP configuration issue. It sends one UDP packet with source port=1701, destination port=1701 and destination host=89.d.e.f on demand (of course with OpenL2TP stopped). The packets behave exactly as the OpenL2TP response packets (they get transported unencrypted). This confirms for me that this is an Openswan issue.<br>
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
>> conn L2TP-PSK-NAT<br>
<div class="Ih2E3d">>> left=89.a.b.c<br>
</div><div class="Ih2E3d">>> leftid="89.a.b.c"<br>
<br>
</div>What happens if you leave out the leftid?</blockquote><div><br>Nothing. I tried it right after sending my first mail.<br><br></div></div>Thank you so much for your assistance. <br><br>Best regards,<br>Peter<br><br>
Openswan log:<br><br><br>Apr 6 18:16:59 kacsa ipsec__plutorun: Starting Pluto subsystem...<br>Apr 6 18:16:59 kacsa pluto[14111]: Starting Pluto (Openswan Version 2.5.17; Ven<br>dor ID OEztC{yJaHh[) pid:14111<br>Apr 6 18:16:59 kacsa pluto[14111]: Setting NAT-Traversal port-4500 floating to<br>
on<br>Apr 6 18:16:59 kacsa pluto[14111]: port floating activation criteria nat_t=1<br>/port_float=1<br>Apr 6 18:16:59 kacsa pluto[14111]: including NAT-Traversal patch (Version 0.<br>6c)<br>Apr 6 18:16:59 kacsa pluto[14111]: using /dev/urandom as source of random entro<br>
py<br>Apr 6 18:16:59 kacsa pluto[14111]: ike_alg_register_enc(): Activating OAKLEY_TW<br>OFISH_CBC_SSH: Ok (ret=0)<br>Apr 6 18:16:59 kacsa pluto[14111]: ike_alg_register_enc(): Activating OAKLEY_TW<br>OFISH_CBC: Ok (ret=0)<br>
Apr 6 18:16:59 kacsa pluto[14111]: ike_alg_register_enc(): Activating OAKLEY_SE<br>RPENT_CBC: Ok (ret=0)<br>Apr 6 18:16:59 kacsa pluto[14111]: ike_alg_register_enc(): Activating OAKLEY_AE<br>S_CBC: Ok (ret=0)<br>Apr 6 18:16:59 kacsa pluto[14111]: ike_alg_register_enc(): Activating OAKLEY_BL<br>
OWFISH_CBC: Ok (ret=0)<br>Apr 6 18:16:59 kacsa pluto[14111]: ike_alg_register_hash(): Activating OAKLEY_S<br>HA2_512: Ok (ret=0)<br>Apr 6 18:16:59 kacsa pluto[14111]: ike_alg_register_hash(): Activating OAKLEY_S<br>HA2_256: Ok (ret=0)<br>
Apr 6 18:16:59 kacsa pluto[14111]: starting up 1 cryptographic helpers<br>Apr 6 18:16:59 kacsa pluto[14112]: using /dev/urandom as source of random entro<br>py<br>Apr 6 18:16:59 kacsa pluto[14111]: started helper pid=14112 (fd:7)<br>
Apr 6 18:16:59 kacsa pluto[14111]: Using Linux 2.6 IPsec interface code on 2.6.<br>24.3 (experimental code)<br>Apr 6 18:16:59 kacsa pluto[14111]: Changing to directory '/etc/ipsec.d/cacerts'<br>Apr 6 18:16:59 kacsa pluto[14111]: Changing to directory '/etc/ipsec.d/aacerts'<br>
Apr 6 18:16:59 kacsa pluto[14111]: Changing to directory '/etc/ipsec.d/ocspcert<br>s'<br>Apr 6 18:16:59 kacsa pluto[14111]: Changing to directory '/etc/ipsec.d/crls'<br>Apr 6 18:16:59 kacsa pluto[14111]: Warning: empty directory<br>
Apr 6 18:16:59 kacsa pluto[14111]: added connection description "L2TP-PSK-NAT"<br>Apr 6 18:16:59 kacsa pluto[14111]: listening for IKE messages<br>Apr 6 18:16:59 kacsa pluto[14111]: adding interface eth1/eth1 <a href="http://192.168.1.1:500">192.168.1.1:500</a><br>
Apr 6 18:16:59 kacsa pluto[14111]: adding interface eth1/eth1 <a href="http://192.168.1.1:4500">192.168.1.1:4500</a><br>Apr 6 18:16:59 kacsa pluto[14111]: adding interface eth0/eth0 89.a.b.c:500<br>Apr 6 18:16:59 kacsa pluto[14111]: adding interface eth0/eth0 89.a.b.c:450<br>
0<br>Apr 6 18:16:59 kacsa pluto[14111]: adding interface lo/lo <a href="http://127.0.0.1:500">127.0.0.1:500</a><br>Apr 6 18:16:59 kacsa pluto[14111]: adding interface lo/lo <a href="http://127.0.0.1:4500">127.0.0.1:4500</a><br>
Apr 6 18:16:59 kacsa pluto[14111]: adding interface lo/lo ::1:500<br>Apr 6 18:16:59 kacsa pluto[14111]: loading secrets from "/etc/ipsec.secrets"<br>Apr 6 18:17:09 kacsa pluto[14111]: packet from 89.d.e.f:500: ignoring Ven<br>
dor ID payload [MS NT5 ISAKMPOAKLEY 00000004]<br>Apr 6 18:17:09 kacsa pluto[14111]: packet from 89.d.e.f:500: ignoring Ven<br>dor ID payload [FRAGMENTATION]<br>Apr 6 18:17:09 kacsa pluto[14111]: packet from 89.d.e.f:500: received Ven<br>
dor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] method set to=106<br>Apr 6 18:17:09 kacsa pluto[14111]: packet from 89.d.e.f:500: ignoring Ven<br>dor ID payload [Vid-Initial-Contact]<br>Apr 6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[1] 89.d.e.f #1: respond<br>
ing to Main Mode from unknown peer 89.d.e.f<br>Apr 6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[1] 89.d.e.f #1: transit<br>ion from state STATE_MAIN_R0 to state STATE_MAIN_R1<br>Apr 6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[1] 89.d.e.f #1: STATE_M<br>
AIN_R1: sent MR1, expecting MI2<br>Apr 6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[1] 89.d.e.f #1: NAT-Tra<br>versal: Result using draft-ietf-ipsec-nat-t-ike-02/03: peer is NATed<br>Apr 6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[1] 89.d.e.f #1: transit<br>
ion from state STATE_MAIN_R1 to state STATE_MAIN_R2<br>Apr 6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[1] 89.d.e.f #1: STATE_M<br>AIN_R2: sent MR2, expecting MI3<br>Apr 6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[1] 89.d.e.f #1: Main mo<br>
de peer ID is ID_FQDN: '@peetie-671d1cdc'<br>Apr 6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[1] 89.d.e.f #1: switche<br>d from "L2TP-PSK-NAT" to "L2TP-PSK-NAT"<br>Apr 6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[2] 89.d.e.f #1: deletin<br>
g connection "L2TP-PSK-NAT" instance with peer 89.d.e.f {isakmp=#0/ipsec=#<br>0}<br>Apr 6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[2] 89.d.e.f #1: transit<br>ion from state STATE_MAIN_R2 to state STATE_MAIN_R3<br>
Apr 6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[2] 89.d.e.f #1: new NAT<br> mapping for #1, was 89.d.e.f:500, now 89.d.e.f:4500<br>Apr 6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[2] 89.d.e.f #1: STATE_M<br>
AIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=oakley<br>_3des_cbc_192 prf=oakley_sha group=modp2048}<br>Apr 6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[2] 89.d.e.f #1: peer cl<br>ient type is FQDN<br>
Apr 6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[2] 89.d.e.f #1: Applyin<br>g workaround for MS-818043 NAT-T bug<br>Apr 6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[2] 89.d.e.f #1: IDci wa<br>s FQDN: Y\205+\227, using NAT_OA=<a href="http://192.168.2.20/32">192.168.2.20/32</a> as IDci<br>
Apr 6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[2] 89.d.e.f #1: the pee<br>r proposed: 89.a.b.c/32:17/1701 -> <a href="http://192.168.2.20/32:17/1701">192.168.2.20/32:17/1701</a><br>Apr 6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[2] 89.d.e.f #2: respond<br>
ing to Quick Mode {msgid:e1893734}<br>Apr 6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[2] 89.d.e.f #2: transit<br>ion from state STATE_QUICK_R0 to state STATE_QUICK_R1<br>Apr 6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[2] 89.d.e.f #2: STATE_Q<br>
UICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2<br>Apr 6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[2] 89.d.e.f #2: transit<br>ion from state STATE_QUICK_R1 to state STATE_QUICK_R2<br>Apr 6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[2] 89.d.e.f #2: STATE_Q<br>
UICK_R2: IPsec SA established transport mode {ESP=>0x3060f09a <0x47a6e706 xfrm=3<br>DES_0-HMAC_MD5 NATD=89.d.e.f:4500 DPD=none}<br>Apr 6 18:17:44 kacsa pluto[14111]: "L2TP-PSK-NAT"[2] 89.d.e.f #1: receive<br>
d Delete SA(0x3060f09a) payload: deleting IPSEC State #2<br>Apr 6 18:17:44 kacsa pluto[14111]: "L2TP-PSK-NAT"[2] 89.d.e.f #2: request to replace with shunt a prospective erouted policy with netkey kernel --- experimental<br>
Apr 6 18:17:44 kacsa pluto[14111]: "L2TP-PSK-NAT"[2] 89.d.e.f #1: received and ignored informational message<br>Apr 6 18:17:44 kacsa pluto[14111]: "L2TP-PSK-NAT"[2] 89.d.e.f #1: received Delete SA payload: deleting ISAKMP State #1<br>
Apr 6 18:17:44 kacsa pluto[14111]: "L2TP-PSK-NAT"[2] 89.d.e.f: deleting connection "L2TP-PSK-NAT" instance with peer 89.d.e.f {isakmp=#0/ipsec=#0}<br>Apr 6 18:17:44 kacsa pluto[14111]: "L2TP-PSK-NAT": request to delete a unrouted policy with netkey kernel --- experimental<br>
Apr 6 18:17:44 kacsa pluto[14111]: packet from 89.d.e.f:4500: received and ignored informational message<br><br>