[Openswan dev] traffic leak on openswan with Win7/Vista L2TP

Paul Wouters paul at xelerance.com
Tue Nov 23 13:49:03 EST 2010

See: https://lists.strongswan.org/pipermail/dev/2010-May/000200.html

 	When pluto is the responder it installs the inbound SA when it
 	receives the first Quick Mode (I1) message from the initiator. The
 	outbound SA is installed when it receives the second one (I2).

 	We had a problem with Windows Vista/7 L2TP over IPsec clients
 	and OpenL2TPd on the server side. OpenL2TPd connect(2)s the UDP
 	socket when it receives the SCCRQ from Windows between I1 and I2.
 	Because there's no outbound SA/policy installed at that time the
 	L2TP packet is sent untransformed. Depending on your setup it gets
 	dropped by the local packetfilter or travels to the client in
 	plain text, which in turn drops it then because it's expecting it
 	to be encapsulated. Because OpenL2TPd used connect(2) there's no
 	other route/xfrm lookup done and retransmitted packets continue
 	being sent untransformed even though a policy exists.

 	Installing the inbound SA after the outbound SA prevents this
 	problem in general as it is not limited to L2TP as far as I can
 	tell. Thus, this patch removes the install_inbound_ipsec_sa()
 	function and changes to order in which IPsec SAs are installed to
 	outbound before inbound.

The bug I guess is that Vista sends L2TP traffic before the SA is up. Since
its packet could never receive an answer, it should not be sending yet.

I am not sure if the proposed patch is the proper solution though....

Should we drop all the traffic on an incoming SA until the outbound SA
is fully established?


More information about the Dev mailing list