TunnelVPN und IPv6

Immer mehr Internetprovider stellen an den Privatanschlüssen eine IPv6-Verbindung parallel bereit. Wer für die Sicherheit einer Firma zuständig ist und auf Tunnel-VPNs vertraut, sollte die Auswirkungen auf das IP-Routing kennen. Nicht alle VPN-Lösungen sichern den Tunnel auch für IPv6 ab. Das Problem ist schon länger beschrieben, aber ich habe dem trotzdem eine eigene Seite gewidmet.

Diese Seite ist auch für Microsoft 365 und IPv6 wichtig.

Auslöser

Wie so oft ist es ein Support-Einsatz bei einem Kunden, der in dem Fall Probleme mit Skype for Business On-Premises hatte. Ein Teil der Anwender sitzt im Homeoffice mit einem Windows SSTP-TunnelVPN. und wir haben über das UCCAPILOG auf dem Client nach Fehlern gesucht. Dabei gab es auch eine 1:1 Audioverbindung zwischen einem VPN-Anwender und einem Homeoffice-User ohne VPN. Wie erwartet haben wir das "Angebot" des VPN-Benutzers und des Nicht-VPN-Benutzers gesehen:

  • ICE Kandidaten des Users ohne VPN oder mit SplitVPN

    Sie sehen die direkten Kandidaten ("typ host") und auch eine IPv6 Adresse. Weiterhin gibt es natürlich die Relay-Kandidaten, die der Edge-Server bereitstellt und ohne VPN kann der Client auch meine NAT-Adressen (STUN) anbieten. In dem Moment hatte ich wohl die 94.31.83.223 (Deutsche Glasfaser) als externe Adresse.
  • Im Gegenzug bietet mir der Homeoffice User mit Tunnel-VPN seine Kandidaten an:

    Sie sehen, dass der Host auch eine IPv6 Adresse anbietet. Das ist aber, anders als die private IP-Adresse 192.168.178.91 aus dem Fritz!Box Netzwerk eine offiziell routbare Adresse. Auch hier gibt es TURN-Adressen ("type relay") und die NAT-Adresse (gelb) zeigt auf eine private Adresse. Da scheint das IPv4-Paket durch den Tunnel zu gehen und der STUN-Server konnte keine öffentliche Adresse melden.
  • Handshake
    Der von den beiden Endpunkten ausgehandelte ICE-Handshake ist nicht zu sehen aber das Ergebnis sehen wir im nächsten INVITE:

    Der anrufende Client ohne VPN bietet seine IPv6-Adresse an und meldet den IPv6-Kandidaten des Ziels als Gegenstelle
  • Betätigung des Ziels
    Dort sehen wir dann die Rückrichtung, die ebenfalls IPv6 nutzt

Damit ist bestätigt, dass das Windows SSTP-VPN in der Kunden-Konfiguration "nicht ganz dicht" ist. IPv6 umgeht den Tunnel.

Testen

Wenn Sie nun unsicher sind, ob ihr Internetzugang schon IPv6 anbietet und ihr Tunnel-VPN für IPv6 durchlässig ist, dann reicht in der Regel ein Browser und die passenden URLs. Wenn der Browser nicht durch HTTP-Proxy-Einstellungen umgelenkt wird, dann versucht er den Namen des Hosts aufzulösen und mit einer IPv6-Konfiguration findet er auch IPv6-Gegenstellen.

Je nach Konfiguration gibt es mehrere mögliche Antworten, die aber paarweise gleich aussehen

Lokales IPv6 Tunnel mit IPv6 Status Ergebnis

Nein

Ja

Sicher

Der Client könnte ein IPv4-basierte VPN zur Firma aufmachen und damit eine IPv6-Adresse der Firma erhalten. Sie sehen dann auf den Webseiten eine funktionierende IPv6-Verbindnug mit einer IP-Adresse aus ihrer Firma

Nein

Nein

Sicher

Die IPV6-Verbindungen werden nicht funktionieren. Die Webseiten sollten einen Fehler anzeigen

Ja

Ja

Sicher

Der Client kann ein IPv4 oder IPv6-VPN zur Firma aufbauen und von dort eine IPv6-Adresse erhalten. Die Webseiten sollten eine IPv6-Adresse der Firma zeigen

Ja

Nein

Unsicher

Wenn der Client über das VPN keine IPv6-Pakete routen kann, dann gibt es auch kein "Default Gateway" ins VPN. In dem Fall wird der Client höchstwahrscheinlich ihre schöne IPv4-Tunnelkonfiguration für IPv6-Verbindungen ignorieren.

Ohne Browser können Sie natürlich auch mit NSLOOKUP nach Hostnamen suchen, die nur per IPv6 auflösbar sind sind. So nutzt https://test-ipv6.com/ per JavaScript den Host ipv6.ams2.test-ipv6.com. (Kann sich ändern), den sie per PowerShell nur mit einem AAAA-Record auflösen können.

