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
NAT trotz IPv6
Moderator: Lancom-Systems Moderatoren
-
- Beiträge: 1061
- Registriert: 19 Aug 2014, 22:41
Re: NAT trotz IPv6
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.).
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.).
Re: NAT trotz IPv6
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:
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
[...]