Hi,

I'm trying to setup Direct Access on a Windows 2012 R2 server and I'm running into what is hopefully a pretty easy problem to resolve.

I've followed the instructions to setup a simple setup for DA on a Windows 2012 R2 server with everything all on one server and I'm running behind a TMG 2010 server.  On the TMG server I've published the my DA server using a server publishing rule based on these instructions http://danstoncloud.com/blogs/simplebydesign/archive/2013/04/04/tmg-can-be-a-good-friend-of-directaccess.aspx

The setup seems pretty straight forward, but now when I'm testing my clients I'm getting the NameResolutionFailure error when I try and connect when I'm not on our internal network.

The problem I'm pretty sure is DNS related because when my test Windows 8.1 client is on our internal network everything works fine. 

When I plug the machine into an external network, I get the NameResolutionFailure error for the DA client. If I try and ping anything address on our domain name I get an error that the address is unresolvable.  I can ping any other domain name address fine.

On my DA server, on the DNS tab of the Infrastructure Server setup I have the following entries:

mydomain.com              fdf3:137e:5133:ce07:1000::127

directaccess.mydomain.com

DirectAccess-NLS.mydomain.com

directaccess.mydomain.com is the publicly resolvable name of my DA 2012 R2 server that is bound the external IP address published on my TMG 2010 server.  This name is not resolvable when on any internal machines.

If I execute the get-DNSClientNRPTPolicy command I get this:

Namespace                        : DirectAccess-NLS.mydomain.com
QueryPolicy                      :
SecureNameQueryFallback          :
DirectAccessIPsecCARestriction   :
DirectAccessProxyName            :
DirectAccessDnsServers           :
DirectAccessEnabled              :
DirectAccessProxyType            : UseDefault
DirectAccessQueryIPsecEncryption :
DirectAccessQueryIPsecRequired   : False
NameServers                      :
DnsSecIPsecCARestriction         :
DnsSecQueryIPsecEncryption       :
DnsSecQueryIPsecRequired         : False
DnsSecValidationRequired         : False
NameEncoding                     : Utf8WithoutMapping

Namespace                        : directaccess.mydomain.com
QueryPolicy                      :
SecureNameQueryFallback          :
DirectAccessIPsecCARestriction   :
DirectAccessProxyName            :
DirectAccessDnsServers           :
DirectAccessEnabled              :
DirectAccessProxyType            : UseDefault
DirectAccessQueryIPsecEncryption :
DirectAccessQueryIPsecRequired   : False
NameServers                      :
DnsSecIPsecCARestriction         :
DnsSecQueryIPsecEncryption       :
DnsSecQueryIPsecRequired         : False
DnsSecValidationRequired         : False
NameEncoding                     : Utf8WithoutMapping

Namespace                        : .mydomain.com
QueryPolicy                      :
SecureNameQueryFallback          :
DirectAccessIPsecCARestriction   :
DirectAccessProxyName            :
DirectAccessDnsServers           : fdf3:137e:5133:ce07:1000::127
DirectAccessEnabled              :
DirectAccessProxyType            : NoProxy
DirectAccessQueryIPsecEncryption :
DirectAccessQueryIPsecRequired   : False
NameServers                      :
DnsSecIPsecCARestriction         :
DnsSecQueryIPsecEncryption       :
DnsSecQueryIPsecRequired         : False
DnsSecValidationRequired         : False
NameEncoding                     : Utf8WithoutMapping

So I'm thinking that the issue is related to the fact that the NRPT table says that directaccess.mydomain.com address there is no DNS specified.  In fact it seems like that entry shouldn't even be there.  When I was configuring DA for the first time, I got a warning that said:

Warning: The NRPT entry for the DNS suffix .serverdomain.local contains the public name used by client computers to connect to the Remote Access server. Add the name Servername.serverdomain.local as an exemption in the NRPT.

I wasn't sure what this meant at the time but I'm guessing it's relevant to this problem.

Can some one give some help with this?

Thanks in advance

Nick

 

 

• Edited by Nick Palmer Tuesday, January 14, 2014 10:15 PM

