[Swan-dev] Finding connections with %any fails due to only searching hostpair

Andrew Cagney andrew.cagney at gmail.com
Wed Mar 17 16:36:53 UTC 2021


On Wed, 17 Mar 2021 at 12:20, Paul Wouters <paul at nohats.ca> wrote:
>
> On Wed, 17 Mar 2021, Andrew Cagney wrote:
>
> >> It's concept is really for left/right on the same IP (which is also an
> >> issue, with multiple behind NAT). Which is why I think the concept of
> >> hostpair is not sustainable. This isn't the first time code needed to
> >> be changed to search all connections :/
> >
> > I still don't follow.
> >
> >> From the bug. Before any connection, A's host-pair contains the
> > oriented template:
> >
> >  local=192.168.173.129 remote = %any : A(template)
> >
> > after one connection it contain both an oriented template and an
> > oriented instance:
> >
> >  A(template): local=192.168.173.129 remote = %any :
> >  A(instance): local=192.168.173.129 remote = 192.168.173.144
> >
> > the above lookup is only for 192.168.173.129->192.168.173.144, if it
> > also looked for 192.168.173.129->unset_address, it would find the
> > template.  Which I'm guessing is what is needed.
>
> But the hostpair of a connection contains the specific remote peer IP.

Only a non-template connection.  Hostpair breaks oriented connections
down into and maintains lookups for:

local:<unset>
local:remote

this is really old behaviour.  Most code using these tables makes two calls:

    for-each-host-pair(local, remote)
        do something
    well if that something failed then
        for-each-host-pair(local, <unset>)
            so something-else but I suspect it is similar to something

that the TS code doesn't do this seem to be a standout

> The idea used to be that all connections of a hostpair share the same
> IKE IDs. Eg there is no difference in authentication. So picking up
> all "%any" is not the right thing to do. You should really only pick
> up a match for local=192.168.173.129 remote = %any localid=east remoteid=west

Presumably something-else in the above would check those additional predicates.

> Especially because we just did authentication.
>
> Our IKEv2 code is not the best for its way of decision making during the
> consumption of IKE_AUTH as responder.
>
> Paul


More information about the Swan-dev mailing list