<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Hi Tobias,<br><br>On Fri, Jul 17, 2015 at 4:39 AM, Tobias Brunner <span dir="ltr"><<a href="mailto:tobias@strongswan.org" target="_blank">tobias@strongswan.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
</span>That would be my take on this.  I initially though of using the<br>
addresses in `right` too, however, there are a several reasons why I<br>
didn't implement it.  left|rightsubnet are already used for policies, so<br>
we don't have to add/change any code.  left|right currently don't have<br>
the same feature set:  Ranges can't currently be used in<br>
left|rightsubnet, and host names would have to be resolved (maybe with a<br>
specific address family, somehow to be determined, as hint) before<br>
installing the policies.  Using left|rightsubnet also allows users to<br>
limit the traffic selectors to certain protocols and ports, which is not<br>
possible with left|right.  And lastly, having two options to achieve the<br>
same thing might be even more confusing.  So I think having right=%any<br>
as a precondition for this and just use left|rightsubnet to define the<br>
policies is much simpler.<br>
<br>
One alternative would we to enable this feature only with a dedicated<br>
flag (i.e. not by right=%any).  That way `right` could still be limited<br>
to certain addresses/subnets to avoid that the config is considered for<br>
other clients (see below).  But that could still lead to<br>
misconfigurations if the values don't match.  There is a situation,<br>
though, where this could really simplify the configuration, which is<br>
where you have very different configs for different sets of hosts.  With<br>
the current solution you'd have to add additional configs with a<br>
matching `right` value _before_ the right=%any configs (while the latter<br>
would fail with mismatching traffic selectors for unrelated clients, no<br>
switch to a matching configuration would happen so late in the process).<br>
<span></span><br></blockquote><div><br></div><div>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.<br><br></div><div>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(*).<br><br></div><div>(*) If the secret is specified per-host, rather than for the range, strongswan does work as a responder. E.G. <br></div><div>   <a href="http://192.168.122.0/24">192.168.122.0/24</a> : PSK "mysecret"<br></div><div>does not work while<br></div><div>   192.168.122.70 : PSK "mysecret"<br></div><div>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.<br><br></div><div>Thanks,<br><br></div><div>-- Stuart<br><br></div></div><br></div></div>