[strongSwan] NAT-T being enabled even though received NATD hashes matches calculated ones

[Tore Anderson]

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