Hi Stuart, > This could be construed as a misconfiguration
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). > but my reading of the documentation implies that it is valid to specify > a range for right. Yes, but only as responder to limit the clients for which a config is considered. To initiate a connection (without trap-any) an IP or host name is required (the first one is used), as documented on the man and wiki pages. Regards, Tobias _______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
