Hi, I am trying to understand out why strongSwan (v5.9.5, el8) in an IKEv2 initiator role chooses to enable NAT-T even though the NATD hashes received from the responder appear to match the calculated ones.
In particular I am looking at the following debug log from charon: received packet: from y.y.y.y[500] to x.x.x.x[500] (615 bytes) parsed IKE_SA_INIT response 0 [ SA KE No V V N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) V ] (...) precalculated src_hash => 20 bytes @ 0x7f8d4804d540 0: 5C 16 6D FF FB DF 8C 49 A4 F9 7F DE F9 DB DE 56 \.m....I.......V 16: 3F F9 2C 5F ?.,_ precalculated dst_hash => 20 bytes @ 0x7f8d48016630 0: AF 97 80 BC 57 8A F8 F3 88 ED D2 F4 63 F9 F8 61 ....W.......c..a 16: 90 37 07 80 .7.. received src_hash => 20 bytes @ 0x7f8d3004de30 0: 5C 16 6D FF FB DF 8C 49 A4 F9 7F DE F9 DB DE 56 \.m....I.......V 16: 3F F9 2C 5F ?.,_ received dst_hash => 20 bytes @ 0x7f8d30084dc0 0: AF 97 80 BC 57 8A F8 F3 88 ED D2 F4 63 F9 F8 61 ....W.......c..a 16: 90 37 07 80 .7.. (...) generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_6_ADDR) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ] sending packet: from x.x.x.x[4500] to y.y.y.y[4500] (208 bytes) The hashes match. I have also verified with Wireshark that these exact hashes also appear in actual packet that arrives on the wire. My understanding of NAT-T is that it it is a *mismatch* between the calculated and received hashes that should cause NAT-T to be enabled. Conversely, when the hashes do match, NAT-T should remain disabled. What am I missing here? Any suggestsions why strongSwan chooses to enable NAT-T and move to port 4500 for the subsequent IKE_AUTH request? Tore
