[Openswan Users] L2TP response unencrypted

Mon Apr 7 12:36:28 EDT 2008

Hi,

Jacco, thank you for your answer. Please find my answers in-line.

On Mon, Apr 7, 2008 at 2:54 PM, Jacco de Leeuw <jacco2 at dds.nl> wrote:

>
> Alan Whinery wrote:
>
> > The XP SP2 NAT patch is necessary for your client to do NAT. The "server
> > behind Nat" scenario is merely the reason they turned off NAT in SP2.
>
> Microsoft did not turned off NAT in SP2. If the server is really not
> behind
> NAT then the patch should not be necessary. But I would really like to see
> Peter's Openswan log to make any conclusions. Or better yet, an 'ipsec
> barf'.
>

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.

What is an 'ipsec barf'?

>> the server unencrypted. I confirmed this by sniffing the traffic on
> >> both the server and the client.
> >> This confirms for me that the capture results on the
> >> server are not due to some NETKEY vs. sniffer artifact, but indeed,
> >> the packets are not encrypted by IPSEC.
>
> I would recommend using a third computer to do the sniffing. (Just like
> an attacker would do :-).

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.
 - 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)
 - 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
 - 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.

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.

> >> conn L2TP-PSK-NAT
> >>         left=89.a.b.c
> >>         leftid="89.a.b.c"
>
> What happens if you leave out the leftid?

Nothing. I tried it right after sending my first mail.

Thank you so much for your assistance.

Best regards,
Peter

Openswan log:

Apr  6 18:16:59 kacsa ipsec__plutorun: Starting Pluto subsystem...
Apr  6 18:16:59 kacsa pluto[14111]: Starting Pluto (Openswan Version 2.5.17;
Ven
dor ID OEztC{yJaHh[) pid:14111
Apr  6 18:16:59 kacsa pluto[14111]: Setting NAT-Traversal port-4500 floating
to
on
Apr  6 18:16:59 kacsa pluto[14111]:    port floating activation criteria
nat_t=1
/port_float=1
Apr  6 18:16:59 kacsa pluto[14111]:    including NAT-Traversal patch
(Version 0.
6c)
Apr  6 18:16:59 kacsa pluto[14111]: using /dev/urandom as source of random
entro
py
Apr  6 18:16:59 kacsa pluto[14111]: ike_alg_register_enc(): Activating
OAKLEY_TW
OFISH_CBC_SSH: Ok (ret=0)
Apr  6 18:16:59 kacsa pluto[14111]: ike_alg_register_enc(): Activating
OAKLEY_TW
OFISH_CBC: Ok (ret=0)
Apr  6 18:16:59 kacsa pluto[14111]: ike_alg_register_enc(): Activating
OAKLEY_SE
RPENT_CBC: Ok (ret=0)
Apr  6 18:16:59 kacsa pluto[14111]: ike_alg_register_enc(): Activating
OAKLEY_AE
S_CBC: Ok (ret=0)
Apr  6 18:16:59 kacsa pluto[14111]: ike_alg_register_enc(): Activating
OAKLEY_BL
OWFISH_CBC: Ok (ret=0)
Apr  6 18:16:59 kacsa pluto[14111]: ike_alg_register_hash(): Activating
OAKLEY_S
HA2_512: Ok (ret=0)
Apr  6 18:16:59 kacsa pluto[14111]: ike_alg_register_hash(): Activating
OAKLEY_S
HA2_256: Ok (ret=0)
Apr  6 18:16:59 kacsa pluto[14111]: starting up 1 cryptographic helpers
Apr  6 18:16:59 kacsa pluto[14112]: using /dev/urandom as source of random
entro
py
Apr  6 18:16:59 kacsa pluto[14111]: started helper pid=14112 (fd:7)
Apr  6 18:16:59 kacsa pluto[14111]: Using Linux 2.6 IPsec interface code on
2.6.
24.3 (experimental code)
Apr  6 18:16:59 kacsa pluto[14111]: Changing to directory
'/etc/ipsec.d/cacerts'
Apr  6 18:16:59 kacsa pluto[14111]: Changing to directory
'/etc/ipsec.d/aacerts'
Apr  6 18:16:59 kacsa pluto[14111]: Changing to directory
'/etc/ipsec.d/ocspcert
s'
Apr  6 18:16:59 kacsa pluto[14111]: Changing to directory
'/etc/ipsec.d/crls'
Apr  6 18:16:59 kacsa pluto[14111]:   Warning: empty directory
Apr  6 18:16:59 kacsa pluto[14111]: added connection description
"L2TP-PSK-NAT"
Apr  6 18:16:59 kacsa pluto[14111]: listening for IKE messages
Apr  6 18:16:59 kacsa pluto[14111]: adding interface eth1/eth1
192.168.1.1:500
Apr  6 18:16:59 kacsa pluto[14111]: adding interface eth1/eth1
192.168.1.1:4500
Apr  6 18:16:59 kacsa pluto[14111]: adding interface eth0/eth0 89.a.b.c:500
Apr  6 18:16:59 kacsa pluto[14111]: adding interface eth0/eth0 89.a.b.c:450
0
Apr  6 18:16:59 kacsa pluto[14111]: adding interface lo/lo 127.0.0.1:500
Apr  6 18:16:59 kacsa pluto[14111]: adding interface lo/lo 127.0.0.1:4500
Apr  6 18:16:59 kacsa pluto[14111]: adding interface lo/lo ::1:500
Apr  6 18:16:59 kacsa pluto[14111]: loading secrets from
"/etc/ipsec.secrets"
Apr  6 18:17:09 kacsa pluto[14111]: packet from 89.d.e.f:500: ignoring Ven
dor ID payload [MS NT5 ISAKMPOAKLEY 00000004]
Apr  6 18:17:09 kacsa pluto[14111]: packet from 89.d.e.f:500: ignoring Ven
dor ID payload [FRAGMENTATION]
Apr  6 18:17:09 kacsa pluto[14111]: packet from 89.d.e.f:500: received Ven
dor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] method set to=106
Apr  6 18:17:09 kacsa pluto[14111]: packet from 89.d.e.f:500: ignoring Ven
dor ID payload [Vid-Initial-Contact]
Apr  6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[1] 89.d.e.f #1: respond
ing to Main Mode from unknown peer 89.d.e.f
Apr  6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[1] 89.d.e.f #1: transit
ion from state STATE_MAIN_R0 to state STATE_MAIN_R1
Apr  6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[1] 89.d.e.f #1: STATE_M
AIN_R1: sent MR1, expecting MI2
Apr  6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[1] 89.d.e.f #1: NAT-Tra
versal: Result using draft-ietf-ipsec-nat-t-ike-02/03: peer is NATed
Apr  6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[1] 89.d.e.f #1: transit
ion from state STATE_MAIN_R1 to state STATE_MAIN_R2
Apr  6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[1] 89.d.e.f #1: STATE_M
AIN_R2: sent MR2, expecting MI3
Apr  6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[1] 89.d.e.f #1: Main mo
de peer ID is ID_FQDN: '@peetie-671d1cdc'
Apr  6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[1] 89.d.e.f #1: switche
d from "L2TP-PSK-NAT" to "L2TP-PSK-NAT"
Apr  6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[2] 89.d.e.f #1: deletin
g connection "L2TP-PSK-NAT" instance with peer 89.d.e.f {isakmp=#0/ipsec=#
0}
Apr  6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[2] 89.d.e.f #1: transit
ion from state STATE_MAIN_R2 to state STATE_MAIN_R3
Apr  6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[2] 89.d.e.f #1: new NAT
 mapping for #1, was 89.d.e.f:500, now 89.d.e.f:4500
Apr  6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[2] 89.d.e.f #1: STATE_M
AIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY
cipher=oakley
_3des_cbc_192 prf=oakley_sha group=modp2048}
Apr  6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[2] 89.d.e.f #1: peer cl
ient type is FQDN
Apr  6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[2] 89.d.e.f #1: Applyin
g workaround for MS-818043 NAT-T bug
Apr  6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[2] 89.d.e.f #1: IDci wa
s FQDN: Y\205+\227, using NAT_OA=192.168.2.20/32 as IDci
Apr  6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[2] 89.d.e.f #1: the pee
r proposed: 89.a.b.c/32:17/1701 -> 192.168.2.20/32:17/1701
Apr  6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[2] 89.d.e.f #2: respond
ing to Quick Mode {msgid:e1893734}
Apr  6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[2] 89.d.e.f #2: transit
ion from state STATE_QUICK_R0 to state STATE_QUICK_R1
Apr  6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[2] 89.d.e.f #2: STATE_Q
UICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
Apr  6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[2] 89.d.e.f #2: transit
ion from state STATE_QUICK_R1 to state STATE_QUICK_R2
Apr  6 18:17:09 kacsa pluto[14111]: "L2TP-PSK-NAT"[2] 89.d.e.f #2: STATE_Q
UICK_R2: IPsec SA established transport mode {ESP=>0x3060f09a <0x47a6e706
xfrm=3
DES_0-HMAC_MD5 NATD=89.d.e.f:4500 DPD=none}
Apr  6 18:17:44 kacsa pluto[14111]: "L2TP-PSK-NAT"[2] 89.d.e.f #1: receive
d Delete SA(0x3060f09a) payload: deleting IPSEC State #2
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
Apr  6 18:17:44 kacsa pluto[14111]: "L2TP-PSK-NAT"[2] 89.d.e.f #1: received
and ignored informational message
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
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}
Apr  6 18:17:44 kacsa pluto[14111]: "L2TP-PSK-NAT": request to delete a
unrouted policy with netkey kernel --- experimental
Apr  6 18:17:44 kacsa pluto[14111]: packet from 89.d.e.f:4500: received and
ignored informational message
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20080407/8043646d/attachment.html 