Your output of the NRPT actually looks correct. What that warning means is that "hey, you told me to send *.mydomain.com inside the DirectAccess tunnels, but that namespace includes the public DNS name of myself, so make sure to exclude that particular name from the NRPT". Typically I see people get tripped up here because they don't understand that message and don't add in the record. UAG used to add it automatically, I don't know why in the world they decided not to have it added automatically in 2012. But anyway, from your NRPT it looks like your public DNS record is correctly "excluded" from the NRPT, which means that requests to directaccess.mydomain.com flow outside of the DA tunnels, which is exactly what you need it to do.

So however directaccess.mydomain.com got added in there, yes it is supposed to be there and without a DNS server defined, meaning that it is going to force that name to fall onto whatever DNS servers are configured for the local NIC on the client computer, therefore keeping that traffic outside of the DA tunnels.

So the issue you are having, I don't think it is related to this. Unless this NRPT setting hasn't filtered down to the clients fully yet. Perhaps initially the NRPT didn't include directaccess.mydomain.com and then it was added later? This could leave client computers in a state where DA wouldn't work until they get the new NRPT from the GPOs.

Hi Happy to see that my blog posts are used. At first : -Check if your TMG rule work (a simple Telnet on client side to the HTTPS interface) -Check if your client establish a tunnel -Check if you can ping the IPv6 address you can see in the NETSH.EXE NAMESPACE SHOW EF command. If you hava a positive answer to ping. Let's switch to DNS with : DNSLOOKUp Server <NRPT IPV6 address> If you have a DNS answer it's only a NRPT content problem as Jordan told you.

Hi Jordan, thanks for the reply

I think you may have been correct about the NRPT not filtering down to my client.  Now when I ping directaccess.mydomain.com I get the correct IP address of my TMG server's external address.  But if I do a get-DAConnectionStatus I'm still getting the NameResolutionFailure error.  I can't ping any other .mydomain.com addresses when I'm external but that sounds correct.

The name Directacess-NLS.mydomain.com is the name I've assigned the NLS service on my DA server so should it be in the NRTP without an IP address for the DNS server?

Nick

Hi Benoit,

I'm not sure how to test with telnet? I can telnet to directaccess.mydomain.com with 443 for the port and my screen goes blank but I'm not sure else to do after that.

And yes from my client system I can ping the DNS server listed when I do a NETSH.EXE NAMESPACE SHOW EF.  That is the internal address of my DA server so I must at least be getting to the server right?

When I try and do an NSLOOKUP with that server though I can't connect to it

Thanks

Nick

