Which directaccess ipv6 transition technology uses secure sockets layer over port 443?

From a client perspective, DirectAccess is an IPv6-only solution and requires IPv6 connectivity end to end. To enable the solution to work on IPv4-only networks, DirectAccess makes use of one of several IPv6 transition technologies – 6to4, Teredo, or IP-HTTPS. By leveraging these IPv6 transition technologies, a DirectAccess client can communicate with the DirectAccess server when they are both connected to the public IPv4 Internet, which is the most common deployment scenario today.

The first two IPv6 transition technologies, 6to4 and Teredo, both require that the DirectAccess server be directly connected to the public Internet. Beginning with Windows Server 2012, placing the DirectAccess server behind a border router or edge firewall performing Network Address Translation [NAT] is now supported. However, in this deployment model only the IP-HTTPS IPv6 transition protocol can be utilized. In this scenario, it is recommended to disable the unused IPv6 transition protocols to prevent potential connectivity issues. You can disable them on a per-host basis using PowerShell, which is fine for individual client testing purposes, or globally using Active Directory Group Policy Objects [GPOs], which is recommend for enterprise-wide production deployment.

To disable unused IPv6 transition protocols on a per-host basis on Windows 8 clients using PowerShell, open an elevated PowerShell prompt and execute the following commands:

Set-Net6to4Configuration –State disabled
Set-NetTeredoConfiguration –Type disabled
Set-NetIsatapConfiguration –State disabled

To disable unused IPv6 transition protocols on a per-host basis on Windows 7 client using netsh, open an elevated command prompt and execute the following commands:

netsh interface 6to4 set state disabled
netsh interface teredo set state disabled
netsh interface isatap set state disabled

To disable unused IPv6 transition protocols using Active Directory GPO, open the Group Policy Management Console [GPMC] and create a new GPO. Edit the GPO by navigating to Computer Configuration / Policies / Administrative Templates / Network / TCP/IP Settings / IPv6 Transition. Double-click Set 6to4 State and enable the policy, then select Disabled State from the list of states. Repeat these steps for Teredo and ISATAP.

Change the security filtering for the GPO and specify the security group for your DirectAccess clients. Once complete, link the new GPO to the domain.

As a reminder, the steps above are for disabling unused IPv6 transition protocols in a deployment scenario where the DirectAccess server is running Windows Server 2012/R2 and is deployed behind a NAT device. If your DirectAccess server is connected directly to the public Internet, disabling these IPv6 transition protocols is not required.

All posts tagged IPv6 transition protocol

DirectAccess IP-HTTPS Discovery Script for Nmap

When troubleshooting DirectAccess connectivity issues, the popular Nmap network mapping and discovery tool is an invaluable resource for verifying the communication path to the DirectAccess server from outside the network. However, just verifying that ports are open and listening often isn’t sufficient. In the case of IP-HTTPS, for example, the tried and true method of using telnet to verify that the port is open might be misleading. For instance, telnet might indicate that TCP port 443 is open and responding, but DirectAccess connectivity can still fail. This often happens as a result of a network configuration error that allows another network device other than the DirectAccess server to respond to HTTPS requests, which results in a false positive.

In an effort to conclusively determine that the DirectAccess server is responding, I’ve often relied on the SSL Labs Server Test site. Here I will enter the DirectAccess server’s public hostname and run the test, and from the results I can easily determine if indeed the DirectAccess server is responding by verifying that the HTTP server signature is Microsoft-HTTPAPI/2.0.

This usually works well, but it takes a few minutes to run the test, and there are a few scenarios in which it doesn’t work. For example, I might be working with a customer to perform some initial testing by using a local HOSTS file entry for the public name before the DNS record has been created. Also, if the SSL certificate on the DirectAccess server uses an IP address instead of a hostname [not recommended, but it is supported!] the SSL Labs server test won’t work.

Fortunately, the latest release Nmap [v7.00] now includes a script that enables the detection of Microsoft DirectAccess responding on TCP port 443. With the IP-HTTPS discovery script, it is now possible to determine not only if the port is open, but if the DirectAccess server is actually the service responding. The syntax for conducting a port scan using the IP-HTTPS discovery script for NMAP is as follows:

nmap.exe –n –Pn –p443 [directaccess_public_fqdn] –script [path_to_nmap_iphttps_discovery_script]

Here’s an example:

nmap.exe –n –Pn –p443 da.richardhicks.net –script c:\tools\nmap\scripts\ip-https-discover.nse

Now it is possible, using just Nmap, to not only determine if the IP-HTTPS communication path is functioning, but to definitively determine that the DirectAccess server is the device responding.

Happy troubleshooting!

Tagged DirectAccess, HTTPS, IP-HTTPS, IPv6, IPv6 transition, IPv6 transition protocol, network, Networking, nmap, Remote Access, SSL, TCP, TLS, troubleshooting

Posted by Richard M. Hicks on November 30, 2015

//directaccess.richardhicks.com/2015/11/30/directaccess-ip-https-discovery-script-for-nmap/

DirectAccess Manage Out from Windows 10 Does Not Work

Note: The issue described in this article has been resolved in Windows 10 version 1703 [Creators Update]. Making these changes is no longer required after installing the Creators Update release of Windows 10.

For DirectAccess manage out deployments using ISATAP, you may encounter a scenario in which you are unable to initiate outbound connections to connected DirectAccess clients from a Windows 10 computer. Outbound connections using ISATAP from Windows 7, Windows 8, Windows Server 2008/R2, or Windows Server 2012/R2 systems work without issue.

As it turns out, there is a bug in the Windows 10 DNS client code that prevents manage out using ISATAP from a Windows 10 client from working correctly. Thanks to the diligent effort of DirectAccess administrators Mike Piron and Jason Kuhns, a workaround has been identified. To deploy the workaround, it will be necessary to implement registry changes to alter the default behavior of the DNS resolver in Windows 10. You can implement these changes on a Windows 10 DirectAccess manage out machine by using the following PowerShell commands:

New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\” -Name DisableParallelAandAAAA -PropertyType dword -Value 1 -Force

New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\” -Name DisableServerUnreachability -PropertyType dword -Value 1 –Force

Once these registry changes have been made, you should now be able to use ISATAP for DirectAccess manage out connections from a Windows 10 machine.

Posted in DirectAccess, DNS, IPv6, IPv6 Transition, ISATAP, PowerShell, Remote Access, Windows 10, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2

Tagged bug, DirectAccess, IPv6, IPv6 transition, IPv6 transition protocol, ISATAP, Manage Out, PowerShell, Remote Access, transition protocol, Windows, Windows 10, Windows Server, Windows Server 2012 R2

Posted by Richard M. Hicks on November 10, 2015

//directaccess.richardhicks.com/2015/11/10/directaccess-manage-out-from-windows-10-does-not-work/

DirectAccess and Windows 10 Better Together

With the release of Windows 10, many organizations who chose to skip Windows 8 are now beginning to deploy this new client operating systemn. To maximize investment in Windows 10, DirectAccess can be leveraged to provide employees with seamless and transparent, always on, secure remote corporate network connectivity. DirectAccess has been around for many years, and today the most popular DirectAccess client is Windows 7. However, Windows 10 provides better support for DirectAccess features that enhance performance and availability, while at the same making it easier to implement and support. Windows 10 opens up many new and compelling deployment scenarios for small businesses to large scale enterprises.

Full Support for Geographic Redundancy

Without a doubt the most important DirectAccess feature Windows 10 supports is automatic entry point selection and transparent failover for multisite deployments. DirectAccess multisite deployment provides essential geographic redundancy for organizations with multiple physical locations. Windows 7 has only minimal support for multisite deployment, with clients required to be assigned to a single entry point. Windows 10 clients are aware of all entry points and will intelligently select the closest entry point when establishing a DirectAccess connection. If the entry point becomes unavailable during the connection, Windows 10 clients will transparently connect to another entry point automatically.

Better Scalability and Performance

