This is now the 3rd time that I have set up a single network adapter installation of DirectAccess 2012 for one of my customers and I wanted to share my experience with one of the most common problems I’ve seen thus far. This issue has to to with deploying DirectAccess 2012 behind a NAT using the single network adapter method. In searching around the web, it is clear that this is a very common problem for many of us that attempt to deploy DirectAccess 2012 so today I want to address the issue and present the solution.
The scenario is that you have just set up DirectAccess on your Windows Server 2012 server using the single network adapter method and everything is working except for the IP-HTTPS service.
Looking at the operation status page the following error for IP-HTTPS is displayed:
Error:
The IP-HTTPS listener is inactive and cannot accept connections from DirectAccess clients.Cause:
The Listener service has been stopped, or is not configured.Resolution:
Ensure that the IP-HTTPS listener is listening on port 443 of the external network adapter.
Also, executing the following command from powershell will show the IP-HTTPS listener is not working, further verifying the IP-HTTPS interface is bad:
netsh interface httpstunnel show interface
The interface status says “invalid IPHTTPS URL specified”.
Because there are several configuration pieces that need to fit together nicely, this is a common type of problem when setting up a simple DirectAccess 2012 server behind NAT. First, there are a few things you need to check:
1. Enable all three firewall profiles in Windows Firewall with Advanced Security on the DirectAccess server. The Windows Firewall cannot be disabled whatsoever due to the fact that IPSec policies (a prerequisite for DirectAccess) requires an active Windows Firewall to work.
2. Allow inbound ports 80, 443, and 62000 through Windows Firewall with Advanced Security on the DirectAccess server. These ports must be allowed from the internet.
3. When using the single network adapter installation of DirectAccess, this means your DA server is behind NAT. On your external router\firewall, ensure ports 80, 443, and 62000 are forwarded to the DirectAccess server (a.k.a. port forwarding).
This issue all has to do with how you initially configured the Remote Access Server settings in Step 2 of the configuration wizard. In the Remote Access Administration Console, click on Configuration then click the Edit button under Step 2. There needs to be an actual DNS name in this box, not an IP address.
VERY IMPORTANT: Do not use an IPv4 address. Type in an actual DNS name. You will need to create a DNS A record in your organization for the IP address you intend on using for DirectAccess connectivity and type that A record into the Remote Access Server setup configuration. It must a DNS name reachable from the internet. As an alternative, you can set up a Dynamic DNS record through No-IP.com or Dyn.com.
When the change is made, click Next and accept all defaults from here on out. Click Finish and click Finish once more to publish the new settings. Finally, reboot the DirectAccess server.
When the DNS a setting are changed, and after the DA server has rebooted, wait a few minutes then check the operation status in the Remote Access Administration Console. You should see that IP-HTTPS is now working.
You can confirm that the IP-HTTPS interface is active by executing the following command from the command line:
netsh interface httpstunnel show interface
The IPHTTPS interface status will now be active.
If the IPHTTPS interface is still not active, execute gpupdate /force on the DirectAccess server then reboot it again. Eventually, the IPHTTPS interface will activate and your clients will be able to connect.
At this point, you should execute gpupdate /force on your clients, reboot them, and verify DirectAccess connectivity.
- Joe