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

noel.kuntze+strongswan-users-ml at thermi.consulting noel.kuntze+strongswan-users-ml at thermi.consulting
Tue Jul 19 12:28:28 CEST 2022


Hi,

That can be because of MOBIKE. It enables roaming between NATed networks.

Kind regards
Noel

Am 19. Juli 2022 09:56:45 UTC schrieb Tore Anderson <tore at fud.no>:
>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

Sent from mobile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20220719/73416817/attachment.html>


More information about the Users mailing list