Tunnelkomponenten

IPV6 und IPV4 können nebeneinander koexistieren aber es gibt immer Teilstücke, die z.B. kein IPV6 unterstützen, so dass "getunnelt" werden muss. Es gibt aber auch Server die kein IPV6 bedienen und nur über IPV4 erreichbar sind. Auch hier müssen Systeme die reinen IPV6-Clients den Zugriff z.B. per NAT64 erlauben. Hier eine Sammlung der verschiedenen Optionen:

  • 6in4 / IPv6over IPv4
    Mit 6to4-Tunnelung nach RFC3056 kann ein Client aus der IPV4-Welt Zugang in die IPV6-Welt erhalten. Voraussetzung ist hier aber eine öffentliche IPV4 Adresse. NAT oder andere Proxies scheiden aus. Für Direkect
  • Teredo
    Dieses Protokoll wurde maßgeblich von Microsoft mit entwickelt und ist zwischenzeitlich im RFC4380 standardisiert. Dabei wird IPV6 in UDP-Pakete (Port 3544) eingetunnelt.
  • https
    Zuletzt gibt es natürlich noch die Möglichkeit, die Pakete in HTTPS-Pakete einzupacken und damit nahezu jede Netzwerkfirewall, Proxy oder Router zu passieren. Dazu wird der TCP-Port 443 genutzt.
  • ISATAP
    Hierbei werden IPV6-Pakete in IPV4 getunnelt, wie dies auch bei einem VPN schon länger bekannt ist. Das ISATAP-Netz ist quasi ein Overlay-Netz mit Link Lokalen Adressen (FE80)
  • NAT64
    Diese Funktion setzt Pakete von Clients, die "nur IPV6" sprechen auf Server um, die "nur IPV4" können. für den Einsatz mit Direct Access ist dies wichtig, wenn Sie intern noch nicht alle Systeme oder Dienste über IPV6 erreichen können. Diese Funktion ist aber nicht Bestandteil von Direct Access sondern sie benötigen den Microsoft UAG oder eine andere NET64 Lösung.

Funktionsübersicht

Sie haben schon gelesen, dass bei Direct Access nichts ohne IPV6 geht. Das basiert darauf, dass Microsoft mit Direct Access zuerst einmal davon ausgeht, dass die beiden Kommunikationspartner per IPV6 miteinander kommunizieren können und Gruppenrichtlinien entsprechend die Verbindungen konfiguriert werden (IPSec). Nun ist es aber leider nicht so, dass heute schon alle Clients per IPV6 miteinander kommunizieren können. Direct Access stellt durch die passenden Komponenten auf dem Windows 7 Enterprise/Ultimate-Client und den Direct Access-Server die Hilfsmittel bereit, auch IPV4-Strecken über das Internet für IPV6 durchgängig zu machen und hierbei auch NAT-Router und andere Hindernisse zu überwinden. IPV6 wird also auf dem Client in ein IPV4-Paket getunnelt zum Direct Access Server übertragen, welcher dann das Packet wieder intern auf die Leitung setzt. Da spielen natürlich viele Komponenten zusammen, damit Direct Access funktioniert. Auch wenn die Direct Access-Rolle an sich sehr schnell installiert ist und der Assistent Sie durch die Konfiguration führt, so ist dies "nur" Direct Access aber nicht die Umgebungen. Hier mal ein schematisches Bild der Komponenten.

Dieses Bild nutze ich gerne bei Vorträgen und Planungsworkshops mit Kunden. Dort "entsteht" das Bild aber auf einer weißen Tafel. Links sieht man die vier verschiedenen Möglichkeiten einer Clientverbindung

Der Client kann zuhause, an einem öffentlichen Accesspoint o.ä. angeschlossen sein und schafft es für Verbindungen zu den internen Servern die Daten zu übertragen. Über Zertifikate auf dem Server und die Clients wird der Datenverkehr abgesichert. Als Tunneloptionen bietet DirektAccess dabei 6to4, Teredo, ISATAP oder HTTPS-Tunnel an.

