Tech Blog

I was working with Direct Access recently and the manage out function. The idea is servers on premises can communicate with direct access clients on the internet who are using a IPv6 over IPv4 protocol.

For example, it’s great when you want to manage SCCM clients who are not in the office.

To do this you need an ISATAP server that sits in-between the Direct Access servers and the internal servers, I like to think of ISATAP as like a DHCP/DNS server that gives out IPv6 addresses to internal servers which then in turn allows them to query IPv6 clients.

I’m going to presume you’ve setup Direct Access and ISATAP and at some point it was all working (if anyone wants a guide on setup of ISATAP, just shout), now for what ever reason you can not resolve IPv6 clients!!

• Logon to your Direct Access (DA) Server, pick a client and check you can ping it, it should return a IPv6 address.
• 
• Logon to your ISATAP server and ping the same client, if it does then great the issue is not between DA and ISATAP, if not then it’s time to check your connectivity (firewall and routes) between the two servers.
• Logon to a server that that using the ISATAP server and ping the same client, in my case this did not work.
• So first check the interface on the server, ipconfig /all

This is bad.  If its fe80 it means windows has assigned a IP itself and not had a address assigned from ISATAP, bit like APIPA address.

• You can disable and enable ISATAP on the server to check if it changes to fe70

netsh int ipv6 isatap set state disable

netsh int ipv6 isatap set state enable

• Moving back to the ISATAP server, there basically two things to check, the interface and the routes
• First check the interface and its idx number:

netsh Int ipv6 show int

• In my case I know the interface I configured when I set up the server was IDX 6 where as below it shows IDX 9, this means that something has changed, potentially a VMWare hardware update.

• As the interface has changed that means the interface settings have been lost and the static routes, so lets add them again:
  • First on the NIC, add forwarding:

netsh Int ipv6 set int 12 forwarding = enabled

• • Then on the ISATAP Interface

netsh Int ipv6 set int 9 advertise = enabled
netsh Int ipv6 set int 9 forwarding = enabled

• Next check the routes for the interface, the magic route is mising

netsh int ipv6 show route

• Add it back

netsh interface ipv6 add route fd07:4444:4444:1::/64 9 publish=yes

• Finally check the server again

• YAY!!!

Had a odd issue with our Direct Access servers today, We kept getting the following errors:

“There is no valid certificate to be used by IPsec which chains to the root/intermediate certificate configured to be used by IPsec in the DirectAccess configuration.”

After a day or two of not doing anything we couldnt event open the direct access console:

Or see any of the settings in PowerShell:

So whats the issue?  Turns out our Certificates had updated, namly our root and intermediate certificate and the direct access console didnt know what to do.

So to fix it, I’ll need to update the cert.

Open PowerShell and find the cert you want to use (the root or intermediate cert you used before):

Get-ChildItem Cert:\LocalMachine\Root

Then set this cert:

$certificate = (Get-ChildItem Cert:\LocalMachine\Root\1111111111111111111111111111111111222222222222)
Set-DAServer -IPsecRootCertificate $certificate

Open the Direct Access console and give it a try.

My Windows 10 client wouldn’t connect to our Direct Access severs today, kept just getting Connecting

So to troubleshoot I’d recommend:

Checking your internet connection:

Now its worth running some PowerShell commands to get the actual error:

Get-NetIpHttpsState

This likeley means your proxy is in the way of your connection.

Check the settings:

Get-NetIPHttpsConfiguration

Double check your internet connection

Test-NetConnection

I think its time to check the proxy settings:

Check if you can get to a website via IE and try via another browser such as Firefox.

If you cant then check if your proxy is off:

Now check the windows 10 proxy and the Netsh proxy:

Windows 10, turn it off:

Check the netsh and then turn it off or reset it to IE:

#Show the proxy settings:
netsh winhttp show proxy
#Reset it to default
netsh winhttp reset proxy
#Set to IE
netsh winhttp import proxy source=ie

When reset should look like this:

Failing that reset the IP Helper in services.msc or reboot:

The netsh settings fixed it for me, the reason I’d set it was to allow PowerShell out to the internet for Exchange 365 work.