Hello,

After configuring DA 2012, the operation status reports everything is fine except for DNS.

DNS is not working properly. Even though during configuration time, i specified ipv4 addresses for my DNS servers, the GPO are created with ipv6 addresses and i have no idea how he configuration wizard picked these addresses. (I am talking about the DNS servers in Step3 of the configuration manager, the ones that are added to the NRPT table)

If i do an ipconfig on one of my DNS server there is only a local-link address (see output below)

What should i do to fix this? Do DA requires the DNS addresses to be in the ipv6 format? Because if i try to change the config from the RA Management console and put back the ipv4 addresses it is still overwriting my IPs with ipv6 ones?

ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : NLAMSSV11
   Primary Dns Suffix  . . . . . . . : corp.acme.local
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : corp.acme.local
                                       acme.local
                                       acme.com

Ethernet adapter Local Area Connection Gb1:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Broadcom BCM5709C NetXtreme II GigE (NDIS VBD Client) #2
   Physical Address. . . . . . . . . : D0-67-E5-F9-DA-43
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::807b:dd57:9d3e:3766%13(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.2.1.11(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.0.0
   Default Gateway . . . . . . . . . : 10.2.255.254
   DHCPv6 IAID . . . . . . . . . . . : 315647973
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-16-E9-72-17-D0-67-E5-F9-DA-45
   DNS Servers . . . . . . . . . . . : 10.1.1.1
                                       127.0.0.1
                                       10.1.1.42
                                       10.1.1.142
   NetBIOS over Tcpip. . . . . . . . : Enabled

Tunnel adapter isatap.{95B7B839-93D1-42C5-8782-C05DFED8EC07}:

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

Tunnel adapter Teredo Tunneling Pseudo-Interface:

   Media State . . . . . . . . . . . : Media disconnected
   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

Is this DNS server 2008, 2008 R2, or 2012?

I specified my domain name in the NRPT table and it resolved itself (detect and validate buttons) to the IPv6 address of the internal ip adapter of the DA server. That adapter needs the IP addresses of the internal DNS servers in its configuration. DA will then forward all all traffic using IPv4 to your DNS servers and DA client DNS queries should start working. 

DNS servers are running windows 2008 R2.

When i enter the domain name and click detect it populates the IP field with an IPv6 address that is the one of the DA server.

If i click validate, it gives a warning: The specified DNS server is not responding. Ensure that the DNS server role is installed and running on the server.

Does nslookup work from the DA server? And what type of configuration are you running - edge, maybe?

The reason you see IPv6 addresses in the GPO for the client settings is this - DA converts your internal DNS server IPv4 addresses into IPv6 addresses using a site prefix that will start with 2001 or 2002 and then provides IPv6 entries in the NRPT. The DA server, when it receives a request from the client for an internal resource, then encapsulates the IPv6 trafic inside of IPv4 headers for compatibility with your IPv4 networking.

The last two portions of the address(es) you see in the NRPT GPO are a hexadecimal representation of your IPv4 address. In your case, for the IPv4 address of the server you've shown above, the last two portions should read :0a02:010b (if I did the conversion correctly). Half of each section translates to one octet of the IPv4 space.

The DA server is a router, of sorts, for IPv6 traffic.

• Proposed as answer by waingro Thursday, April 25, 2013 4:39 PM
• Edited by waingro Thursday, April 25, 2013 4:40 PM Correction

Does nslookup work from the DA server? And what type of configuration are you running - edge, maybe?

The reason you see IPv6 addresses in the GPO for the client settings is this - DA converts your internal DNS server IPv4 addresses into IPv6 addresses using a site prefix that will start with 2001 or 2002 and then provides IPv6 entries in the NRPT. The DA server, when it receives a request from the client for an internal resource, then encapsulates the IPv6 trafic inside of IPv4 headers for compatibility with your IPv4 networking.

The last two portions of the address(es) you see in the NRPT GPO are a hexadecimal representation of your IPv4 address. In your case, for the IPv4 address of the server you've shown above, the last two portions should read :0a02:010b (if I did the conversion correctly). Half of each section translates to one octet of the IPv4 space.

The DA server is a router, of sorts, for IPv6 traffic.

• Proposed as answer by waingro Thursday, April 25, 2013 4:39 PM
• Edited by waingro Thursday, April 25, 2013 4:40 PM Correction

Does nslookup work from the DA server? And what type of configuration are you running - edge, maybe?

The reason you see IPv6 addresses in the GPO for the client settings is this - DA converts your internal DNS server IPv4 addresses into IPv6 addresses using a site prefix that will start with 2001 or 2002 and then provides IPv6 entries in the NRPT. The DA server, when it receives a request from the client for an internal resource, then encapsulates the IPv6 trafic inside of IPv4 headers for compatibility with your IPv4 networking.

The last two portions of the address(es) you see in the NRPT GPO are a hexadecimal representation of your IPv4 address. In your case, for the IPv4 address of the server you've shown above, the last two portions should read :0a02:010b (if I did the conversion correctly). Half of each section translates to one octet of the IPv4 space.

The DA server is a router, of sorts, for IPv6 traffic.

• Proposed as answer by waingro Thursday, April 25, 2013 4:39 PM
• Edited by waingro Thursday, April 25, 2013 4:40 PM Correction

nslookup works from the DA server for normal queries without any issues

In the DA management console, on the Dashboard i can see everything is OK except for DNS, the error is DNS: Not working properly (View the DNS monitor for more details).

In the DNS monitor, the error is:

None of the enterprise DNS servers fd6b:95ec:1d28:7777::a01:10b,fd6b:95ec:1d28:7777::a01:10c,fd6b:95ec:1d28:7777::a02:10b used by DirectAccess clients for name resolution are responding.
This might affect DirectAccess client connectivity to corporate resources.

Enterprise DNS servers fd6b:95ec:1d28:7777::a01:10b,fd6b:95ec:1d28:7777::a01:10c,fd6b:95ec:1d28:7777::a02:10b are not responding.

From a client, the status is connecting...and stays like this forever.

I can see the client connection on the DA server from the Remote Client Status console: It says Protocol: IPHttps I can see my 3 DNS servers in the Access Details tab

If i collect the logs from a client this is the first error lines:

DirectAccess connectivity status for user: CORP\thomas is
Error: Corporate connectivity is not working. Windows is unable to contact the DirectAccess server. 23/4/2013 14:54:12 (UTC)
Probes List
HTTP: http://directaccess-WebProbeHost.corp.acme.local (Fail)
HTTP: http://nls.acme.com/ (Fail)
DTE List
PING: fd6b:95ec:1d28:1000::1 (Fail)
PING: fd6b:95ec:1d28:1000::2 (Fail)

From the DA server i can ping the IP addresses in the DTE list successfully.

To waingro,

Just an update: i did as you advised, i went to Step 3 of the configuration manager, cleared my DNS addresses and clicked Detect than Validate, updated the config and now the DNS shows a green light on the Dashboard.

Now the logs from a client show in the probe list:

A successful access to http://direct-access-WebProbeHost.corp.acme.local

A failed access to http://nls.acme.com ?? not sure why yet as the test is validated in the config manager

The DTE list is still in fail state

DTE List
PING: fd6b:95ec:1d28:1000::1 (Fail)
PING: fd6b:95ec:1d28:1000::2 (Fail)

Should my DNS server have AAAA records ffor the ipv6 addresses in the DTE list, could it be my i have this error?

I think that is what is intended. It sounds like your client is on the corporate network since it is able to access the http://direct-access-WebProbeHost.corp.acme.local url. It can't access the DTEs because those should be external interfaces and no, you don't need DNS records for those interfaces. Put your client on the internet and see if it automajically connects back to your network.

A good post on DTEs:
http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/thread/0542e6a0-b724-4d7e-a4a7-6d5b2d8455e5/

No the client is not on the corporate network, i am connected to an Internet Wifi...

After every change make sure to update the group policy on the client before trying externally.

What is the result of this command?

netsh advfirewall monitor show mmsa

At this point I think it wise to work your way through this guide:
http://technet.microsoft.com/en-us/library/ee624058(v=ws.10).aspx

This one is helpful as well:

http://www.windowsnetworking.com/articles-tutorials/trouble/7-Steps-Troubleshooting-DirectAccess-Clients.html

Changes have been updated to the client

Here is the result of the command:

C:\Windows\system32>netsh advfirewall monitor show mmsa

Main Mode SA at 04/25/2013 09:33:37
----------------------------------------------------------------------
Local IP Address:                     fd6b:95ec:1d28:1000:7cf2:9cb:c766:5053
Remote IP Address:                    fd6b:95ec:1d28:1000::1
Auth1:                                ComputerCert
Auth2:                                UserNTLM
MM Offer:                             None-AES128-SHA256
Cookie Pair:                          4699bc636211c1d5:93db628c2430899c
Health Cert:                          No
Ok.

Thank you so much for the troubleshooting links, i will have a look  now.

Just a FYI, i spend some quality time with MS to fix the issue, it turned out to be a problem in the NRPT entries.

We have a split-dns setup so we have, on one hand, corporate AD Domain Controllers with DNS integrated zone for acme.com. The DNS zone contains an A record for direct-access.acme.com with a local IP.

On the other hand, there is a Public DNS record for direct-access.acme.com that resolves to a public IP.

What seemed to fix the issue is when in the configuration manager (at Step 3) we created an entry for direct-access.acme.com (same entry as the one for the Network Location Server nls.acme.com with no DNS ip).

After the change Win7 and Win8 clients are happily connecting to the DA server.

Hello,

After configuring DA 2012, the operation status reports everything is fine except for DNS.

DNS is not working properly. Even though during configuration time, i specified ipv4 addresses for my DNS servers, the GPO are created with ipv6 addresses and i have no idea how he configuration wizard picked these addresses. (I am talking about the DNS servers in Step3 of the configuration manager, the ones that are added to the NRPT table)

If i do an ipconfig on one of my DNS server there is only a local-link address (see output below)

What should i do to fix this? Do DA requires the DNS addresses to be in the ipv6 format? Because if i try to change the config from the RA Management console and put back the ipv4 addresses it is still overwriting my IPs with ipv6 ones?

ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : NLAMSSV11
   Primary Dns Suffix  . . . . . . . : corp.acme.local
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : corp.acme.local
                                       acme.local
                                       acme.com

Ethernet adapter Local Area Connection Gb1:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Broadcom BCM5709C NetXtreme II GigE (NDIS VBD Client) #2
   Physical Address. . . . . . . . . : D0-67-E5-F9-DA-43
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::807b:dd57:9d3e:3766%13(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.2.1.11(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.0.0
   Default Gateway . . . . . . . . . : 10.2.255.254
   DHCPv6 IAID . . . . . . . . . . . : 315647973
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-16-E9-72-17-D0-67-E5-F9-DA-45
   DNS Servers . . . . . . . . . . . : 10.1.1.1
                                       127.0.0.1
                                       10.1.1.42
                                       10.1.1.142
   NetBIOS over Tcpip. . . . . . . . : Enabled

Tunnel adapter isatap.{95B7B839-93D1-42C5-8782-C05DFED8EC07}:

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

Tunnel adapter Teredo Tunneling Pseudo-Interface:

   Media State . . . . . . . . . . . : Media disconnected
   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

The reason for this issue is the fact that your DNS Server has a dynamic IPv6 Address. have a look at your DirectAccess Server's IPv6 configuration (should be a static IPv6 Address, and Mimic that configuration on your DNS Servers using the propper IPv6 Addresses given to you by your Error in Direct Access Operations Status. Reboot your DA Server Force a Group Policy Update and you should be good to go.

I really stuck with the very same problem. 

Two servers:

1. Server1- Server 2012, DC, DNS and Hyper-V host
2. Server2 - Server 2012, Hyper-V VM, DA and RRAS.

Client (Win7) is able to establish IP-HTTPS (I even can see them as connected in the Remote Access Manager as DirectAccess clients connected), IPv6 of DA is pingable from clients but nothing really work. I feel that this is caused by the same problem as on the topicstarter: DA doesn't know DNS address. 

Questions:

1) Should I set static IPv6 for the DNS (DC) server (there is no IPv6 DHCP anyway)?
2) If Yes, how to determine this address?
3) Should I put static IPv6 address of DNS in DA NIC settings, respectively? 

Hi,

IPv6 addresses were needed for DirectAccess only when introduced with Windows Server 2008 R2. This requirement disapeated with ForeFront UAG 2010 that introduce DNS64/NAT64 feature. Unless you hace an active ISATAP router, none of your Windows computers will be able to generate an IPv6 routable address. The only case when a Windows Operating system generate a routable IPv6 address is when your IPv4 IP plan does not comply with RFC1918.

But your DirectAccess clients need an IPv6 address for DNS. This IPv6 address is generated using the internal IPv4 address of your DirectAccess Gateway. You will recognize it as it use 3333::1 as a prefix.

thank you for your input.

OK, IPv6 address with 3333::1 exists and reachable (as you can see on the screenshot above). This is address of DA itself that should act as DNS proxy. However, it seems it doesn't work. It seems that all the rest works, this is only problem. 

I worked out this guide

https://technet.microsoft.com/en-us/library/ee624058%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396 

and everything fine till step 10 as well as step 12. I don't understand step 11 because I don't have IntranetDNSServerIPv6Address This is actually my question.

Could you advice next steps? I run out of ideas.

Hm, I found that if I type nslookup <any FQDN in my network> <DA IPv6> (without -q=AAAA) it resolves any existent address and I can ping them by IPv6! It means that tunnel up and DNS works.

But I can't ping any IPv4 except 192.168.43.1 that seems IPv4 address of DA adapter itself (never seen this subnet before)

Hi,

When your DirectAccess client is located on Internet. NRPT is enabled and command NETSH NAMESPACE SHOW EF should show you the content of the NRPT config. Name resolution is the first step. If you can resolve IPv6 addresses with DIrectAccess, DNS64 is operational. Next point, ping. By default Windows Firewall does not allow a server to respond to ICMP messages unless corresponding firewall rules are open (File and Print if I remember well). That's the first thing to check.

Second point, check if you can reach the resource from your DirectAccess Gateway. You will be able to reach it using IPv4 address.

Last point : In DirectAccess, you can only reach IPv6 addresses, not IPv4. IPSEC tunnel definition only allow IPv6 network traffic to pass throught IPSEC tunnel.

I almost there...

1. netsh namespace show policy and netsh namespace show effective show correct information
2. I can resolve IPv6 both with nslookup and nslookup -q=aaaa when I explicitly put DNS server from previous step
3. I can ping IPv6 addresses obtained from previous step for any pingable node in my network
4. I CAN'T ping by FQDN and none of network-enabled application works on client

I looks like despite of correct NRPT, client still use default DNS for obtained for NIC (Wi-Fi)

Any ideas?

Hi,

2 things to check :

-Can you reach the resource from the DirectAccess Gateway (so in IPv4)?

-Are you sure incoming firewall rules allow ICMP messages?

I can't believe but it seems it works!

I think the problem was with NLS name (and location), which FQDN was the same as DC (with DNS role installed). Perhaps, because exclusion of this FQDN in NRPT, client cannot communicate with DC (and "main" DNS) over tunnel and this caused a problem.

Since I don't have third server, the tricky part was relocation NLS to DA because IIS has already bounded SSL certificate with external DNS in subject. I set new A record and enroll new certificate but even though I tried to set different site names, it broke my RD and SSTP setup. So, I ended up with different (non-standard) port (444) for NLS. Never seen non-standard NLS port but it works! :)

Thank you for you help!

I need some more time to ensure if it works reliable and will keep you posted on any new issues. 

Hi,

Hosting NLS on an existing server is possible if you use an alternate name. Otherwise, services co-located on the server won't be reachable from DirectAccess clients. In case of a domain controller, it can be critical as it can be used for NTLM/Kerberos authentication by your DirectAccess clients.

If that solve your problem, mark question as answered.

I can't believe but it seems it works!

I think the problem was with NLS name (and location), which FQDN was the same as DC (with DNS role installed). Perhaps, because exclusion of this FQDN in NRPT, client cannot communicate with DC (and "main" DNS) over tunnel and this caused a problem.

Since I don't have third server, the tricky part was relocation NLS to DA because IIS has already bounded SSL certificate with external DNS in subject. I set new A record and enroll new certificate but even though I tried to set different site names, it broke my RD and SSTP setup. So, I ended up with different (non-standard) port (444) for NLS. Never seen non-standard NLS port but it works! :)

Thank you for you help!

I need some more time to ensure if it works reliable and will keep you posted on any new issues. 

• Proposed as answer by Nikriaz 19 hours 28 minutes ago

I can't believe but it seems it works!

I think the problem was with NLS name (and location), which FQDN was the same as DC (with DNS role installed). Perhaps, because exclusion of this FQDN in NRPT, client cannot communicate with DC (and "main" DNS) over tunnel and this caused a problem.

Since I don't have third server, the tricky part was relocation NLS to DA because IIS has already bounded SSL certificate with external DNS in subject. I set new A record and enroll new certificate but even though I tried to set different site names, it broke my RD and SSTP setup. So, I ended up with different (non-standard) port (444) for NLS. Never seen non-standard NLS port but it works! :)

Thank you for you help!

I need some more time to ensure if it works reliable and will keep you posted on any new issues. 

• Proposed as answer by Nikriaz Tuesday, August 04, 2015 11:55 AM

So far so good but

- have issues with performance (speed). I believe it relates to the whole RRAS subsystem because SSTP and PPTP display similar speed. While total bandwidth is not worse than 10 Mbit/s, I have file copying 30-60 Kb Kbyte/s. On hardware VPN (IPSec) on the same channels I have ~ 1Mbyte/s. 

- Something broke in RDP. Now, RemoteApps published on the same VM as DA always ask for credentials when clients starts them. It definitely related to DA because before it worked robust.

So, this game is going to be endless :(

For NLS, I found this post helpful http://blog.ryanbetts.co.uk/2014/06/directaccess-configuring-network.html 

Hi,

You might have performance issues with Windows 7 in IP-HTTPS scenario as we have two encryption level -IP-HTTPS ans IPSEC. If you plan to support both legacy and Windows 8/10, the issue remain. Otherwise, you can removce support for Windows 7. In this situation Cipher suite to be used will not perform enryption. Noe that if you colocate VPN and DirectAccess on the same platerorm, you will automatically loose the benefit of IP-HTTPS null encryption cipher suite.

Colocate Remote-App with DirectAccess might not be a good option. Both rely on HTTPS, at low level. Not sure it was designed by Microsoft to be co-located.

Hello, thank so much for your input. It seems I solved last problems.

Poor performance was caused enabled jumbo frames option. It was enabled everywhere (NICs, Virtual Switch) but in fact I didn't use since this server used remotely. After disabling, speed increased dramatically back to the normal level. I made brief measurements, it looks like DA has best performance, SSTP a bit worse, PPTP is worst one (approx. 10% below DA).

For RDS and DA, it looks like problem primarily caused by authentication type. It works now but still has some issues.This is difficult subject, I will post it separately.