[Swan-dev] hold/trap + acquires causing multiple IPsec negotiations

Paul Wouters paul at nohats.ca
Tue May 5 01:50:48 EEST 2015

On Mon, 4 May 2015, Tuomo Soini wrote:

> Subject: [Swan-dev] hold/trap + acquires causing multiple IPsec negotiations

[Talked to Tuomo offlist, but I'll summarize it here too]

> We have some problem in our initiation code, both ikev1 and ikev2. If
> we have traffic which matches our ipsec policy when we are negotiating
> a tunnel it causes us to negotiate several tunnels.
> I didn't check further but I'm quite sure we before had a check in code
> that if there was already matching tunnel negotiation we didn't start
> new one when acquired - now we get new tunnel negotiation. So
> restarting pluto on ipsec-gw causes road warrior to negotiate like 6
> IPsec SAs because of acquires instead of one required.

This is caused by a difference between KLIPS and NETKEY. We have
addressed this on a branch related to OE that will soon be merged into

KLIPS gives an acquire with the src and dst IP address only.

NETKEY gives an acquire with the src and dst IP address + ports and
protocol. (ports maybe be blanc if the application does a connect()
before it sends a packet, since the connect() already triggers the

We convert the acquire into a hold "bare shunt". (and KLIPS would also
cache first+last packet)

The code in master still only installs a shunt equal to what it
received, so for NETKEY it installs a shunt that only covers that one
packet flow. If a new flow happens (like a new ephemeral source port)
it would not be caught.

Combine these with the ping command, that uses a UDP connect() call to
the destination IP to determine its source IP, then you see acquires.
One for UDP and one for ICMP.

The code currently in the OE branch widens the hold to cover all
transport protocols and all ports. This works for OE, but before we
merge this back into master, we need to actually lookup the connection
we found, check its protoport= settings and only widen it to that set.


More information about the Swan-dev mailing list