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

[Phil Nightowl]

> > 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