[strongSwan-dev] Adding support for subnets in transport mode (Feature #196)
stuartd at lexmark.com
Fri Jul 17 21:59:19 CEST 2015
On Fri, Jul 17, 2015 at 4:39 AM, Tobias Brunner <tobias at strongswan.org>
> That would be my take on this. I initially though of using the
> addresses in `right` too, however, there are a several reasons why I
> didn't implement it. left|rightsubnet are already used for policies, so
> we don't have to add/change any code. left|right currently don't have
> the same feature set: Ranges can't currently be used in
> left|rightsubnet, and host names would have to be resolved (maybe with a
> specific address family, somehow to be determined, as hint) before
> installing the policies. Using left|rightsubnet also allows users to
> limit the traffic selectors to certain protocols and ports, which is not
> possible with left|right. And lastly, having two options to achieve the
> same thing might be even more confusing. So I think having right=%any
> as a precondition for this and just use left|rightsubnet to define the
> policies is much simpler.
> One alternative would we to enable this feature only with a dedicated
> flag (i.e. not by right=%any). That way `right` could still be limited
> to certain addresses/subnets to avoid that the config is considered for
> other clients (see below). But that could still lead to
> misconfigurations if the values don't match. There is a situation,
> though, where this could really simplify the configuration, which is
> where you have very different configs for different sets of hosts. With
> the current solution you'd have to add additional configs with a
> matching `right` value _before_ the right=%any configs (while the latter
> would fail with mismatching traffic selectors for unrelated clients, no
> switch to a matching configuration would happen so late in the process).
Thanks for the detailed explanation. I would prefer going with an
alternative trigger than right=%any. One possible trigger could be
right=%subnet, which would point the administrator to the correct
I've done some more testing, and so far the updated trap-any branch works
well as long as the authentication is certificate based. Pre-shared keys
fail, however, whether strongswan is operating as the initiator or the
(*) If the secret is specified per-host, rather than for the range,
strongswan does work as a responder. E.G.
192.168.122.0/24 : PSK "mysecret"
does not work while
192.168.122.70 : PSK "mysecret"
works, albeit only for that specific remote. PSK support for this feature
is not required for our needs, but I wanted to investigate it for
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Dev