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

[Phil Nightowl]

Hello,

still could not get it fixed so far. Is there perhaps an overview of the 
testing configurations? 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?

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