[strongSwan-dev] Adding support for subnets in transport mode (Feature #196)

[Stuart Daniel]

Hi Tobias,

On Fri, Jul 17, 2015 at 4:39 AM, Tobias Brunner <tobias at strongswan.org>
wrote:

>
> 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
configuration directive.

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
responder(*).

(*) 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
completeness.

Thanks,

-- Stuart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/dev/attachments/20150717/20382140/attachment.html>