Correct about the NLS address in the NRPT - you want that name to be listed without anything in the DNS field (just like for your public name). Whenever you have a name in the NRPT that has nothing listed for DNS, it tells the DA client machines that for requests to that name to ignore those and send the requests off to whatever DNS the operating system is using (so your ISP's DNS or whatever is currently assigned to your NIC). This is how we ensure that traffic to the NLS server and the public name do not try to flow inside the DirectAccess tunnels, but rather go outside of them.

Benoit, I think that Nick already has Telnet Client installed, and it sounds from his response that he is successfully opening a socket connection to the public name on port 443. Nick, this is good news in that your HTTPS traffic does seem to be flowing and ending up somewhere at least. (the blank screen with a flashing cursor after doing the telnet command indicates a successful connection)

If you do an ipconfig /all, does your IP-HTTPS adapter have an IPv6 address now? You can also do netsh int httpstunnel show int to get more information about the IP-HTTPS adapter and it's status.

Hi,

By default, the TELNET client is not installed os Windows 7.8 and must be installed as an optionnal feature from the control panel or the Enable-WindowsOptionalfeature. If test is successfull, this means that IPSEC tunnel should establish. If this test fail, it's normal for DNS resolution to fail too.

Hi Jordan,

Thanks for the information.  That makes sense now.

Here is some information from the client system:

ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : win81Test
   Primary Dns Suffix  . . . . . . . : mydomain.com
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : mydomain.com

Wireless LAN adapter Wi-Fi:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Dell Wireless 1370 WLAN Mini-PCI Card
   Physical Address. . . . . . . . . : 00-14-A5-5C-50-B3
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Broadcom 440x 10/100 Integrated Controller
   Physical Address. . . . . . . . . : 00-14-22-EF-B7-04
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::55de:8e47:652:71b4%3(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.0.117(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Thursday, January 16, 2014 3:49:02 PM
   Lease Expires . . . . . . . . . . : Thursday, January 23, 2014 3:49:01 PM
   Default Gateway . . . . . . . . . : fdfd:1374:5130:ce07:1000::21
                                       192.168.0.1
   DHCP Server . . . . . . . . . . . : 192.168.0.1
   DHCPv6 IAID . . . . . . . . . . . : 50336802
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-19-F2-3A-1F-00-14-22-EF-B7-04
   DNS Servers . . . . . . . . . . . : 192.168.0.1
   NetBIOS over Tcpip. . . . . . . . : Enabled

Tunnel adapter Teredo Tunneling Pseudo-Interface:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
   Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv6 Address. . . . . . . . . . . : 2001:0:9d38:6ab8:303d:5e3:9f08:bb61(Preferred)
   Link-local IPv6 Address . . . . . : fe80::303d:5e3:9f08:bb61%6(Preferred)
   Default Gateway . . . . . . . . . :
   DHCPv6 IAID . . . . . . . . . . . : 234881024
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-19-F2-3A-1F-00-14-22-EF-B7-04
   NetBIOS over Tcpip. . . . . . . . : Disabled

Tunnel adapter isatap.{C74F2337-9F0D-4227-93EF-5ABA22950621}:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft ISATAP Adapter #2
   Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes

Tunnel adapter iphttpsinterface:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : iphttpsinterface
   Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv6 Address. . . . . . . . . . . : fdfd:1374:5130:1000:1931:6832:61c4:d6ca(Preferred)
   Temporary IPv6 Address. . . . . . : fdfd:1374:5130:1000:8047:d4f4:2aa5:fe6(Preferred)
   Link-local IPv6 Address . . . . . : fe80::1931:6832:61c4:d6ca%8(Preferred)
   Default Gateway . . . . . . . . . :
   DHCPv6 IAID . . . . . . . . . . . : 134217728
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-19-F2-3A-1F-00-14-22-EF-B7-04
   NetBIOS over Tcpip. . . . . . . . : Disabled

Get-NCSIPolicyConfiguration output:

Description                    : NCSI Configuration
CorporateDNSProbeHostAddress   : ::1
CorporateDNSProbeHostName      : directaccess-corpConnectivityHost.mydomain.com
CorporateSitePrefixList        : {fdfd:1374:5130::/48, fdfd:1374:5130:7777::/96, fdfd:1374:5130:1000::1/128,
                                 fdfd:1374:5130:1000::2/128}
CorporateWebsiteProbeURL       : http://directaccess-WebProbeHost.mydomain.com
DomainLocationDeterminationURL : https://DirectAccess-NLS.mydomain.com:62000/insideoutside

netsh int httpstunnel show int:

Interface IPHTTPSInterface (Group Policy)  Parameters
------------------------------------------------------------
Role                       : client
URL                        : https://directaccess.mydomain.com:443/IPHTTPS
Last Error Code            : 0x0
Interface Status           : IPHTTPS interface active

And lastly I went and looked at the configuration on my DA server and it has the following IP configuration:

Internal network IPV6 prefixes:
fdfd:1374:5130::/48

IPv6 prefix assigned to DirectAccess client computers:
fdfd:1374:5130:1000::/64

The internal IPv6 address of my DA server is fdfd:1374:5130:ce07:1000::127

So maybe this is a networking issue?  It seems like I'm getting to the DA server from the client but I'm not able to communicate with the internal DNS server once I'm connected?

Thanks

Nick

Hi,

From your IPCONFIG result we can see and IPHTTPS and a Teredo network adapter fully operationnal. That's surprising to see that if you published only IPHTTPS with my blog post (no teredo support possible). From my point of view Teredo is useless so let's remove it with a NETSH.EXE INTERFACE TEREDO SET SATE DISABLE or  Set-NetTeredoConfiguration -Type Disabled.

You can do the same for 6to4.

I'm afraid that I completely disagree, I recommend using Teredo when possible. :)

(By the way Nick, Benoit and I have been friends for years so there aren't any hard feelings here. It's fun to argue different perspectives every once in a while. Plus he's French, so his blood boils faster than mine and sometimes I try to push his buttons) hahaha - Sorry Benoit, I just had to say it. Don't hurt me ;)

Whether you decide to leave Teredo on or not, either way you have an IP-HTTPS tunnel established on this machine and so that is a good thing. Now what we are likely missing is the IPsec tunnels that need to build themselves inside that IP-HTTPS tunnel. On the authentication screen of the DA wizards, are you requiring certificate authentication? (if you checked the box for pushing Windows 7 clients through, then it would have also automatically selected to use certificate auth as well). The most common cause that I see of being able to establish an IP-HTTPS tunnel but no IPsec tunnels inside is a cert problem. This would be the machine certs that you would have issued from your internal CA server. Or if you did not choose to use cert authentication, these certs wouldn't be necessary, but DA would only work for Windows 8 clients. Keep in mind that not using certificates for authentication isn't a recommended practice (not by me anyway) and so you may want to re-visit that part of the config anyway.

My favorite way to check for the existance of IPsec tunnels is to open up "wf.msc" and drop down the Monitoring section. Then look inside the Security Associations folders. If you see items listed in here, those are the IPsec tunnels. If it is empty here, then this is most likely the problem, that your tunnels aren't building for some reason.

Hi Jordan.

There is no problem, I can control myself :)

My position about
IPHTTPS come from customers of mine witch consider that Windows servers should never have direct Internet connection. For them, I have the IPHTTPS only scenario. It's their requirement so their choice. And yes, I agree with you on the following points:

-We should always deploy DirectAccess with an IPHTTPS certificate delivered by as recognized certification authority

-We should always deploy DirectAccess with IPSEC certificate authentication (requirement for 2FA authentication)

In DirectAccess infrastructure deployed by nick, they made the choice to only offer DirectAccess with IPHTTPs transition protocol. Thats why Teredo is not required at client-side level.

I agree, I went back and read Nick's original post, and by having the DA server sit behind a TMG NAT, yes Nick that means that in your situation you will only have IP-HTTPS available to you. That makes it very interesting that Teredo shows that it is connected with an IP address, and I wonder if your client is tapping into the Microsoft publically-available Teredo relay to receive this address. To make sure that isn't causing you any problems, go ahead and disable Teredo on the client to see if it makes a difference.

I think there was a small typo in the netsh command Benoit typed out, to disable Teredo you can run this: netsh int teredo set state disabled

In fact, for testing if you want to enable/disable any of the given transition technologies, here is a link with procedure for enabling or disabling all three: http://www.ivonetworks.com/news/2012/08/enabling-or-disabling-the-directaccess-adapters-for-testing-6to4-teredo-ip-https/

When a DirectAccess infrastructure is not configured to support legacy DirectAccess clients, client-side GPO do not provide configuration for Teredo protocol. So DirectAccess client initiate a Teredo interface with "teredo.ipv6.microsoft.com.". That's why I disable the Teredo interface.

One point for France :) / New DirectAccess problem in game

I capitulate. :)

