Ip‑https tunnel failure behind home routers

Ayu Lestari 40 Reputation points
2026-08-28T03:19:06.4233333+00:00

Restarted the DirectAccess client and it could not establish the IPsec outer tunnel through IP‑HTTPS. Packet captures show that the home NAT router modified HTTPS payload headers, breaking tunnel negotiation. I have already verified certificate trust and firewall rules, but the connection still fails. Is there a recommended way to configure IP‑HTTPS fallback mechanisms or enable Null Encryption options to maintain connectivity for clients behind strict routers ?

Windows for business | Windows 365 Business
0 comments
Answer accepted by question author
Hoang Le 4,665 Reputation points Independent Advisor
2026-08-28T05:44:46.73+00:00

Hello Ayu,

The failure you’re seeing is due to the home router modifying TLS payloads, which breaks IP‑HTTPS negotiation. DirectAccess requires a clean TLS channel, so any SSL inspection or header rewriting will cause the IPsec outer tunnel to fail. Null encryption is not a supported option in production; it was only meant for lab testing and should not be enabled in real deployments. The recommended path is to ensure IP‑HTTPS traffic is not altered in transit, or provide an alternate VPN method such as IKEv2 for clients behind restrictive NAT devices. Teredo and 6to4 are technically available as fallback, but they are unreliable behind symmetric NAT, which is common in home routers. If you want to confirm the exact cause, run netsh trace start scenario=DirectAccess and check logs under %windir%\tracing for TLS handshake errors. If SSL inspection is present, the only fix is to disable it or use a different network path. There is no registry tweak or supported configuration to bypass this behavior.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

HL.

Was this answer helpful?

1 person found this answer helpful.
0 comments

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-08-28T03:19:29.13+00:00

    IP-HTTPS is already the fallback method when DirectAccess cannot use 6to4 or Teredo. The supported guidance in this scenario is not to enable a separate IP-HTTPS fallback mode or Null Encryption option.

    For clients behind strict home routers, use this troubleshooting path:

    1. Verify that the DirectAccess server public name resolves correctly from the client.
      • The required check is successful name resolution to the DirectAccess server public IP.
    2. Test TCP 443 connectivity to the DirectAccess server external name or IP.
      • Try a telnet connection to port 443.
      • If this fails, the connection is likely being dropped by a firewall or by incorrect NAT rules on the path.
    3. If TCP 443 connects, inspect the SSL handshake in a network trace.
      • The SSL handshake should succeed for IP-HTTPS to work.
    4. Check for proxy interference on the client.
      • DirectAccess clients can cache proxy settings.
      • Review the proxy configuration under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\iphlpsvc\Parameters\ProxyMgr.
      • Export the ProxyMgr key first. If the proxy is no longer used, remove the registry values under that subkey and restart the DirectAccess client.
      • Warning: registry changes can affect connectivity if done incorrectly.
    5. If certificate trust was already verified, also confirm the full certificate chain is present.
      • The root CA certificate must be in the Trusted Root Certification Authorities store.
      • Intermediate CA certificates must be in the Intermediate Certification Authorities store.
    6. If the issue is specific to certificate validation over IP-HTTPS, confirm revocation checking can succeed.
      • DirectAccess requires certificate revocation checking for the IP-HTTPS connection.
      • The IP-HTTPS certificate must include an Internet-accessible CRL distribution point for Internet-connected clients.

    Relevant behavior:

    • DirectAccess first tries 6to4 when the client has a public IPv4 address.
    • If the client is behind NAT, it tries Teredo.
    • If Teredo or 6to4 cannot be used, the client fails over to IP-HTTPS over TLS on TCP 443.

    The provided guidance does not document a supported Null Encryption configuration for this problem.

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.