I have been searching all over for a resolution and have tried many different configurations trying to figure this one out.  

We have been testing Direct access for a few months and have worked out most of the bugs/problems with it.  However one issue we havent been able to resolve is DA client to DA client connectivity.  Both clients connect via DA fine and can access all network resources, but as soon as you want to connect to another DA client from another DA client, it fails.  

Trying to ping the other DA client throws the well know error:

    Ping request could not find host xxxx. Please check the name and try again.

Trying to ping the IPv6 address fails as well.   

Pinging the same DA client from the DA server or another system that is on the intranet seems to work fine.

Anyone run into this before?

Hi

I've already worked on that topic.

Direct communication from DirectAccess client to other DirectAccess client if performed outside IPSEC tunnel (unless force tunneling enabled). So some security measures will be required.

By default unsollicited network flow are blocked in the Windows Firewall. So dont forget to configure the "NAT-Transversal" feature for the public and private Windows Firewall profile. Name resolution can be a problem if clients does not register itself in DNS.

The records are there in DNS.  I can ping them from other ISATAP clients that are internal to the network (I get ipv6 replies back).  Its just the DA client to DA client that fails.  

I understand how opening the windows firewall can help in this situation but shouldn't the DA Client be able to find the dns record of the other DA client when trying to ping?  If the client can't find or use the DNS record then I would have to resort to using the v6 address.  

Hi

Client can record it's name only if interface if configured to do so. Are you sure you have the correct IPV6 record in your inernal DNS?

yes, there are registering fine once connected thru the DA server.  

Does isatap need to be enabled as well for client to client communications?

ISATAP is only required for internal IPv6 usage. There is no need to have an ISATAP interface on a DirectAccess client connected on Internet. Having ISATAP operational with DirectAccess could lead to IPv6 routing issues.

Understood.  Thanks for that info.  

But back to the issue; is there anything in the DA Server firewall that needs to be done ?  

No Nothing to change in the DA Gateway configuration. Only on client-side.

If the clients are to communicate outside the ipsec tunnel then wouldn't they be using ipv4 instead of their ipv6 address?  

Sorry if I'm not understanding this correctly, but i'm just trying to find out why this would be this difficult.  

When they will resolve names, it would be in IPv6. So clients will use IPv6.At last, they wont use IPSEC tunnels because tunnels enpoints only cover internal network (organizational IPv6 prefix).

as you can see the DNS records are there:



The below pic is of pings to other internal host.  at the very bottom is the attempted ping of the DA client with the error stating that it cant find the host:

• Edited by joel.delatorre Friday, February 21, 2014 3:36 PM

as you can see the DNS records are there:



The below pic is of pings to other internal host.  at the very bottom is the attempted ping of the DA client with the error stating that it cant find the host:

• Edited by joel.delatorre Friday, February 21, 2014 3:36 PM

It just say that your DirectAccess client is not able to resolve a hostname to IPv6. Can you try with a suffix. and check name resolution with the following approach :

NETSH NAMESPACE SHOW EF

Get the IPv6 address of the DNS servers to be used for internal name resolution

NSLOOKUP

Server <IPv6>

Type name of hostname to resolve.

Pinging full suffix comes back with same error.

Also ran nslookup and came back with nothing.  

>
> xxx-5
Server:  [fd6c:e05b:a606:3333::1]
Address:  fd6c:e05b:a606:3333::1

Name:    xxx-5.domain.com

>

So it seems to me that the DA server chooses to not return the DNS record back to the DA client.  

So it's a DNS registration problem.

And i would agree with you however if you look at my pics i've attached earlier you can see that the DNS records are there.  And they are working because I can ping the clients by name from an internal client that is isatap enabled.  

It's ,not the same source for the answer. For ISATAP, your ISATAP client directly connect to the DNS to get the information. With DirectAccess, you dont have DirectAccess to your DNS. You rely on DNS64 first. Its this component that respond to you. You may be affected by the new behavior of DNS64 introduced in Windows Server 2012. Have a look at this :  http://danstoncloud.com/blogs/simplebydesign/archive/2013/01/12/dns64-behavior-change-in-windows-server-2012.aspx

that helped.  Pinging from the DA client now at least comes back with the v6 address.  Still can't ping but I think that could be a firewall issue on the client.  Internal ISATAP client can ping though.  

C:\Users\jdelato>ping xxx-5

Pinging xxx-5.domain.com [fd6c:e05b:a606:1000:5057:e5d5:d5bc:a3bd] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for fd6c:e05b:a606:1000:5057:e5d5:d5bc:a3bd:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

• Edited by joel.delatorre Friday, February 21, 2014 5:38 PM

that helped.  Pinging from the DA client now at least comes back with the v6 address.  Still can't ping but I think that could be a firewall issue on the client.  Internal ISATAP client can ping though.  

C:\Users\jdelato>ping xxx-5

Pinging xxx-5.domain.com [fd6c:e05b:a606:1000:5057:e5d5:d5bc:a3bd] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for fd6c:e05b:a606:1000:5057:e5d5:d5bc:a3bd:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

• Edited by joel.delatorre Friday, February 21, 2014 5:38 PM

Hi

Good, I forgot the DNS64 behavior change. Next move is your firewall issue. After that Network flow would work between your DirectAccess clients. Securing them will be the last topic.

Thank BenoitS. that fixed this issue.  

By fixing, do you mean you can now actually ping/communicate between two DA clients? I can succesfully resolve them, but the traffic doesn't seem to arrive... Trace shows echo request but no reply. I enabled "log dropped packets" but nothig particular pops up...

Also I assume the following statement is incorrect? http://social.technet.microsoft.com/Forums/windowsserver/en-US/e35f0288-2abd-48ba-bd5f-6c67634397f7/directaccess-client2client-communication?forum=winserver8gen

Thanks in advance for some feedback!

Yes, full communication is working.  I just had to make sure Windows firewall ports were open for whatever communication was needed.

Thanks for confirming.

This stuff is hard to troubleshoot. Aside from the fact that IPv6 is slightly different than IPv4 all the tunneling and virtual interfaces don't help at all ;) I'll probably let this one rest till after the weekend and start with a clear head.

Am I correct to state that the FW rules on the DA are "non-relevant" for this to work? I would assume that this traffic is handled by the IPHTTPS interface and it all stays on the same subnet (the DA client subnet).

Hi

Now start the fun part. How to secore communication between DirectAccess clients as traffic wont does in DirectAccess tunnels.

Yes, full communication is working.  I just had to make sure Windows firewall ports were open for whatever communication was needed.

Can you clear this up for me. I have RDP/RA working DA-DA after making the changes on the DA server to resolve AAAA records.

But I get the issue where if I ping DA->DA I get a request timed out. Even though I have the ICMPv6 Echo Rules turned on and configured and edge traversal allowed. I just don't get a response. I am scratching my head as to why its not pinging the client.. Internal out works fine, as well as ISATP out. Just DA->DA ping won't respond.