We are testing out DirectAccess on 2016 in a lab and so far everything has been working pretty well. Clients are connecting in, getting GPO, accessing files shares, RDP works, etc. Inbound is great. However, outbound/manage out is proving to be a problem. I have gotten it to work a few times but it looks like I have DNS issues based on the behavior. In this scenario my manage out internal server is an SCCM system. I'd like to be able to remote control DA clients like we do internally.
I have a 2 NIC DirectAccess server in the DMZ. We NAT to the DMZ interface, 443 inbound. The interface also holds the default gateway (second NIC is blank on the gateway). It's configured to use certs + AD auth. We're not doing force tunnel (yet). My infrastructure server is the SCCM server in question. I have specified my internal domain search suffix as well. We have an NSL web server running internally as well.
For the manage out clients I have configured ISATAP using a DNS alias + GPO to enable it on the SCCM server. This appears to be working for the most part but this is where it gets murky.
I bring my DA system online. It registers in DNS on the domain controllers with the IPv6 address. At first I am completely unable to ping that system from SCCM. If I do an NSLOOKUP <client host name>. It resolves (doesn't matter if I use the host name or FQDN for nslookup). If I ping that hostname it will fail. If I ping the FQDN AFTER doing an NSLOOKUP it fails on the first attempt. If I ping it a second time it responds. This second ping situation happens pretty consistently. Sometimesafter pinging the FQDN successfully I can then ping the host name. If I leave it for awhile (15-30 minutes) I won't be able to ping anymore. I can then do the nslookup and repeat the process. Like there's some odd failure to cache long term. See below;
At this point it is very hit or miss if I will be able to remote control the client from SCCM. But one thing is consistent, if I remote control the host name it fails. If I manually type in the FQDN using the File > Connect option it generally work. That's why I don't believe it's firewall related. Though I have turned on logging dropped packets on the client just in case.
I saw this similar post but it dead ended. This gentleman was having a very similar remote control + FQDN issue.
I feel like we're close but need some help getting this last bit of DNS weirdness sorted out. Thanks in advance for any feedback.