<html><head></head><body>Hi,<br><br>That can be because of MOBIKE. It enables roaming between NATed networks.<br><br>Kind regards<br>Noel<br><br><div class="gmail_quote">Am 19. Juli 2022 09:56:45 UTC schrieb Tore Anderson <tore@fud.no>:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre dir="auto" class="k9mail">Hi,<br><br>I am trying to understand out why strongSwan (v5.9.5, el8) in an IKEv2<br>initiator role chooses to enable NAT-T even though the NATD hashes<br>received from the responder appear to match the calculated ones.<br><br>In particular I am looking at the following debug log from charon:<br><br>received packet: from y.y.y.y[500] to x.x.x.x[500] (615 bytes)<br>parsed IKE_SA_INIT response 0 [ SA KE No V V N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) V ]<br>(...)<br>precalculated src_hash => 20 bytes @ 0x7f8d4804d540<br>   0: 5C 16 6D FF FB DF 8C 49 A4 F9 7F DE F9 DB DE 56  \.m....I.......V <br>  16: 3F F9 2C 5F                                      ?.,_<br>precalculated dst_hash => 20 bytes @ 0x7f8d48016630<br>   0: AF 97 80 BC 57 8A F8 F3 88 ED D2 F4 63 F9 F8 61  ....W.......c..a <br>  16: 90 37 07 80                                      .7..<br>received src_hash => 20 bytes @ 0x7f8d3004de30<br>   0: 5C 16 6D FF FB DF 8C 49 A4 F9 7F DE F9 DB DE 56  \.m....I.......V <br>  16: 3F F9 2C 5F                                      ?.,_<br>received dst_hash => 20 bytes @ 0x7f8d30084dc0<br>   0: AF 97 80 BC 57 8A F8 F3 88 ED D2 F4 63 F9 F8 61  ....W.......c..a <br>  16: 90 37 07 80                                      .7..<br>(...)<br>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) ]<br>sending packet: from x.x.x.x[4500] to y.y.y.y[4500] (208 bytes)<br><br>The hashes match. I have also verified with Wireshark that these exact<br>hashes also appear in actual packet that arrives on the wire.<br><br>My understanding of NAT-T is that it it is a *mismatch* between the<br>calculated and received hashes that should cause NAT-T to be enabled.<br>Conversely, when the hashes do match, NAT-T should remain disabled.<br><br>What am I missing here? Any suggestsions why strongSwan chooses to<br>enable NAT-T and move to port 4500 for the subsequent IKE_AUTH request?<br><br>Tore<br></pre></blockquote></div><div style='white-space: pre-wrap'>Sent from mobile</div></body></html>