PS C:\> Resolve-DnsName ipv6.ams2.test-ipv6.com -Type A

Name                        Type TTL   Section    PrimaryServer               NameAdministrator           SerialNumber
----                        ---- ---   -------    -------------               -----------------           ------------
test-ipv6.com               SOA  93    Authority  ns1.test-ipv6.com           jfesler.test-ipv6.com       2016030401

PS C:\> Resolve-DnsName ipv6.ams2.test-ipv6.com -Type AAAA

Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
ipv6.ams2.test-ipv6.com                        AAAA   90    Answer     2a00:dd80:3c::8aa

Systeme die über IPv4 und IPv6 auflösbar sind, liefern nur dann beide Adressen, wenn auch eine IPv6-Auflösung per DNS möglich ist

PS C:\> Resolve-DnsName www.msxfaq.de

Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
www.msxfaq.de                                  AAAA   600   Answer     2a01:488:42:1000:b24d:7562:25:6783
www.msxfaq.de                                  A      423   Answer     178.77.117.98

Lassen Sie sich aber nicht täuschen, wenn sie keine IPv6-Auflösung haben. VoIP und ICE nutzen keine DNS-Auflösung für die Kandidaten und Malware kann auch DNS zur Suche der Gegenstelle verzichten.

Eigentlich schade, dass die meisten Office 365/Microsoft 365-Dienste nicht IPv6 nutzen und so einen Tunnel umgehen könnten.

Lösen

Wer heute ein "Tunnel-VPN" einrichtet um einen Nebeneingang oder Bypass im Home-Office zu verhindern, möchte natürlich sicherstellen, dass dies für jegliche Kommunikation sichergestellt ist. Der erste Schritt nach dem Testen ist daher die Kontrolle ihrer VPN-Lösung, wie diese mit IPv6 umgeht. Es gibt meiner Ansicht nach mehrere Optionen, die Sicherheit eines Clients hier zu verbessern.

  • IPv6 im VPN-Tunnel zu aktivieren
    Aktuell existiert der Nebenausgang mit IPv6 ja nur, weil das normale VPN sich nur um IPv4 kümmert und daher beim Verbindungsaufbau die "Default Route" eben auch nur für IPv4 umsetzt. Der beste, und empfohlene Weg wäre die Ausweitung des VPN auf IPv6. Es könnte ja auch sein, dass sie im Firmennetzwerk schon mit IPv6 arbeiten und dann würde es schnell auffallen, wenn VPN-Anwender diese IPv6-Only-Dienst nicht erreichen könnten. Leider denken viele Firmen nicht einmal über IPv6 im LAN nach und im VPN schon gar nicht.

    Sie müssten ja nur im VPN einrichten, dass auch die VPN-Verbindung in den IPv6-Einstellungen das Standardgateway ins Firmennetzwerk umbiegt.

Achtung:
Allein ein IPv6-Defaultgateway in der VPN-Einstellung reicht nicht aus. Sie brauchen zumindest auf dem VPN auch eine IPv6-Adresse. Ein wenig IPv6-Deployment im Firmennetz ist daher schon erforderlich.

  • IPv6 am Client blockieren
    Es gibt VPN-Produkte, die IPv6 auf dem Client aktiv unterbinden. Dabei darf nicht nur das Routing sondern auch die DNS64-Auflösung angepasst werden. Wenn Sie aber keinen DNSv6-Server betreiben, wird der Client auch keine AAAA-Adressen auflösen. Denken Sie aber daran, dass ICE nicht auf DNS basiert
  • IPv6 im Homenetz abschalten
    Wenn der Client keine lokale IPv6-Verbindung hat, kann er sie auch nicht als Bypass nutzen. So können Sie in einer Fritz!Box die IPv6-Funktion abschalten und damit IPv4 erzwingen. Allerdings kann diese Einstellung nicht durch die IT kontrolliert werden und ist bei öffentlichen WLAN-Access Points nicht erzwingbar. Zudem widerspricht es ja dem Ziel, IPv6 überall bereitzustellen.
  • IPv6 auf dem Client deaktivieren
    Wenn der Client gar nicht erst IPv6 unterstützt, kann er ebenfalls nicht am VPN vorbei gehen. Diese Einstellung blockiert aber jede interne IPv6 Nutzung. Es gibt viele unterschiedliche und falsche Beschreibungen. Supported und leistungsfähig ist die Vorgabe von Microsoft:
    Guidance for configuring IPv6 in Windows for advanced users (https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/configure-ipv6-in-windows)

