[Swan] ipsec traffic leak

Xinwei Hong xhong at skytap.com
Thu May 4 22:37:45 UTC 2017


Hi,

I have a policy-based ipsec setting where I only have one end ready and we
are waiting for other end to connect to it. So, the VPN tunnel is not
actually created yet. When we try to ping an address in remote subnet
(presumably), the traffic could leak out to network through its interface.
I checked and found this xfrm entry was missing.

# ip xfrm policy
src 10.100.0.0/16 dst 10.200.0.0/16
dir out priority 2608
tmpl src 0.0.0.0 dst 0.0.0.0
proto esp reqid 0 mode transport
When this entry exists, pkt will be dropped as expected.

If I have all config ready and do a "ipsec start", that entry is added and
pkt go dropped. If I do a ipsec auto --down/delete/add/up, I suppose we can
get same behavior as "ipsec start", i.e. the entry is added. However, the
entry will not be added and traffic get routed out. If the remote peer goes
up and connect to this terminal, the entry will be added correctly. Do you
know any reason why this behavior difference? How can we make sure no
traffic gets leaked out while we are waiting for the peer to connect?

I do see the following log when the entry is not added.
May 3 22:29:08 vvr-10-69-244-34 pluto[22363]: vpn-5483483: WARNING: using a
weak secret (PSK)
May 3 22:29:08 vvr-10-69-244-34 pluto[22363]: vpn-5483483:
"conn_vpn-5483483-tunnel-VPNRemoteRoutedSubnet-tunnel-10.200.0.0/16" #1:
initiating Main Mode
May 3 22:29:08 vvr-10-69-244-34 pluto[22363]: vpn-5483483:
"conn_vpn-5483483-tunnel-VPNRemoteRoutedSubnet-tunnel-10.200.0.0/16":
*deleting* non-instance connection
May 3 22:29:08 vvr-10-69-244-34 pluto[22363]: vpn-5483483:
"conn_vpn-5483483-tunnel-VPNRemoteRoutedSubnet-tunnel-10.200.0.0/16" #1:
*deleting* state (STATE_MAIN_I1)
May 3 22:29:08 vvr-10-69-244-34 pluto[22363]: vpn-5483483: added connection
description
"conn_vpn-5483483-tunnel-VPNRemoteRoutedSubnet-tunnel-10.200.0.0/16"

The "deleting .." was not there when we do "ipsec start". Not sure if the
SPD policy entry was deleted during the time. (in both cases, remote peer
is not ready or does not exist)


Thanks,
Xinwei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20170504/a5f4b693/attachment.html>


More information about the Swan mailing list