While it seems like the hype surrounding the expiration of available public IPv4 addresses and the DIRE NEED to move to IPv6 has died down, it is a legitimate problem and that means companies are taking steps to make more and more communications become IPv6. What this means for the typical end-user, at this point, is simply that an ipconfig these days might show that you have an active IPv6 address from your router, alongside your normal IPv4 address.
For example, here is a fairly common result of an ipconfig on a client computer connected to a home wifi router:
You’ll notice I have a normal IPv4 address of 192.168.1.66, which is a very common address space for any home network. However, what immediately stands out to me here related to the DirectAccess world is the existence of a native IPv6 address as well. That address starting with 2602: immediately stands out to me, as I’ve seen it cause trouble time and time again. I believe the first time I discovered this was back in 2010, so this is nothing new, but it is quickly becoming more and more common as new routers and ISPs tend to enable IPv6 by default.
You’re probably thinking – “but wait a minute, I thought DirectAccess used IPv6 anyway, why would a native IPv6 address from my router cause me problems with DirectAccess?” That is a great question. DirectAccess does use IPv6, which means that DA is also trying to setup an IPv6 address on your client computer, and this native IPv6 address can conflict with it. You see, when you connect a DirectAccess computer to the internet, it will typically establish either a Teredo or IP-HTTPS tunnel back to the DirectAccess server. This tunnel is your IPv6 transition tunnel, and it will give you an IPv6 address on your computer as well. This is the address that DirectAccess MUST USE in order to build IPsec tunnels into your corporate network. If you do not have a native IPv6 address on your client computer, the IPsec tunnels are built over the DA transition tunnel as they should, with no potential for interference. But as soon as a native IPv6 address exists on the system, there is a potential conflict. Unfortunately, the Windows Firewall who is responsible for building those IPsec tunnels does not seem to be smart enough to know that it must always use either a Teredo or IP-HTTPS tunnel in order to build those IPsec tunnels. So occasionally when a client has a native IPv6 address and an IP-HTTPS address, for example, WFAS will choose incorrectly, and it will attempt to build the IPsec tunnels that are necessary for DirectAccess connectivity over the native IPv6 address. This address does not have a valid destination that can reach the DirectAccess server, since all DA servers are installed on the public IPv4 internet, and so that traffic fails to go anywhere. When you cannot establish IPsec tunnels, your DirectAccess doesn’t work.
What does this look like in the real world? Well, when you generate DirectAccess troubleshooting logs, one of the first things you see in that log is what I showed above, the IP address information on the client. If you see a native IPv6 address (typically they will start with 2602), this is always a red flag and something you need to address. However, something more specific in the logs that you can look for is down in the IPsec Main Mode SAs section of the logs. As you can see in the screenshot below, I have an IPsec tunnel that is attempting to establish, but you can see that the LocalEndpoint address it is trying to use is that 2602 address. This is bad news. That IPsec tunnel will never connect, and I currently have a “broken” DirectAccess client. If I were to get rid of that 2602 address, DirectAccess should flip over to using the IPv6 address presented by either Teredo or IP-HTTPS, and connect without a problem.
I have seen many cases where a DirectAccess client computer has both a DirectAccess transition tunnel address as well as a native IPv6 address and DA has been working just fine. Those are the lucky ones. What you need to be aware of, though, is that the next time that laptop reboots or goes into standby and then re-establishes IP addresses, those IPsec tunnels are rebuilt every time, and so even though it works today, it might not connect tomorrow. It is always best to get rid of that native IPv6 address and let DirectAccess do its job.
Speaking of getting rid of that native IPv6 address, how do we do that? You could log into your home router and disable DHCPv6 so that it stops handing out those addresses in the first place, but that would be a major administrative headache if you needed to instruct your users on how to accomplish that. What is much easier, albeit cumbersome, is to open up the NIC properties on your DirectAccess laptops, and uncheck the TCP/IPv6 box. This will cause the laptop to stop getting native IPv6 addresses no matter what network the user connects to, while still allowing DirectAccess IPv6 to do its thing.
Keep in mind that if your laptops have a wireless NIC and a physical ethernet port and users may potentially connect via either method, you should uncheck the TCP/IPv6 box from both NICs. This ensures they will not receive a native IPv6 address from either kind of network.