Aber auch hier ist zu sehen, dass der Zugriff auf eine IPV4-Ressource im LAN nur über ein NAT64-Gateway wie den UAG oder andere Systeme erfolgen kann. Das Problem wird natürlich kleiner je mehr Dienste intern per IPV6 zu erreichen sind. Mindestens ein Domain Controller muss ja schon per IPV6 erreichbar sein, damit die Funktion gegeben ist. Wer intern dann jedoch mehrere Subnetze betreibt, wird irgendwann auch hier intern IPV6-taugliche Router einsetzen müssen, damit auch diese Erreichbarkeit durchgängig möglich ist.

Welchen Weg der Client aus dem Internet zum Direct Access-Server nutzt, bestimmt er anhand der lokalen IP-Adresse, die er in seinem Subnetz bekommen hat:

IP-Adresse des Clients Bevorzugter Verbindungsweg FirewallPorts Verbindung

Globale eindeutige IPV6-Adresse

IPV6 zum Direct Access-Server

ICMPv6
IP Protokoll 58
IPsec Encapsulating Security Payload (ESP) traffic (IPv6 protocol 50)

Direkt IPV6

öffentliche IPV4 Adresse

6to4: IPV6-Pakete über IPV4-Pakete geroutet übermitteln

Getunnelter IPv6 Traffic über
IPv4 Protocol 41

Direkt IPV4

Private IP-Adresse

Teredo: Tunnelt IPV6-Pakete in IPV4-Pakete, die auch durch NAT-Systeme durchgehen können

UDP Port 3544

NAT über IPV4

Keine Verbindung per 6to4 oder Teredo

Fallback auf IP over HTTPS

TCP Port 443

HTTPS auch über Proxies

Damit ist natürlich klar, dass das ganze nur sinnvoll funktioniert, wenn das Client-Subnetz sich auch danach richtet. Eine Firma, die intern einen "offiziellen" Bereich verwendet, der ihr aber nicht zugewiesen ist, sondern als "Altlast" einfach da ist, wird den Client genauso stören wir eine offizielle "falsche" IP-V6-Adresse.

Weiterhin spielen ihnen Internet Provider, Router und GSM-Provider Streiche, indem Sie bestimmte Ports aus "Kostengründen" oder "Sicherheitsbedenken" sperren

Der APN für Vodafone ist: "volume2.d2gprs.de" statt "web.vodafone.de"
Hinweis. Ein 1und1 Vertrag der die Vodafone Struktur nutzt, kann diesen APN scheinbar nicht nutzen.

Der APN für T-Mobile ist: "internet.t-mobile.de"
Hinweis. Ein 1und1 Vertrag der die Vodafone Struktur nutzt, kann diesen APN scheinbar nicht nutzen.

Tunnel-Techniken aktivieren/deaktivieren

Normalerweise ist es nicht erforderlich, einzelne Tunnel-Protokolle zu deaktivieren. Windows macht schon einen ziemlich guten Job bei der Ermittlung der passenden Konfiguration. Aber ich kenne schon drei Gründe, einzelne Funktionen abzuschalten:

  • Sicherheit wegen ISATAP
    Per Default ist ISATAP aktiv und sollte wirklich jemand in ihrem Netzwerk einen ISATAP-Server starten und im DNS eingetragen bekommen und ihre Firewall/Router würden ISATAP nicht stoppen, dann hätten Sie wirklich ein Firmenweites nicht segmentiertes WAN, was niemand will. Aber sie haben schon viele "Wenn" gelesen. Sie müssen schon verdammt viel falsch in ihrem LAN machen, damit die Clients diese Brücke bauen können.
  • Reduzierung der Netzwerkkarten
    Es soll Anwender geben die bei einem IPCONFIG durch die Menge der Tunneladapter durcheinander kommen. Natürlich gibt es heute auch auch noch VPN, Bluetooth und andere Schnittstellen, die ein Netzwerk darstellen können aber man kann durch das Deaktivieren von Protokollen natürlich auch die dazugehörigen Karten verschwinden lassen.
  • Beschleunigung DirectAccess (Win7)
    Windows 7 hat zum Direct Access-Server nicht nur IPHTTP genutzt, sondern auch 6to4 und Teredo versucht. Der Windows 2012 DA-Server ist auf diesem Oh quasi taub. Wer also viele Windows 7 Clients mit Direct Access hat, kann die Herstellung der Verbindung etwas beschleunigen, wenn diese Protokolle abgeschaltet werden.

