Error: 0x2AF9
Role: Client
URL: `https://da.contoso.com/IPHTTPS`
Last Error Code: 0x2AF9
Interface Status: Failed to connect to the IPHTTPS server; waiting to reconnect
0x2AF9 translates to:
WSAHOST_NOT_FOUND
# No such host is known.
WSAHOST_NOT_FOUND
# Non-NULL value successfully returned.
There are several reasons this error may occur:
A proxy is blocking the connection.
Inability to resolve the name of the IP-HTTPS server (DirectAccess server).
Client-side or server-side firewall may be blocking the connection.
NAT device in front of the DirectAccess server is configured incorrectly (if a behind-edge scenario is being used).
All connectivity is fine, but the server does not have the IPv6 prefix published, or server-side IP-HTTPS is set to disabled.
Resolution
Try to connect to the server through telnet by using the external IP address or name of the DirectAccess server on port 443. If it fails to connect, this may be because the packet is being dropped somewhere on the network, or the NAT rules are not created correctly on the external NAT device behind which DirectAccess is configured.
For more information, please see the "Plan firewall requirements" section of the following page at Microsoft Technet: Plan the DirectAccess Infrastructure
The external name should be resolvable from the client. Try to ping the name of the IP-HTTPS site name (the DirectAccess server public name), and check whether the name resolution is succeeding. If the name does not resolve, fix the name resolution.
We are just looking for success of name resolution of the DirectAccess server's public name to an IP address, and not the actual success of the Ping command.
If a telnet connection is successful, then look at a network trace. The SSL handshake should be successful.
Reset the local system proxy settings. You can manipulate these settings by viewing the proxy settings in Internet Explorer. You must open Internet Explorer under the local system context rather than by using a normal account.
DirectAccess clients may be configured to reach the HTTPS site through a proxy server (which may be blocking the connection). The latest proxy addresses are cached in the registry. To view them, open Registry Editor (regedit) on your DirectAccess client, and then navigate to the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\iphlpsvc\Parameters\ProxyMgr
Export the ProxyMgr registry subkey. If you no longer use the proxy server, remove all registry keys under this registry subkey, and then restart the DirectAccess client.
DirectAccess connectivity methods
DirectAccess clients use multiple methods to connect to the DirectAccess server, which enables access to internal resources. Clients have the option to use either Teredo, 6to4, or IP-HTTPS to connect to DirectAccess. This also depends on how the DirectAccess server is configured.
When the DirectAccess client has a public IPv4 address, it will try to connect by using the 6to4 interface. However, some ISPs give the illusion of a public IP Address. What they provide to end users is a pseudo public IP address. What this means is that the IP address received by the DirectAccess client (a data card or SIM connection) might be an IP from the public address space, but in reality is behind one or more NATs.
When the client is behind a NAT device, it will try to use Teredo. Many businesses such as hotels, airports, and coffee shops do not allow Teredo traffic to traverse their firewall. In such scenarios, the client will fail over to IP-HTTPS. IP-HTTPS is built over an SSL (TLS) TCP 443-based connection. SSL outbound traffic will most likely be allowed on all networks.
Having this in mind, IP-HTTPS was built to provide a backup connection that is reliable and always reachable. A DirectAccess client will make use of this when other methods (such as Teredo or 6to4) fail.
More information about transition technologies can be found at IPv6 transition technologies.
