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@0x55d4e9c53088(1->0) (in libevent_free() at
server.c:985)
pluto[11791]: | delref pe@0x55d4e9c49018(1->0) (in free_event_entry() at
server.c:476)
pluto[11791]: | event_schedule: newref EVENT_SA_REKEY-pe@0x55d4e9c49018
pluto[11791]: | inserting event EVENT_SA_REKEY, timeout in 27807 seconds for #1
pluto[11791]: | newref libevent@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@0x55d4e9c47808(2->1) (in cert_decode_cleanup() at
cert_decode_helper.c:195)
pluto[11791]: | delref root_certs@0x55d4e9c470b8(2->1) (in
cert_decode_cleanup() at cert_decode_helper.c:196)
pluto[11791]: | delref logger@0x55d4e9c56e78(1->0) (in handle_helper_answer()
at server_pool.c:457)
pluto[11791]: | delref fd@NULL (in free_logger() at log.c:677)
pluto[11791]: | delref fd@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@0x55d4e9c47808(1->0) (in resume_handler() at
server.c:733)
pluto[11791]: | delref logger@0x55d4e9c57138(1->0) (in resume_handler() at
server.c:733)
pluto[11791]: | delref fd@NULL (in free_logger() at log.c:677)
pluto[11791]: | delref fd@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@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
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
