[Swan] Possible to setup multiple connections, partly behind NAT?

[Paul Wouters]

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 at 0x55d4e9c33508(2->1) (in add_connection() at connections.c:2110)
>> pluto[11791]: | delref fd at 0x55d4e9c33508(1->0) (in whack_handle_cb() at rcv_whack.c:943)
>> pluto[11791]: | freeref fd-fd at 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
>