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.
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
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
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev
