Hi Tobias,
It seems the solution you suggested works fine as long as there is no traffic
selector narrowing involved.
Example:
On the responder -> 192.168.120.0/24 === 192.168.110.0/24
On the initiator -> 192.168.110.0/25 === 192.168.120.0/25
On the responder
# setkey -DP
192.168.110.0/24[any] 192.168.120.0/24[any] 255
in discard
created: Oct 9 11:12:40 2015 lastused: Oct 9 11:12:40 2015
lifetime: 9223372036854775807(s) validtime: 0(s)
spid=112 seq=1 pid=5405
refcnt=1
192.168.120.0/24[any] 192.168.110.0/24[any] 255
out discard
created: Oct 9 11:12:40 2015 lastused: Oct 9 11:12:40 2015
lifetime: 9223372036854775807(s) validtime: 0(s)
spid=111 seq=0 pid=5405
refcnt=1
After negotiation and effective narrowing:
# setkey -DP
V50XXA4B0000045>showSPD
192.168.110.0/24[any] 192.168.120.0/24[any] 255
in discard
created: Oct 9 11:12:40 2015 lastused: Oct 9 11:14:11 2015
lifetime: 9223372036854775807(s) validtime: 0(s)
spid=112 seq=3 pid=5406
refcnt=1
192.168.110.0/25[any] 192.168.120.0/25[any] 255
in ipsec
esp/tunnel/192.168.56.110-192.168.56.120/unique:1
created: Oct 9 11:14:09 2015 lastused: Oct 9 11:14:09 2015
lifetime: 9223372036854775807(s) validtime: 0(s)
spid=116 seq=2 pid=5406
refcnt=1
192.168.120.0/24[any] 192.168.110.0/24[any] 255
out discard
created: Oct 9 11:12:40 2015 lastused: Oct 9 11:12:40 2015
lifetime: 9223372036854775807(s) validtime: 0(s)
spid=111 seq=1 pid=5406
refcnt=1
192.168.120.0/25[any] 192.168.110.0/25[any] 255
out ipsec
esp/tunnel/192.168.56.120-192.168.56.110/unique:1
created: Oct 9 11:14:09 2015 lastused: Oct 9 11:14:09 2015
lifetime: 9223372036854775807(s) validtime: 0(s)
spid=115 seq=0 pid=5406
refcnt=1
Packets are successfully received (the SPD is not checked for incoming packets)
But packets are never sent, they seem to be dropped by the kernel (the lastused
of the out discard policy is refreshed)
What do you think?
Emeric
----- Mail original -----
De: "Tobias Brunner" <[email protected]>
À: "Emeric POUPON" <[email protected]>
Cc: [email protected]
Envoyé: Lundi 5 Octobre 2015 18:20:35
Objet: Re: [strongSwan-dev] patch proposal: ignore acquire
Hi Emeric,
> I guess you are not interested by the "ignore_acquire" approach?
Not really. Drop policies are exactly for this purpose, while trap
policies are to trigger IKE/IPsec SAs, not to drop traffic. Ignoring
acquires makes not much sense, in particular because the kernel's
behavior is quite different when traffic matches a trap policy. The
kernel might create a temporary SA and cache packets until the SA is
established, so that could require lots of resources if the other peer
does not establish the connection for a while. And depending on the OS
settings and the traffic the kernel might send lots of acquires to the
daemon (for instance, on FreeBSD the default is to trigger an acquire
every 10th packet, see net.key.blockacq_count).
> The only drawback is that we have to manually add a "drop" connection for
> each "responder only" connection.
Using the `also` keyword you could simplify this and avoid having to
duplicate the traffic selector definition (e.g. define left|rightsubnet
in the "drop" connection and include it in the "responder" connection
and override/add settings appropriately).
Regards,
Tobias
_______________________________________________
Dev mailing list
[email protected]
https://lists.strongswan.org/mailman/listinfo/dev
