[strongSwan] activate only a small part of a right subnet

Tobias Brunner tobias at strongswan.org
Mon Jun 7 19:04:25 CEST 2021


Hi,

> If I change the 
> rightsubnet to only use this one host, the tunnel will not properly come 
> up, as it does not match the partner settings anymore.

This is called traffic selector (TS) narrowing, and it's one of the
major improvements of IKEv2 over IKEv1.  Unfortunately, some IKEv2
implementations are just minimally patched IKEv1 implementations, so
they don't support narrowing (or multiple TS per CHILD_SA).  I think
this violates RFC 7296, section 2.9 (see [1]), so you may want to report
that to the remote admins.

> Is there a way to 
> build the SA with the large subnet, but internally only add routes for a 
> smaller subnet?

Theoretically, yes.  But there are no configuration options for it.  You
could disable policy installation (installpolicy=no) and do that
manually in an updown script (a route might also be necessary), or you
could write a custom plugin that narrows the local TS before policies
for the IPsec SAs are installed (NARROW_INITIATOR_POST_*).

However, both approaches get complicated by your using traps
(auto=route).   If you disable policy installation, you'd need to
install those trap policies manually too (and the updown script is not
called at that point, so you'd need to do that outside e.g. from a start
script).
And if you don't disable the policy installation and go the plugin
route, you'd need the outbound trap policy (i.e. your configuration) to
be narrow already (it would otherwise capture all traffic to the larger
remote subnet even if the eventually installed policy is narrowed,
because the whole point is to send matching traffic through the IPsec SA
once it exists), then a larger TS has to be negotiated and then a
narrowed TS should again be used when installing policies for the
negotiated IPsec SAs.  That could be done from a plugin as you can, as
mentioned above, change the TS before they are installed and also before
they are sent (NARROW_INITIATOR_PRE_*).  So that's possible but maybe
not that easy if you're not familiar with the codebase.

A simpler alternative could be to install bypass policies for the parts
of the remote TS you don't want to tunnel.  These policies have a higher
priority than regular or trap policies, so traffic matching those
destinations won't trigger traps or get tunneled later.  For instance,
if you have 172.16.0.0/12 as remote subnet and only want to tunnel
traffic to 172.16.4.53/32 (I don't know the actual IP, so...) you need
to add a passthrough connection (see [2]) with the following:


rightsubnet=172.16.0.0/22,172.16.4.0/27,172.16.4.32/28,172.16.4.48/30,172.16.4.52/32,172.16.4.54/31,172.16.4.56/29,172.16.4.64/26,172.16.4.128/25,172.16.5.0/24,172.16.6.0/23,172.16.8.0/21,172.16.16.0/20,172.16.32.0/19,172.16.64.0/18,172.16.128.0/17,172.17.0.0/16,172.18.0.0/15,172.20.0.0/14,172.24.0.0/13

Regards,
Tobias

[1] https://datatracker.ietf.org/doc/html/rfc7296#section-2.9
[2]
https://wiki.strongswan.org/projects/strongswan/wiki/UsableExamples#Passthrough-policy


More information about the Users mailing list