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

[Phil Nightowl]

Out of other ideas, I resorted to debug logs. To me, the more interesting 
part seems to be the initiator, since the responder reports to have 
established a tunnel successfully:

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}


On the initiator, the (probably) critical part reads

pluto[11791]: "headq"[1] 198.51.100.33 #1: authenticated using RSA with SHA2_512
pluto[11791]: | #1 spent 2.36 (2.36) milliseconds in ikev2_verify_rsa_hash()
pluto[11791]: | parent state #1: PARENT_I2(open IKE SA) => ESTABLISHED_IKE_SA(established IKE SA)
pluto[11791]: | #1 will start re-keying in 27807 seconds with margin of 993 seconds (attempting re-key)
pluto[11791]: | state #1 deleting .st_event EVENT_SA_REPLACE
pluto[11791]: | delref libevent at 0x55d4e9c53088(1->0) (in libevent_free() at server.c:985)
pluto[11791]: | delref pe at 0x55d4e9c49018(1->0) (in free_event_entry() at server.c:476)
pluto[11791]: | event_schedule: newref EVENT_SA_REKEY-pe at 0x55d4e9c49018
pluto[11791]: | inserting event EVENT_SA_REKEY, timeout in 27807 seconds for #1
pluto[11791]: | newref libevent at 0x55d4e9c5dd68(0->1) (in libevent_malloc() at server.c:969)
pluto[11791]: | pstats #1 ikev2.ike established
pluto[11791]: | FOR_EACH_STATE_... in nat_traversal_ka_event (for_each_state)
pluto[11791]: | skipping NAT-T KEEP-ALIVE: #2 is not current IKE SA
pluto[11791]: | we are behind NAT: sending of NAT-T KEEP-ALIVE for conn headq
pluto[11791]: | ka_event: send NAT-KA to 198.51.100.33:4500 (state=#1)
pluto[11791]: | sending NAT-T Keep Alive
pluto[11791]: | sending 1 bytes for NAT-T Keep Alive through enp2s0 from 10.0.1.138:4500 to 198.51.100.33:4500 using UDP (for #1)
pluto[11791]: |   ff
pluto[11791]: | global one-shot timer EVENT_NAT_T_KEEPALIVE scheduled in 20 seconds
pluto[11791]: | TSi: parsing 1 traffic selectors
pluto[11791]: | ***parse IKEv2 Traffic Selector Header:
pluto[11791]: |    TS type: IKEv2_TS_IPV4_ADDR_RANGE (0x7)
pluto[11791]: |    IP Protocol ID: ALL (0x0)
pluto[11791]: |    length: 16 (00 10)
pluto[11791]: | ****parse IKEv2 IP Traffic Selector port range:
pluto[11791]: |    start port: 0 (00 00)
pluto[11791]: |    end port: 65535 (ff ff)
pluto[11791]: | parsing 4 raw bytes of IKEv2 Traffic Selector Header into TS IP start
pluto[11791]: | TS IP start
pluto[11791]: |   5e c7 62 37
pluto[11791]: | parsing 4 raw bytes of IKEv2 Traffic Selector Header into TS IP end
pluto[11791]: | TS IP end
pluto[11791]: |   5e c7 62 37
pluto[11791]: | TSi: parsed 1 traffic selectors
pluto[11791]: | TSr: parsing 1 traffic selectors
pluto[11791]: | ***parse IKEv2 Traffic Selector Header:
pluto[11791]: |    TS type: IKEv2_TS_IPV4_ADDR_RANGE (0x7)
pluto[11791]: |    IP Protocol ID: ALL (0x0)
pluto[11791]: |    length: 16 (00 10)
pluto[11791]: | ****parse IKEv2 IP Traffic Selector port range:
pluto[11791]: |    start port: 0 (00 00)
pluto[11791]: |    end port: 65535 (ff ff)
pluto[11791]: | parsing 4 raw bytes of IKEv2 Traffic Selector Header into TS IP start
pluto[11791]: | TS IP start
pluto[11791]: |   c0 a8 85 f0
pluto[11791]: | parsing 4 raw bytes of IKEv2 Traffic Selector Header into TS IP end
pluto[11791]: | TS IP end
pluto[11791]: |   c0 a8 85 f0
pluto[11791]: | TSr: parsed 1 traffic selectors
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
pluto[11791]: | job 4 for #2: initiator decoding certificates (decode certificate payload): calling cleanup function 0x55d4e84f4250
pluto[11791]: | delref mdp at 0x55d4e9c47808(2->1) (in cert_decode_cleanup() at cert_decode_helper.c:195)
pluto[11791]: | delref root_certs at 0x55d4e9c470b8(2->1) (in cert_decode_cleanup() at cert_decode_helper.c:196)
pluto[11791]: | delref logger at 0x55d4e9c56e78(1->0) (in handle_helper_answer() at server_pool.c:457)
pluto[11791]: | delref fd at NULL (in free_logger() at log.c:677)
pluto[11791]: | delref fd at NULL (in free_logger() at log.c:678)
pluto[11791]: | #2 complete_v2_state_transition() PARENT_I2->ESTABLISHED_CHILD_SA with status STF_FAIL+v2N_TS_UNACCEPTABLE; .st_v2_transition=NULL
pluto[11791]: "headq"[1] 198.51.100.33 #2: state transition 'Initiator: process IKE_AUTH response' failed with v2N_TS_UNACCEPTABLE
pluto[11791]: | delref mdp at 0x55d4e9c47808(1->0) (in resume_handler() at server.c:733)
pluto[11791]: | delref logger at 0x55d4e9c57138(1->0) (in resume_handler() at server.c:733)
pluto[11791]: | delref fd at NULL (in free_logger() at log.c:677)
pluto[11791]: | delref fd at NULL (in free_logger() at log.c:678)
pluto[11791]: | #2 spent 3.87 (3.87) milliseconds in resume sending helper answer back to state
pluto[11791]: | delref libevent at 0x7f6ebc0170b8(1->0) (in libevent_free() at server.c:985)
pluto[11791]: | processing global timer EVENT_SHUNT_SCAN
pluto[11791]: | checking for aged bare shunts from shunt table to expire
pluto[11791]: | spent 0.0259 (0.0253) milliseconds in global timer EVENT_SHUNT_SCAN
pluto[11791]: | processing global timer EVENT_NAT_T_KEEPALIVE

Can you please confirm if that this is really a TS mismatch? And if that 
is the case, can you see whether origin of the problem is on the 
initiator or the responder side? Of course, I'd appreciate any 
suggestions to what to adjust in my config.

Many thanks,

Phil