This came up as a side issue during some troubleshooting for client connectivity (posted here). I needed to find a reliable way to force client machines to use Teredo or IP-HTTPS while running tests. Forcing a client to use IP-HTTPS was easy enough to do in Windows 7 as you can just block outbound UDP on port 3455, this is the port that Teredo uses so it can’t establish a connection and the client then defaults back to IP-HTTPS.
Finding a way to force the client to use IP-HTTPS should have been straight forward as this is the least preferred protocol as it has the largest performance overhead (from the SSL connection it needs to establish). Generally if you run an ipconfig on the client machine you can tell what protocol your using. Normally if you have an IP listed against “Tunnel adapter iphttpsinterface:” then you are using IP-HTTPS to connect. If you have something listed against “Tunnel adapter Teredo Tunneling Pseudo-Interface:” then you are using Teredo. Sometimes you will see both IP-https and Teredo with IP’s, this can occur during normal operation if the Teredo tunnel has had problems establishing a valid connection.
During my testing I found that suddenly from one day to the next Teredo had stopped establishing a tunnel so the client was always reverting back to IP-HTTPS and there had been no configuration changes.
It turns out that when Teredo makes its connection to the internal network it performs a pre-defined DSN lookup that should only be resolvable by the internal DNS servers. The response should come back with “::1” which is the IPv6 localhost loopback address.
What had happened is that UAG had auto-registered its default DNS entry for Teredo validation “UAGDirectAccess-corpConnectivityHost.domain.tld”. The Client then had expiry and scavenging enabled on their DNS servers. After a period of time the DNS entry had reached the scavenging period and had been removed from internal DNS. UAG will only ever re-create this record when it is re-activated or restarted (if the record does not exist), it will not renew the entry in DNS as part of its day to day operations.
Fortunately the solution was fairly simple, manually create the “UAGDirectAccess-corpConnectivityHost” in DNS so that it never ages or gets removed automatically!
Again a huge thanks to Balint from Microsoft PSS for his assistance working through this issue!