[Openswan dev] traffic leak on openswan with Win7/Vista L2TP
paul at xelerance.com
Tue Nov 23 13:49:03 EST 2010
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