Ob dies aber den Aufwand rechtfertigt müssen Sie selbst ermitteln. Ich schalte die Tunnel normal nicht ab, sondern belasse Windows Clients möglichst bei den Standardeinstellungen.

Sie sollten also immer die verwendeten Protokolle können und mit NETMON auch hinter die Kulissen schauen können.

6to4

Mit einer offiziellen IPv4 Adresse versucht der Client sich also per 6to4-Tunnel mit dem Server zu verbinden. Der Assistent zu Direct Access macht die erforderlichen Einstellungen per Gruppenrichtlinie, wie Sie an dem Bild erkennen können:

In der Mitte ist die IPv4-Adresse des Server angegeben. Eine Kontrolle mit RegEdit auf dem Client zeigt ihnen den entsprechenden Schlüssel: 

Die Einträge für Teredo sind auch an der gleichen Stelle zu finden. Auch NETSH zeigt ihnen die Daten mit "netsh interface 6to4 show relay":

Eigentlich sollte 6to4 über offizielle Adressen in allen Netzwerken funktionieren. Dummerweise gibt es Provider, die trotz offizieller Adresse dies diese ICMP-Pakete verändern und der Direct Access Client die Verbindung nicht herstellen kann. Es kann daher sogar besser sein, auf 6to4 zu verzichten und gleich zu Teredo zu gehen.

Ob die Verbindung per 6to4 möglich ist, können Sie einfach mit dem NETMON überprüfen, bei dem Sie folgenden Filter verwenden:

IPv4.NextProtocol == 0x29

An einem einfachen unverschlüsselten PING eines Clients ist gut zu sehen, wie IPv6 in IPv4 eingepackt wird

Andere "Nutzdaten" werden anhand der Richtlinien natürlich verschlüsselt.

I would definitely set Teredo to Enterpriseclient status. I recommend that you do this permanently für all of your Direct Access computers via a GPO (and disable 6to4 on all of your Direct Access clients computers using the same GPO). 6to4 is only ever used if your client computer gets a real public IP address (like from a cell phone card), 6to4 will never connect when the User is sitting behind a NAT like a home router. And in the rare cases that 6to4 does actually connect, half the time the ISP blocks IP Protocol 41 which kills your DA connection. Better to disable the 6to4 adapter and let Teredo do the job in its place.
Quelle: Jordan Krause MVP http://social.technet.microsoft.com/Forums/en/forefrontedgeiag/thread/8475dc32-eb4e-4255-9153-76db62b0b582

Das können Sie auf dem Client zum Test einfach mit NetSH ein und ausschalten.

netsh interface 6to4 set state disabled

Für den Firmeneinsatz sollte das natürlich dann in der Direct Access Gruppenrichtlinie unter "Computer Configuration\Policies\Administrative Templates\Network\TCPIP Settings\IPv6 Transition Technologies " erfolgen.

Sollten Sie die entsprechende Einstellung nicht in der GuI sehen, dann haben Sie noch nicht die Windows 2008 R2 - ADMX-Vorlagen eingespielt.

Teredo

Aber auch für das "Tunneln" durch Teredo tragen die Gruppenrichtlinien entsprechende Einträge lokal ein, die auf den Direct Access Server verweisen. Über "netsh interface teredo show state" können Sie den Status des Teredo-Interface einsehen

Die IP-Adresse des Servers, der per Gruppenrichtlinie übertragen wurde, habe ich hier unkenntlich gemacht. Sie können Teredo natürlich auch manuell per NETSH konfigurieren

netsh interface teredo set state enterpriseclient
sc control iphlpsvc paramchange

Über NETSH können Sie auf dem Direct Access Server auch die Serverseite anschauen

C:\>netsh int ipv6 show teredo server
Teredo Parameters
---------------------------------------------
Type                    : server
Virtual Server Ip       : 80.22.60.221
Client Refresh Interval : 30 seconds
State                   : online
 
Server Packets Received : 33612
Success                 : 33583 (Bubble 31210, Echo 2273, RS1 86 RS2 14)
Failure                 : 29 (Hdr 0, Src 29, Dest 0, Auth 0)
 
Relay Packets Received  : 21724
Success                 : 245421 (Bubble 544, Data 244877)
Failure                 : 446 (Hdr 0, Src 0, Dest 446)
 
Relay Packets Sent      : 53555
Success                 : 556279 (Bubble 1210, Data 555069)
Failure                 : 8 (Hdr 0, Src 8, Dest 0)
 
Packets Received in the last 30 seconds:
Bubble 0, Echo 0, RS1 0, RS2 0
6to4 source address 0, native IPv6 source address 0
6to4 destination address 0, native IPv6 destination address 0

Ich ziehe aber die Konfiguration per Gruppenrichtlinien über den Assistenten vor. Damit Teredo funktioniert muss mindestens eine Firewallregel auf dem Client eingerichtet werden.

To allow Teredo-based connectivity, you must configure and deploy the following additional Windows Firewall with Advanced Security rules für all of the domain member computers in your organization:

Inbound ICMPv6 Echo Request messages (required)
Outbound ICMPv6 Echo Request messages (recommended)

Nicht alle Router unterstützen übrigens Teredo. Dazu zählt insbesondere die Fritz-Box 7170 und 7270 (Version 1). Ab Version 2 kann IPV6 intern genutzt werden.

ISATAP (Intrasite Automatic Tunnel Addressing Protocol)

Dieses Verfahren ist für Direct Access ebenfalls wichtig, zumindest wenn sie in ihrem Intranet noch kein IPV6 durchgängig konfiguriert haben. Ohne Hilfe von NAT64, z.B. in Form eines UAG, kann ein Client nach dem Tunnel durch Direct Access nur IPV6-Systeme ansprechen. ISATAP ist ein Weg, quasi ein durchgängiges IPV6-Netzwerk über IPV4-Verbindungen aufzubauen. Findet Direct Access bei der Installation keine interne IPV6-Infrastruktur, dann konfiguriert DA sich automatisch als ISATAP-Router um zwischen dem IPV6-Netzwerk von Client und DA-Server und dem IPV6-Server intern und DA-Server zu routen. IPV6 fährt dann also Huckepack auf IPV4-Paketen.

Achtung:
Ein Windows DNS Server hat eine Globale DNS Query Block List, die eine Abfrage auf ISATAP per Default verhindert.
DNS Server Global Query Block List
http://download.microsoft.com/download/5/3/c/53cdc0bf-6609-4841-a7b9-cae98cc2e4a3/dns_server_global_%20query_block%20list.doc

Siehe dazu die eigene Seite ISATAP

IPHTTPS

Zuletzt gibt es den Tunnel durch HTTPS. Der Client packt alle Pakete in HTTPS-Request ein, die er über die gewohnten Wege versendet. Hier kann aber immer noch ein HTTPS-Proxy die Verbindung blockieren. Allerdings gibt es da keine kleine Falle. Während die Gateway-IP für 6to4 und Teredo als "Nummer" gespeichert wird, wird der Zugang für HTTPS als Name gespeichert. Die Einstellungen finden sich auf dem Client auf einem Unterschlüssel:

Und das ist genau die zweite IP-Adresse, die für Direct Access erforderlich ist. Wenn Sie nämlich bei der Konfiguration "genau" hinschauen, dann zeigt der Assistent nicht die erste sondern die zweite IP-Adresse an.

Und diese Adresse ist mit dem Namen im DNS zu veröffentlichen.

Hinweis
Wenn Sie Split-DNS" nutzen, dann müssen sie auch diesen Host später in der NRPT ausnehmen.

Wenn Sie dies nicht tun, dann wird der HTTPSTunnel nicht funktionieren, weil Windows den Namen über die IPv6-DNS-Server erreichen will, der Tunnel aber noch nicht stehen kann. (Henne-Ei-Problem). Wenn das aber funktioniert, dann sieht es wie folgt aus:

Aber auch die Serverseite von IPHTTPS kann per NETSH überprüft werden

C:\>netsh interface httpstunnel show interface 

Interface IPHTTPSInterface Parameters
------------------------------------------------------------
Role                       : server URL                        : https://da.netatwork.de:443/IPHTTPS
Client authentication mode : certificates
Last Error Code            : 0x0
Interface Status           : IPHTTPS interface active


C:\>netsh interface httpstunnel show st
 
Interface IPHTTPSInterface Parameters
------------------------------------------------------------
Total bytes received       : 21331
Total bytes sent           : 42139
 
Most Recent Client Address                 Total Bytes In    Total Bytes Out
------------------------------------------ ----------------- -----------------

Bei einer fehlerfreien Verbindung können Sie mit IPCONFIG den Tunneladapter samt der aus dem Direct Access-Pool zugewiesenen IPv6-Adresse sehen.

Beachten Sie, dass der HTTPTunnel nur funktioniert, wenn der Client zum DA-Server per HTTPS reden kann. Dabei kann auch ein Proxy dazwischen sein, solange dieser keine Authentifizierung verlangt.

IPHTTPS und Proxy
IP-HTTPS does not support proxy servers that require authentication with each connection, which might cause problems with IP-HTTPS connections. To determine if you are behind this type of proxy, open your Internet browser and browse a public website. You might be prompted für authentication. Open a second Internet browser window or tab and browse a different public website. If you can get to the second website without having to specify authentication credentials, IP-HTTPS should work across the proxy. If you need to enter credentials each time you access a different website, IP-HTTPS might be blocked.
Quelle: http://technet.microsoft.com/en-us/library/ee844126(WS.10).aspx

Es ist aber kein Problem, wenn z.B. an einem Hotspot sind und sich dort per Browser anmelden, aber dann keine weitere HTTP-Anmeldung erforderlich ist, was fast überall der "Standard" ist. Faktisch dürfte der HTTPS-Tunnel daher fast nur dann nicht funktionieren, wenn Sie ihren Notebook bei einer fremden Firma angestöpselt haben, deren HTTP-Proxy eine integrierte Anmeldung erfordert.

Sollten alle anderen Optionen (6to4, Teredo) nicht gehen und auch der HTTPS-Tunnel nicht aufgebaut werden, dann sehen Sie beim Schnittstellenstatus mit "netsh interface httptunnel show interface" einen Fehlercode:

Häufiger Fehler ist z.B. das Zertifikat auf dem Client. Wer auf der internen Enterprise-CA ein eigenes Template für die Ausstellung von Computer-Zertifikaten einsetzt, sollte darauf achten, dass der DNS-Name zumindest im SAN-Feld enthalten ist und der Antragsteller (Subject) nicht leert ist. Hier die wichtige Seite.

Aber auch auf dem Server spielen Zertifikate eine wichtige Rolle. Der IPHTTP-Listener kann anscheinend nicht explizit an eine IP-Adresse gebunden werden, sondern nutzt als Teil des Betriebssystems einfach alle IP-Adressen auf Port 443: Entsprechend sieht man mit NETSH einen globalen Listener.

C:\>netsh http show sslcert

SSL Certificate bindings:
-------------------------
 
    IP:port                 : 0.0.0.0:443
    Certificate Hash        : ae5f91d465eeac2a0c3ada91606f7fbd7da4f2c7
    Application ID          : {5d8e2743-ef20-4d38-8751-7e400f200e65}
    Certificate Store Name  : MY
    Verify Client Certificate Revocation    : Enabled
    Verify Revocation using Cached Client Certificate Only    : Disabled usage Check    : Enabled
    Revocation Freshness Time : 0 URL Retrieval Timeout   : 0
    Ctl Identifier          :
    Ctl Store Name          :
    DS Mapper usage    : Enabled
    Negotiate Client Certificate    : Disabled

Dabei bedeutet dies nicht, dass ein IIS oder eine andere Applikation nicht einen "enger" gefassten Listener konfigurieren kann. Es ist mir aber besonders mit UAG aber mehrfach passiert, dass die Assistenten nicht das richtige Zertifikat an diesen Listener gebunden haben. Leider kann man das nicht "ändern", sondern muss den Listener löschen und neu anlegen. Zudem ist die Einstellung "Negotiate Client Certificate" bei DA per Default auf "disabled" und bei UAG ein "enabled". Insofern ist Direct Access hier etwas toleranter als UAG, so dass Fehler auf dem Clientzertifikat vielleicht nicht sofort auffallen.

Dafür kann UAG an anderer Stelle sich einmischen, wie folgender Forenbeitrag ausführt:

BTW: UAG has a setup bug in the way its bind the default website (internal site) to 0.0.0.0:443. When using DA this site gets accessible from the outside (without UAG URL Filters active) because the DA Wizards will create a TCP443 Paketfilter to allow this traffic. So the 404 message you get is most likely a responce from your Default Website (aka. internal site). To see if this is the case für you try using the following URL:  https://da1.koncar-inem.hr/internalsite/languages/en-us.xml If you can access this file (your Portal Trunk would deny it für a good reason), then you still have the default binding in place...
Quelle: http://social.technet.microsoft.com/Forums/en/forefrontedgeiag/thread/2ed199cf-c1ad-47fe-aff1-12fb22449ed6

Wenn Sie daher die Bindungen der Zertifikate überarbeiten wollen, dann sind folgende Zeilen eine gute Vorlage. den Hash des Zertifikats müssen Sie manuell ermitteln und die GUID bei der AppID ist eine zufällige GUID, die sie in PowerShell mit dem Befehl "[guid]::NewGuid()" ganz schnell erzeugen können. Zur Lesbarkeit wurden die Zeilen umgebrochen.

netsh http add sslcert 
   ipport=0.0.0.0:443 
   certhash=28aa1c1bc1bc69b071ecd0d5a0a3fd17f0a4788c 
   appid={9c5923e9-de52-33ea-88de-7ebc8633b9cc} 
   certstorename=MY dsmapperusage=en clientcertnegotiation=dis

netsh http add sslcert 
   ipport=0.0.0.0:443 
    certhash=28aa1c1bc1bc69b071ecd0d5a0a3fd17f0a4788c 
    appid={9c5923e9-de52-33ea-88de-7ebc8633b9cc} 
    certstorename=MY dsmapperusage=en clientcertnegotiation=en

Leider kann man eine Bindung nicht "ändern", sondern muss diese immer "überschreiben" und dabei alle gewünschten Parameter mitgeben

NAT64 und DNS64

Die Direct Access Clients nutzen IPv6 und wenn Sie intern IPv4-Systeme erreichen wollen, dann kommt die DNS-Umsetzung zum Tragen. Der DA-Client frage nicht den normalen DNS-Server ihres Netzwerks sondern den DNS-Proxy des Direct Access Servers. Dieser DNS64-Dienst fragt dann den eigentlichen DNS-Server nach den Namen und abhängig von der Antwort gibt es drei Optionen:

  • Name nicht auflösbar
    Der Client bekommt dann auch ein "Not Resolvable" und kann sich nicht verbinden
  • DNS Abfrage liefert nur eine IPv4-Addresse
    Dann weiß der DA-Server, dass der angefragte Server nicht per IPv6 erreichbar ist. Der DNS-Proxy antwortet dem Client dann mit einer IPv6-Adresse, die auf den NAT64-Dienst des DA-Server verweist. Der Client verbindet sich mit der IPv6-Adresse zum DA-NAT64-Dienst und dieser NAT64 Service setzt die Adresse auf die IPv4 Adresse um
  • DNS-Server liefert gültige IPv6-Adresse
    In dem Fall geht DA davon aus, dass das Zielsystem per IPv6 erreichbar ist und gibt die Antwort unverändert an den Client weiter

Diese Funktion ist übrigens auch der Grund, warum ein direkter Zugriff auf die IPv4-Addresse eines Zielsystems zum scheitern verurteilt ist.

Bei der Umsetzung mit NAT64 müssen sie aber wissen, dass bei den internen Server natürlich als Source-IP der DA-Server erscheint. Wer also z.B. auf dem Exchange Server aus den IISLogs den Client ermitteln will, kommt hier nicht weiter. Auf dem DA-Server ist die Port-Range hinterlegt, mit der DA-Clients nach intern weiter verbunden werden.

PS C:\> Get-NetNatTransitionConfiguration

InstanceName        : DirectAccess
PolicyStore         : PersistentStore
State               : Enabled
TcpMappingTimeout   : 7200
InboundInterface    :
OutboundInterface   : {Intern VLAN0 192.168.1.30}
PrefixMapping       : {fdac:5932:7945:7777::/96,0.0.0.0/0}
IPv4AddressPortPool : {192.168.1.30,6001-47000}

InstanceName        : DirectAccess
PolicyStore         : ActiveStore
State               : Enabled
TcpMappingTimeout   : 7200
InboundInterface    :
OutboundInterface   : {Intern VLAN0 192.168.1.30}
PrefixMapping       : {fdac:5932:7945:7777::/96,0.0.0.0/0}
IPv4AddressPortPool : {192.168.1.30,6001-47000}

Hier ist gut zu sehen, dass der NAT64-Dienst per Default die Port 6001-47000 verwendet.

Achtung: Damit ist auch definiert, dass ein DA-Server maximal 40999 gleichzeitige Verbindungen nach intern umsetzen kann. Wenn jeder Client mit Outlook, SMB, HTTP-Proxy u.a. vielleicht 100 Connections belegt, können Sie ca. 400 Clients gleichzeitig unterstützen. Das kann eng werden. Überwachen Sie den Performance Counter "WINNAT\Current Session Counter (avg)"

Beachten Sie diesen Bereich, wenn auf dem Server noch andere Dienste Ports allokieren wollen, z.B. Management-Produkte, BackupAgenten, Antivirus-Lösungen etc. Sie können Port aus dem Bereich meist ohne Fehler öffnen aber sie werden nicht funktionieren, da der darunter liegende TCP-Stack mit der NAT64-Konfiguratoin die Pakete abfängt.

 

Welcher Tunnelweg ist gerade aktiv?

Nun wissen Sie, dass sie insgesamt vier mögliche Tunnelszenarien vorfinden können, von denen der Client hoffentlich über einen Zugang arbeiten kann. Einen schnellen Überblick über die aktuelle Verbindung erhalten Sie zwar auch mit IPCONFIG, aber die Liste ist meistens sehr lang und nicht übersichtlich. Besser ist der Aufruf von "netsh interface ipv6 show interface" oder

In diesem Beispiel können Sie sehen, das abgesehen vom Loopback Interface ich per WiFi mit einem LAN verbunden bin und weiterhin das iphttpsinterface aktiv ist. Teredo ist nicht aktiv und 6to4 gar nicht aufgeführt.