Azure DevOps IPv6 TLS connection resets on Box 12 — IPv4 works, disabling IPv6 resolves it

Hello,

I’m experiencing frequent, intermittent connection failures to Azure DevOps on my KPN home connection. The issue appears to have started after switching to KPN. Telephone support suggested posting here.

I’ve narrowed it down to connections over IPv6 and would appreciate investigation by the modem or network team.

Modem details

• Model: KPN Box 12 / SagemcomFast5359_KPN
• Hardware version: 4.0
• Active firmware: V12.C.26.04.02

Symptoms

Git operations fail both in Visual Studio and in standalone PowerShell. Typical errors are:

Send failure: Connection was reset
Recv failure: Connection was reset

Both Azure DevOps hostname formats are affected: dev.azure.com and the older *.visualstudio.com addresses.

I am not using a VPN or a manually configured proxy.

Tests and results

• Mobile hotspot: the same computer and repository work through a mobile hotspot.
• IPv4: repeated HTTPS tests succeed consistently.
• IPv6: repeated HTTPS tests frequently time out or fail with a connection reset, although some attempts succeed.
• HTTP/1.1: explicitly forcing HTTP/1.1 in Git did not resolve the issue.
• Modem IPv6 toggle: disabling IPv6 makes Git work reliably in my testing. Re-enabling IPv6 brings the failures back.

Verbose HTTPS failure

This command reproduces the problem without using repository credentials:

curl.exe -6 -v -I --connect-timeout 10 --max-time 20 https://dev.azure.com/

One failed attempt produced:

Host dev.azure.com:443 was resolved.
IPv6: 2603:1061:10:1::16, 2603:1061:10::16
IPv4: (none)
Trying [2603:1061:10:1::16]:443...
schannel: disabled automatic use of client certificate
ALPN: curl offers http/1.1
Send failure: Connection was reset
schannel: failed to send initial handshake data: sent 0 of 460 bytes
closing connection #0
curl: (35) Send failure: Connection was reset

The IPv4: (none) line reflects the use of -6 for this test. IPv4 connectivity works.

This particular failure occurs while attempting to send the initial TLS handshake data. The output does not report a server-certificate validation failure.

For comparison, IPv4 can be tested with:

curl.exe -4 -v -I --connect-timeout 10 --max-time 20 https://dev.azure.com/

Traceroute results

A Windows IPv6 traceroute:

tracert -6 -d -w 1000 dev.azure.com

successfully reached 2603:1061:10:1::16 at hop 19, with final response times of approximately 11–13 ms. Some intermediate hops did not respond.

The modem’s own IPv6 traceroute also showed responses from intermediate hops and a final address of 2603:1061:10::16. However, it labelled several responding intermediate hops “Destination unreachable.” Its IPv4 trace showed “Time exceeded” at intermediate hops and explicitly ended with “Traceroute completed.”

I don’t know whether this difference reflects the modem’s display of diagnostic results or actual differences in the probe responses. I’m including it as an observation, not as proof of where the fault lies.

Current workaround and request

Disabling IPv6 on the modem resolves the practical problem, but I would prefer to keep IPv6 enabled.

Could KPN investigate the intermittent resets during TLS connection establishment over IPv6 to Azure DevOps, and check whether this involves the Box 12 firmware or the network path to Microsoft?

The most repeatable finding is:

IPv6 enabled → failures return.
IPv6 disabled → Git works reliably.

Thank you.