NAT trotz IPv6

[dmark]

Hallo!

Ich bin hier über ein komisches Verhalten gestolpert: Ich verbinde mich mit einem Advanced VPN Client (3.13) per IPv6 mit einem 1906VA-4G (LCOS 10.50 RU2). Der IKEv2 Tunnel wird aufgebaut und funktioniert einwandfrei. Allerdings zeigt der LANMonitor auf dem 1906VA-4G an, dass eine UDP-Encapsulation aufgrund von NAT am entfernten Gateway (also beim Adv. VPN Client) stattfindet. Das Entfernte Gateway wird jedoch mit der korrekten IPv6-Adresse angezeigt.

Client ist ein Win10-PC, der über einen 1783VAW an einem Telekom VDSL hängt. Darüber läuft sowohl IPv4 als auch IPv6.

Was ich nicht verstehe: Warum wird auf IPv6 ohne NAT eben ein NAT festgestellt???
VPN-Client zu alt? Bug im LCOS?

Außerdem: Ich muss im VPN-Profil explizit die IPv6-Adresse eingeben, damit diese auch genutzt wird. bei einem DNS-Namen, der sowohl einen AAAA als auch einen A-Record liefert, wird vom VPN-Client der A-Record genutzt. Warum ist AAAA hier nicht priorisiert? Gelöst habe ich es im Profil mit "IPv6-Adresse;IPv4-Adresse". Aber ein DNS-Name wäre schon schicker.

Viele Grüße, Dirk

[GrandDixence]

Weshalb der VPN-Client auf NAT-Traversal wechselt, müsste im Logbuch des VPN-Clients ersichtlich sein (Logdatei)...
https://www.heise.de/security/artikel/E ... 70056.html

Als Vorbereitung auf die Unterstützung von MOBIKE (siehe Seite 3 im oben stehenden Link) sollte sowieso jeder VPN-Client mit Einwahlverbindung (RAS) standardmässig NAT-Traversal verwenden (also UDP Encapsulation über Serverport UDP 4500). Egal ob mit oder ohne NAT-Komponente im Netzwerkpfad vom VPN-Client zu VPN-Server.

Ob bei der DNS-Namensauflösung der AAAA- oder A-Record verwendet wird, ist üblicherweise eine Betriebssystemkonfiguration. Grundsätzlich ist (heute) die Verwendung von A-Records gegenüber AAAA-Records zu bevorzugen. TCP-, UDP- und QUIC-Netzwerkverbindungen sollten bei einem Dual Stack-Internetanschluss (IPv6 und IPv4) nach Möglichkeit per IPv4 realisiert werden. Zahlreiche Netzwerkübergänge zwischen verschiedenen Netzwerkbetreibern (=> Peering) sind heute (noch) nicht IPv6-tauglich. Was negative Auswirkungen auf die Qualität der Netzwerkverbindung haben kann (=> Peering-Problemen, höhere Paketumlaufzeiten/RTT etc.).

[dmark]

Quelle und Ziel lagen bei dem Test beide im Telekom-Netz. Peering-Probleme würde ich daher ausschließen. MOBIKE hingegen wäre eine plausible Begründung.

Ein nslookup auf den angelegten Hostnamen liefert beide Records zurück, zuerst der AAAA.

Hier der Log-Ausschnitt des Clients:

Code: Alles auswählen

27.01.2022 09:40:09 - IPSec: Start building connection
27.01.2022 09:40:09 - ipsdial: Connecting on unknown interface=fe80:0000:0000:0000:9480:e238:07e9:cd60, setting ESP and IKE use socket
27.01.2022 09:40:10 - Ikev2: Opening connection in PATHFINDER mode : xxxxxxx  IKEv2
27.01.2022 09:40:10 - Ikev2: Outgoing connect request IKEv2 mode - gateway=2003:xxxx:xxxx:0000:0000:0000:0000:0002 : xxxxxxx  IKEv2
27.01.2022 09:40:10 - Ikev2: XMIT_MSG1_INIT - xxxxxxxx  IKEv2,vpngw=2003:xxxx:xxxx:0000:0000:0000:0000:0002:500
27.01.2022 09:40:10 - Ikev2: RECV_MSG2_INIT - xxxxxxxx  IKEv2
27.01.2022 09:40:10 - Ikev2: ConRef=1,Received notify messages - 
27.01.2022 09:40:10 - Ikev2: Notifymsg=<IKEV2_NOTIFY_NAT_DETECTION_SOURCE_IP>
27.01.2022 09:40:10 - Ikev2: Notifymsg=<IKEV2_NOTIFY_NAT_DETECTION_DESTINATION_IP>
27.01.2022 09:40:10 - Ikev2: Notifymsg=<IKEV2_FRAGMENTATION_SUPPORTED>
27.01.2022 09:40:10 - Ikev2: Turning on NATD mode - xxxxxxxxx  IKEv2 - 1
27.01.2022 09:40:10 - IPSec: Final Tunnel EndPoint is=2003:xxxx:xxxx:0000:0000:0000:0000:0002
27.01.2022 09:40:10 - Ike: Turning on IKE fragment mode - xxxxxxxxx  IKEv2
27.01.2022 09:40:10 - Ikev2: RECV_MSG2_INIT - ConRef=1, Remote supports IKEv2 fragmentation
[...]