The other day I had an issue with DirectAccess 2012, in the Remote Access Dashboard under Operations Status I had a yellow check box under Network Adapters stating there was a problem with one or more of my adapters. Yes ambiguous I know. None the less the DirectAccess clients appeared connected, however lost the ability to route to internal resources. I have had this issue before with a misconfiguration, or a NAT\DNS 64 issues, but all that seemed okay. What was even stranger is this server had been operating perfectly normal for months without incident, the only change if you could call it that, was we ran into multiple bugs in OnTap 7.x and the E1000 Bug in vSphere that caused a PSOD on multiple vmware hosts, including the one this resided on. None the less, the machine migrated hosts, and restarted as it should of per the HA in vSphere. Turns out the issue revolved around there being no default route for our ipv6 prefix. Granted we don't use ipv6 internally but in order for the NAT64 to correctly make that distinction your ipv6 Prefix, in our case that's the one that starts with fe80:: had to be assigned to a default interface. We noticed this by doing a:
netsh int ipv6 show route
This is where we noticed our isatap adapters for our 2002: (NAT64) didn't have a default Gateway or Interface name. In our case we could see form the Route Table that interface 15 was our Local LAN isatap gateway. We now needed to add the route for our 2002 Prefix with the isatap as the Interface name.
We accomplished this by the following NETSH Commands:
netsh interface ipv6 add route interface="" store=persistent
Immediately at this point we could PING out from the DA Server to the clients and the clients could route. It wasn't till a few days later realised that our other "Manage Out" clients couldn't connect to the DA Clients in the field. Turns out we forgot some of more important settings on the route add
NETSH INT IPV6 SET INT <INDEX_NUMBER> FORWARDING =EN ADVERTISE=EN ADVERTISEDEFAULTROUTE=ENNETSH STOP IPHLPSVCNETSH START IPHLPSVC
The fact that we forgot to allow forwarding, basically killed the ISATAP ROUTER being able to forward packets, and the two commands for ADVERTISING was not allowing our Manage out clients to get a proper ISATAP address internally. For instance we had the local link ipv6 addresses under isatap , however we did not have an ipv6 address. Once we ran the commands on the DA Server, then on the client a release and renew all was well.[/fusion_text]