Windows 10, like Windows 8 before it, includes support for IP-HTTPS null encryption. This feature greatly improves scalability on the DirectAccess server by eliminating the needless double encryption that Windows 7 clients perform. This reduces resource consumption on the server and enables the server to support many more DirectAccess client connections.

Enhanced Supportability

Many will also appreciate Windows 10’s built-in DirectAccess connectivity status indicator. No longer will administrators have to deploy, manage, and maintain additional software to provide this essential functionality.

To access DirectAccess information in Windows 10, press Window Key + I, click Network & Internet, and then click the DirectAccess tab. Here you will find vital details about DirectAccess configuration and status such as connection state, currently connected entry point, and a site selection drop down box [if manual site selection is enabled by an administrator]. In addition you can generate and collect log information for troubleshooting purposes.

Native PowerShell Support

Anyone tasked with troubleshooting DirectAccess configuration and connectivity issues will appreciate the native PowerShell integration with DirectAccess in Windows 10. With just a few commands a wealth of information about DirectAccess configuration and connectivity status can be obtained.

Need to quickly determine if a Windows 10 client has been provisioned for DirectAccess successfully?

Get-DAClientExperienceConfiguration

Has the Windows 10 client connected successfully? If not, why?

Get-DAConnectionStatus

Need to identify the Network Location Server [NLS] the client is configured to use?

Get-NCSIPolicyConfiguration

Looking for DirectAccess multisite entry point details and connection status?

Get-DAEntryPointTableItem

PKI Optional [But Recommended]

Finally, when Windows 10 [and Windows 8.x] clients are supported exclusively a Public Key Infrastructure [PKI] is optional. Here instead the Kerberos Proxy is leveraged to perform DirectAccess client authentication, which reduces infrastructure requirements by eliminating the need for a PKI. However, this configuration offers only limited support for DirectAccess features. For example, a PKI is still required if any Windows 7 clients are deployed. Also, PKI is required to support features such as one-time password [OTP] authentication, Microsoft Network Access Protection [NAP] integration, load balancing [integrated or external], force tunneling, and multisite configuration.

For optimum security and maximum deployment flexibility it is recommended that PKI be used to manage certificates for all DirectAccess deployments including those supporting only Windows 8.x and Windows 10 clients.

Summary

DirectAccess and Windows 10 are much better together. Windows 10 provides full support for the geographic load balancing features of DirectAccess and at the same time offers improved scalability and performance. Windows 10 also makes supporting and troubleshooting DirectAccess clients much easier. And for smaller deployments, Windows 10 can lower the barrier to entry for organizations considering DirectAccess by eliminating the need for a full PKI deployment.

Additional Resources

Video: DirectAccess and Windows 10 in Action
DirectAccess and Windows 10 in Education
Implementing DirectAccess with Windows Server 2016 Book
Implementing DirectAccess with Windows Server 2016 Video Training Course
DirectAccess Consulting Services

More Information

Have a question about DirectAccess? Fill out the form below and I’ll get in touch with you.

Posted in DirectAccess, High Availability, IP-HTTPS, IPv6, IPv6 Transition, Load Balancing, PowerShell, Remote Access, Security, SSL and TLS, VPN, Windows 10, Windows 7, Windows 8, Windows 8.1, Windows Server 2012 R2

Tagged authentication, certificates, connectivity assistant, DCA, DirectAccess, DirectAccess Connectivity Assistant, DTE, encryption, entry point, failover, geographic redundancy, integration, IP-HTTPS, IPv6, IPv6 transition, IPv6 transition protocol, kerberos, Kerberos proxy, multisite, network location server, NLS, NULL encryption, performance, PKI, PowerShell, public key infrastructure, redundancy, Remote Access, scalability, security, troubleshooting, tunnel endpoint, Windows 10, Windows 7

Posted by Richard M. Hicks on August 4, 2015

//directaccess.richardhicks.com/2015/08/04/directaccess-and-windows-10-better-together/

Which communication protocol is used for DirectAccess?

Is DirectAccess secure?

What are the differences between DirectAccess DA and VPN?

What client authentication method can PEAP use?