Für eine "schnelle Lösung" könnten Sie z.B. per Gruppenrichtlinie oder Software-Verteilung den Registrierungsschüssel auf Clients verteilen, dass Sie kein IPv6 machen. Vielleicht ist es aber auch einfacher die VPN-Konfiguration um IPv6-Funktionen zu erweitern, so dass der Tunnel wirksam wird. Aus jeden Fall sollten Sie aber prüfen, ob die gewünschte Funktion überhaupt gegeben ist.

PowerShell

Mit dem Commandlet "Set-VPNConnection" und "Get-VPNConnection" können sie seit Windows 2012 und Windows 7 die Eigenschaften einer Windows VPN-Verbindung lesen und ändern.

Hier aus Ausgabe einer meiner Verbindungen:

PS C:\> Get-VpnConnection fcvpn

Name                  : fcvpn
ServerAddress         : vpn.msxfaq.de
AllUserConnection     : False
Guid                  : {41DB17EB-AE0A-4493-9065-AF8CE5B72078}
TunnelType            : Sstp
AuthenticationMethod  : {MsChapv2}
EncryptionLevel       : Required
L2tpIPsecAuth         :
UseWinlogonCredential : True
EapConfigXmlStream    :
ConnectionStatus      : Disconnected
RememberCredential    : False
SplitTunneling        : True
DnsSuffix             : msxfaq.de
IdleDisconnectSeconds : 0

Hier ist SplitTunneling auf "True" gesetzt

Achtung:
Der Wert "SplitTunneling" bezieht sich auf die IPv4-Einstellungen aber nicht auf die IPv6-Einstellungen.
Wenn Sie den Wert mit "Set-VPNConnection" setzen, dann ändert er die Checkbox bei IPv4 und IPv6.

Ein Test mit einem IPv4-Only VPN mit und ohne Tunnel zeigt keine Änderung beim IPv6 Default Gateway.

# Default IPv6 Route zum lokalen Router
PS C:\> (Get-NetRoute "::/0").nexthop
fe80::2e91:abff:fe49:d7c9

# Die VPN-Verbindung konfigurier tmit mit SplitTunnel
PS C:\> (Get-VpnConnection vpn).splittunneling
True

PS C:\> rasdial vpn
Verbindung herstellen mit vpn...
Benutzername und Kennwort werden überprüft...
Der Computer wird im Netzwerk registriert...
Verbindung mit "vpn" wurde hergestellt.
Der Befehl wurde erfolgreich ausgeführt.

# IPv6 Default Route ist unverändert
PS C:\> (Get-NetRoute "::/0").nexthop
fe80::2e91:abff:fe49:d7c9

# Umstellen auf Tunnel
PS C:\> rasdial /dis
Der Befehl wurde erfolgreich ausgeführt.
PS C:\> Set-VpnConnection vpn -SplitTunneling $false
PS C:\> rasdial vpn
Verbindung herstellen mit vpn...
Benutzername und Kennwort werden überprüft...
Der Computer wird im Netzwerk registriert...
Verbindung mit "vpn" wurde hergestellt.
Der Befehl wurde erfolgreich ausgeführt.

# IPv6 Default Route ist unverändert, weil auf meinem VPN gar kein IPv6 aktiv ist
PS C:\> (Get-NetRoute "::/0").nexthop
fe80::2e91:abff:fe49:d7c9

PC C:> ipconfig /ALL
PPP-Adapter vpn:

Verbindungsspezifisches DNS-Suffix: msxfaq.de
IPv4-Adresse . . . . . . . . . . .: 192.168.102.188
Subnetzmaske . . . . . . . . . . .: 255.255.255.255
Standardgateway  . . . . . . . . .: 0.0.0.0

Ein Test mit einer VPN-Verbindung, in der auch gleich IPv6-Adressen mit kommen, steht noch aus.

Zwischenstand

Wenn sie als Administrator oder Sicherheitsverantwortlicher bislang darauf vertraut haben, dass ein Microsoft VPN mit aktiviertem Tunnel den Client wirklich gesichert mit ihrem Firmennetzwerk verbindet, dann sollten Sie schnell prüfen, ob dies tatsächlich so ist. Denn es könnte eine trügerische Sicherheit sein.

Denken Sie aber durchaus an die generellen Nachteile eines Tunnel-VPN hinsichtlich VoIP. UDP Sprache in TCP oder HTTPS mit Retransmits einzupacken ist keine gute Idee. Auch die Nutzung von Cloud-Diensten über VPN-Verbindungen ist weniger effektiv und addiert Latenzzeit und höhere Bandbreiten beim VPN-Server.

Dennoch müssen Sie das richtige Maß der notwendigen Sicherheit für ihr Unternehmen erreichen. Dazu gehört aber auch eine gute Endpoint Security und nicht nur das blinde Vertrauen auf einen Tunnel, der vielleicht gar kein 100%-Tunnel ist.

Weitere Links