When DirectAccess is setup in a way that only IP-HTTPS is possible, then yes you should definitely disable Teredo and 6to4 on all of the DA clients, by using a GPO would be best.

I maintain, however, that the best, best practice in my opinion is to install DirectAccess in "edge" mode, with two NICs, and the external NIC having public IPs so that Teredo connectivity is possible. So I'm taking away half of your point. ;)

It will be a complete victory if this solve nick problem.

Hi guys,

I'm stoked I have two guys working to get my problem resolved :) 

First I've executed the commands to disable both the Teredo and 6to4 protocols on my test client system. Depending on how things go I'll deal with enabling/disabling those things with GPO after I can get my test client successfully connected.  Quick question though. Those disable commands, do the protocols stay disabled thru reboots or do I need to execute those commands every time I restart?  Disabling those protocols didn't resolve the connection unfortunately.

I think given my configuration I'll probably always use the IP-HTTPS protocol since I'm using TMG and can't really change how we connect to the internet. 

My initial setup for DA was based on the following link http://www.isaserver.org/articles-tutorials/general/implementing-windows-server-2012-directaccess-behind-forefront-tmg-part1.html.  I was going to get Windows 8 clients working first since that seemed easier :) - and then add support for Windows 7 clients after.  I've also read some different links like http://syscomlab.blog.com/2012/09/how-to-get-windows-7-to-work-with-directaccess-server-2012/ and http://techontip.wordpress.com/2013/02/13/direct-access-installation-configuration/ and also watched the two different videos mentioned here

How to Install Windows Server 2012 Direct Access with Single Network Card Configuration and windows 8 Clients

http://www.youtube.com/watch?v=CNJOziif03k

 And Windows Server 2012 Direct Access with Basic PKI Configuration and Windows 7 Clients

