Hi Tobias, On Fri, Jul 17, 2015 at 4:39 AM, Tobias Brunner <[email protected]> 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
_______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
