On Fri, 1 Mar 2024, Phil Nightowl wrote:
still could not get it fixed so far. Is there perhaps an overview of the
testing configurations?
Not a real overview, but there is a list. Each of the entries has its
own description.txt file:
https://github.com/libreswan/libreswan/blob/main/testing/pluto/TESTLIST
And do you perhaps know off the top of your head if
this scenario (both ends behind NAT) is covered, i. e. guaranteed to be
working? And is it possible to find out since which version that particular
testing case has been introduced?
If both are behind NAT, it means at least one of these must work as
responder, meaning its NAT router must forward UDP port 500 and 4500
to it. That one should use auto=add. The other end should use auto=start
As both are behind NAT, you likely mean to use leftsubnet=yourinternalIP1/32
and rightsubnet=theirinternalIP2/32. Both ends can use
left=%defaultroute and right=OtherPublicIP. To ensure there is no mixups
of IPs with IDs, use names as IDs for each, ef leftid=@John with rightid=@Steve
If you use "left is local, right is remote" on both ends to pick left
and right, make sure that you don't forget to swap the internalIPs to
the right ones in the subnet= options.
Paul
Phil
On Út 27. února 2024, 23:56:31, 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
Makes sense (so I think, at least).
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.
This shouldn't be the case. I double-checked the config. And to be really
sure, I've looked in the debug logs again. Somewhere at the beginning of the
(very same) connection setup, there is (initiator logfile):
pluto[11791]: "headq": loaded private key matching left certificate
'remotehost1'
pluto[11791]: | counting wild cards for C=XX, O=MyOrg, CN=remotehost1.privlan
is 0
pluto[11791]: | counting wild cards for %fromcert is 0
pluto[11791]: | updating connection from left.host_addr
pluto[11791]: | right host_nexthop 10.0.1.138
pluto[11791]: | update_ends_from_this_host_addr() left.host_port: 0->500
pluto[11791]: | updating connection from right.host_addr
pluto[11791]: | update_ends_from_this_host_addr() right.host_port: 0->500
pluto[11791]: | based upon policy narrowing=yes, the connection is a template.
pluto[11791]: | orienting "headq"
pluto[11791]: | left(THIS) host-address=10.0.1.138 host-port=500 ikeport=0
encap=no
pluto[11791]: | right(THAT) host-address=198.51.100.33 host-port=500
ikeport=0 encap=no
pluto[11791]: "headq": added IKEv2 connection
pluto[11791]: | ike_life: 28800; ipsec_life: 3600s; rekey_margin: 540s;
rekey_fuzz: 100%; keyingtries: 0; replay_window: 32; policy:
RSASIG+ENCRYPT+TUNNEL+PFS+IKEV2_ALLOW_NARROWING+IKE_FRAG_ALLOW+ESN_NO+RSASIG_v1_5+failureDROP
pluto[11791]: | 0.0.0.0/0===10.0.1.138[C=GR, O=MyOrg,
CN=remotehost1.privlan]---10.0.1.1...198.51.100.33<198.51.100.33>[%fromcert]===192.168.1.253/32
pluto[11791]: | delref fd@0x55d4e9c33508(2->1) (in add_connection() at
connections.c:2110)
pluto[11791]: | delref fd@0x55d4e9c33508(1->0) (in whack_handle_cb() at
rcv_whack.c:943)
pluto[11791]: | freeref fd-fd@0x55d4e9c33508 (in whack_handle_cb() at
rcv_whack.c:943)
pluto[11791]: | spent 22.6 (115) milliseconds in whack
To me, it seems that pluto is indeed narrowing down (or I at least read it
saying so).
Phil
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