http://www.youtube.com/watch?v=_jgamV0XDiM

I've actually setup the security groups and  certificates for the Windows 7 clients and the DA server as described in the above links but haven't turned that on yet since I'm only testing Windows 8 clients now.

If I look at my DA server now, on the Remote Access Server Setup wizard on the Network Adapters tab I do have the checkbox checked for Use a self-signed certificate created automatically by DirectAccess option and there is a cert in the with the CN=directaccess.mydomain.com

On the Authentication tab under the user authentication option I have the Active Directory credentials (username/password) option checked. That's the only option I have checked on this tab. 

If I bring up the wf.msc and look in the Monitoring section, I see nothing there except two folders called Main Mode and Quick Mode but both are empty.  If I look at the Connection Security Rules I see this:

Name Profile Endpoint 1 Endpoint 2 Authentication mode 1st Authentication Methods 2nd Authentication Methods Protocol Endpoint 1 Port Endpoint 2 Port Group Local Tunnel Endpoint Remote Tunnel Endpoint Status Authorization 
DirectAccess Policy-ClientToCorpSimplified Private, Public Any fdfd:1374:5130::-fdfd:1374:5130:1000::, fdfd:1374:5130:1000:ffff:ffff:ffff:ffff-fdfd:1374:5130:ffff:ffff:ffff:ffff:ffff, fdfd:1374:5130:7777::-fdfd:1374:5130:7777::ffff:ffff Require inbound and outbound Computer (Kerberos V5) User (Kerberos V5) Any Any Any  Any fdfd:1374:5130:1000::1 OK No 

DirectAccess Policy-ClientToDNS64NAT64PrefixExemption Private, Public Any fdfd:1374:5130:7777::-fdfd:1374:5130:7777::ffff:ffff Do not authenticate None None Any Any Any  None None OK No 

DirectAccess Policy-ClientToNlaExempt Private, Public fdfd:1374:5130::-fdfd:1374:5130:ffff:ffff:ffff:ffff:ffff fdfd:1374:5130:7777::ac10:7f, fdfd:1374:5130:ce07:1000::127 Do not authenticate None None TCP Any 443  Any Any OK No 

If I look at the DirectAccess Policy-ClientToCorpSimplified policy and goto the Authenication tab, it says directaccess.mydomain.com in both authentication mechanisms

Right now I don't have any certs on my test win8 client machine except the trusted roort cert for my internal CA.

Do I need to install some certs on my client? 

Nick

Ok interesting update!!

Looking at the firewall on the client got me thinking about the firewall on the DA server which I had turned off.  I turned on the firewall on the DA server on and boom!!  I got my client connected.  In the DA console I can see my client connection and in the both firewall monitoring views (client and DA server) and I can see an IPsec connection.

So, sorry for not mentioning that before. I normally disable the Windows firewall for our internal servers since I figure we are behind our TMG and don't need the local firewall.  Who know that DA would depend on that.

So now I have an interesting issue on the client.  I can ping any internal system that has only and IPV4 address but I can't ping any internal system that has an IPV6 address.  The names for the IPV6 clients resolve but the ping times out.  And when I ping the IPV4 only clients I get an IPV6 address. I'm guessing this is the doing of the DA server right?

Seems like I'm closer than before :)

Nick

Hi

Disabling a transition protocol stay after reboot. You will be able to configure this with GPO computer configuration\administrative templates\network\tcpip settings\IPv6 transition technologies\

Using self signed certificate is a quick deployment option. For production environments using a certificated delivered from a trusted certificate authority is as good practice.

Hi

Firewall handle IPSEC tunnels for DirectAccess.

When a DirectAccess client try to reach an internal ressources, it must be in IPv6. DNS64/NAT64 handle communication between IPv6 and IPv4 network. If you can resolve internal names it's perfect.

ICMP timeout are another problem. By default a Windows Server with a firewall activated does not allow icmp messages for both IPV4 and IPv6. We have two file sharing firewall rules for that. At last when you ping an IPv4 internal resource, the DNS64 mechanism try to validate network connectivity with a ICMP messages. It targeted ressources does not respond, NAT64 does not op

IPv6 internal ressources only is another point. Have a look at this blog post on my blog : http://danstoncloud.com/blogs/simplebydesign/archive/2013/01/12/dns64-behavior-change-in-windows-server-2012.aspx