[Swan-dev] ikev1-hostpair-01 and c->prio

Andrew Cagney andrew.cagney at gmail.com
Fri Sep 25 02:01:28 UTC 2020

On Thu, 24 Sep 2020 at 20:56, Paul Wouters <paul at 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 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
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:
should end up using 32 while, per above:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20200924/26ffd36c/attachment-0001.html>

More information about the Swan-dev mailing list