On Thu, 24 Sep 2020 at 20:56, Paul Wouters <p...@nohats.ca> wrote: > On Thu, 24 Sep 2020, Andrew Cagney wrote: > > > -> the config file has right[host]=%any > > -> update_ends_from_this_host_addr() (nee default_end()) sees this and > does nothing (right.end.client.maskbits==0) > > (before it would think %any was valid and set .end.client to %any/32 -> > right.end.client.maskbits==32; oops) > > - set_policy_prio() computes c->prio using right.end.client.maskbits, > hence 32,32(old) or 32,0(new) > > Ahh. But conn_prio shouldn't be just maskbits ? >
Probably. I just noticed it was using .client.maskbits. > > -> when that.host_addr=%any, I think the new priority is correct > > for instance, the narrower 1.2.0.0/16 now has higher priority than %any > > Right. > > > -> however, I suspect, when .host_addr is changed (ex, ddns), c->prio > should be re-computed > > But that should be the same weight regardless the IP address? Only the > subnets really change the weight calculation ? But I guess if we have > policies that are a /32 those should match before a 0/0 policy. > This is separate to %any. Once ddns resolves a name it updates .host_addr (from AF_UNSPEC to a valid address). This, in turn, can update .client to .host_addr/32. And updating .client changes .maskbits from 0 to 32, say. Since c->prio is based on .maskbits, should it too be updated? For instance, when the client isn't specified: right=foo should end up using 32 while, per above: right=%any would stick to 0. > > > The other possibility is that the change is too aggressive and > update_ends_from_this_host_addr() should selectively > > update fields (for instance, when %any, skip .host_port and skip > that.host_nexthop) > > I thought the conn prio only changed based on the IPsec policy policy, > so ports only come in play with leftprotoport= and the host_port is > completely unrelated to that ? > Yes. It isn't used to compute the priority. It is one of a number of connection fields that should be updated once the address is known. > > Paul >
_______________________________________________ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev