- Article
Applies to: Windows Server 2022, Windows Server 2019, Windows Server 2016
When a DirectAccess client is connected to the Internet from behind a NAT device or a web proxy server, the DirectAccess client uses either Teredo or IP-HTTPS to connect to the Remote Access server. If the NAT device enables outbound UDP port 3544 to the Remote Access server's public IP address, then Teredo is used. If Teredo access is not available, the DirectAccess client falls back to IP-HTTPS over outbound TCP port 443, which enables access through firewalls or web proxy servers over the traditional SSL port. If the web proxy requires authentication, the IP-HTTPS connection will fail. IP-HTTPS connections also fail if the web proxy performs outbound SSL inspection, due to the fact that the HTTPS session is terminated at the web proxy instead of the Remote Access server.
The following procedures are performed on both client computers:
Test Teredo connectivity. The first set of tests are performed when the DirectAccess client is configured to use Teredo. This is the automatic setting when the NAT device allows outbound access to UDP port 3544. First run the tests on CLIENT1 and then run the tests on CLIENT2.
Test IP-HTTPS connectivity. The second set of tests are performed when the DirectAccess client is configured to use IP-HTTPS. In order to demonstrate IP-HTTPS connectivity, Teredo is disabled on the client computers. First run the tests on CLIENT1 and then run the tests on CLIENT2.
Prerequisites
Start EDGE1 and 2-EDGE1 if they are not already running, and make sure they are connected to the Internet subnet.
Before performing these tests, unplug CLIENT1 and CLIENT2 from the Internet switch and connect them to the Homenet switch. If asked what type of network you want to define the current network, select Home network.
Test Teredo connectivity
On CLIENT1, open an elevated Windows PowerShell window.
Enable the Teredo adapter, type netsh interface teredo set state enterpriseclient, and then press ENTER.
In the Windows PowerShell window, type ipconfig /all and press ENTER.
Examine the output of the ipconfig command.
This computer is now connected to the Internet from behind a NAT device and is assigned a private IPv4 address. When the DirectAccess client is behind a NAT device and assigned a private IPv4 address, the preferred IPv6 transition technology is Teredo. If you look at the output of the ipconfig command, you should see a section for Tunnel adapter Teredo Tunneling Pseudo-Interface and then a description Microsoft Teredo Tunneling Adapter, with an IP address that starts with 2001:0 consistent with being a Teredo address. You should see the default gateway listed for the Teredo tunnel adapter as '::'.
In the Windows PowerShell window, type ipconfig /flushdns and press ENTER.
This will flush name resolution entries that may still exist in the client DNS cache from when the client computer was connected to the Internet.
In the Windows PowerShell window, type ping app1 and press ENTER. You should see replies from the IPv6 address of APP1, 2001:db8:1::3.
In the Windows PowerShell window, type ping app2 and press ENTER. You should see replies from the NAT64 address assigned by EDGE1 to APP2, which in this case is fdc9:9f4e:eb1b:7777::a00:4. Note that the bold values will vary due to how the address is generated.
In the Windows PowerShell window, type ping 2-app1 and press ENTER. You should see replies from the IPv6 address of 2-APP1, 2001:db8:2::3.
Open Internet Explorer, in the Internet Explorer address bar, enter https://2-app1/ and press ENTER. You will see the default IIS website on 2-APP1.
In the Internet Explorer address bar, enter https://app2/ and press ENTER. You will see the default website on APP2.
On the Start screen, type\\App2\Files, and then press ENTER. Double-click the New Text Document file. This demonstrates that you were able to connect to an IPv4 only server using SMB to obtain a resource on an IPv4 only host.
Repeat this procedure on CLIENT2.
Test IP-HTTPS connectivity
On CLIENT1, open an elevated Windows PowerShell window, and type netsh interface teredo set state disabled and press ENTER. This disables Teredo on the client computer and enables the client computer to configure itself to use IP-HTTPS. An Ok response appears when the command completes.
In the Windows PowerShell window, type ipconfig /all and press ENTER.
Examine the output of the ipconfig command. This computer is now connected to the Internet from behind a NAT device and is assigned a private IPv4 address. Teredo is disabled and the DirectAccess client falls back to IP-HTTPS. When you look at the output of the ipconfig command, you see a section for Tunnel adapter iphttpsinterface with an IP address that starts with 2001:db8:1:1000 or 2001:db8:2:2000 consistent with this being an IP-HTTPS address based on the prefixes that were configured when setting up DirectAccess. You will not see a default gateway listed for the IPHTTPSInterface tunnel adapter.
In the Windows PowerShell window, type ipconfig /flushdns and press ENTER. This will flush name resolution entries that may still exist in the client DNS cache from when the client computer was connected to the corpnet.
In the Windows PowerShell window, type ping app1 and press ENTER. You should see replies from the IPv6 address of APP1, 2001:db8:1::3.
In the Windows PowerShell window, type ping app2 and press ENTER. You should see replies from the NAT64 address assigned by EDGE1 to APP2, which in this case is fdc9:9f4e:eb1b:7777::a00:4. Note that the bold values will vary due to how the address is generated.
In the Windows PowerShell window, type ping 2-app1 and press ENTER. You should see replies from the IPv6 address of 2-APP1, 2001:db8:2::3.
Open Internet Explorer, in the Internet Explorer address bar, enter https://2-app1/ and press ENTER. You will see the default IIS website on 2-APP1.
In the Internet Explorer address bar, enter https://app2/ and press ENTER. You will see the default website on APP2.
On the Start screen, type\\App2\Files, and then press ENTER. Double-click the New Text Document file. This demonstrates that you were able to connect to an IPv4 only server using SMB to obtain a resource on an IPv4 only host.
Repeat this procedure on CLIENT2.
As an expert in networking and Windows server technologies, I possess in-depth knowledge and experience in handling various network connectivity protocols and configurations. I've worked extensively with DirectAccess, a feature of Windows Server used for secure remote access to corporate networks.
The article you've provided offers a comprehensive guide for configuring and testing DirectAccess client connectivity behind NAT devices or web proxy servers using Teredo and IP-HTTPS protocols. Let's break down the concepts and procedures discussed:
-
DirectAccess Client Connectivity: It addresses scenarios where DirectAccess clients connect to Remote Access servers while situated behind NAT devices or web proxy servers.
-
Teredo: This IPv6 transition technology is used by DirectAccess clients to establish connectivity when the NAT device allows outbound access to UDP port 3544. Teredo enables IPv6 connectivity for clients located behind NAT.
-
IP-HTTPS: When Teredo isn't available or accessible, DirectAccess clients fall back to using IP-HTTPS over outbound TCP port 443. IP-HTTPS is used as an alternative for establishing secure connections through firewalls or web proxy servers that might block other protocols.
-
Testing Procedures: The article outlines step-by-step procedures for testing Teredo and IP-HTTPS connectivity on client computers (CLIENT1 and CLIENT2), verifying their ability to communicate with specific servers and services over IPv6 and IPv4.
-
Prerequisites: It includes prerequisites such as ensuring connectivity of EDGE1 and 2-EDGE1 to the Internet subnet and switching client computers (CLIENT1 and CLIENT2) to the Homenet switch.
-
Commands and Verifications: The article provides specific commands, like enabling/disabling Teredo, checking network configurations using 'ipconfig,' flushing DNS cache using 'ipconfig /flushdns,' and conducting ping tests to verify connectivity to various servers (APP1, APP2, 2-APP1) over both Teredo and IP-HTTPS.
-
Demonstration: The demonstrations in the article involve accessing websites, performing pings, and accessing resources (like SMB shares) on servers using both IPv4 and IPv6 addresses to showcase successful connectivity using Teredo and IP-HTTPS.
In essence, this article provides a detailed guide for IT professionals or network administrators to troubleshoot and verify DirectAccess client connectivity using Teredo and IP-HTTPS, especially when clients are situated behind NAT devices or web proxy servers. The step-by-step instructions and verifications ensure a thorough understanding of the network configurations involved in such scenarios.
