On Tue, 27 Feb 2024, Phil Nightowl wrote:
pluto[30425]: "remotesite"[1] 203.0.113.55 #2: responder established Child SA using #1;
IPsec tunnel [192.168.1.253-192.168.1.253:0-65535 0] -> [203.0.113.55-203.0.113.55:0-65535 0]
{ESPinUDP=>0x7522bc14 <0x80c5c828 xfrm=AES_GCM_16_256-NONE NATD=203.0.113.55:4500
DPD=passive}
So responder likes 192.168.1.253/32 <-> 203.0.113.55/32
On the initiator, the (probably) critical part reads
pluto[11791]: | evaluating our conn="headq"[1] 198.51.100.33 I=0.0.0.0/0:0:0/0
R=192.168.1.253/32:0:0/0 to their:
pluto[11791]: | TSi[0] .net=203.0.113.55-203.0.113.55 .iporotoid=0
.{start,end}port=0..65535
pluto[11791]: | match address end->client=0.0.0.0/0 >=
TSi[0]net=203.0.113.55-203.0.113.55: NO
pluto[11791]: | reject responder TSi/TSr Traffic Selector
Looks like client is missing narrowing=yes, and now insists on getting
the whole 0/0 <-> 0/0 instead of allowing the server to narrow it down
to a single /32 to /32 tunnel.
Paul
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
