[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