IPv6 issues to some websites?

Forums › Vetta and Quic › IPv6 issues to some websites?

amanzi

Amanzi
1355 posts

Uber Geek
+1 received by user: 335

ID Verified

Trusted

Lifetime subscriber

#321569 29-Aug-2025 16:49

I'm only on my second day on Quic and have noticed some issues accessing sites over IPv6. I have a Mikrotik router and followed the advice in this forum to configure it, which seems to be working well. I see the "IPv6" badge on the Geekzone logo, and the test-ipv6.com site gives me a 10/10 score. So I think that all is OK on my side.

But today I noticed two sites that weren't working over IPv6:

Requests fail in Firefox or curl, and this is on multiple machines - macOS and Linux.

curl https://packages.microsoft.com
curl: (35) Recv failure: Connection reset by peer

If I change my IPv6 config on the clients from "auto" to "link-local only", the sites work fine.

Is this an issue on Quic or something to do with my IPv6 config?

This is a filtered page: currently showing replies marked as answers. Click here to see full discussion.

gregb

52 posts

Master Geek
+1 received by user: 13

#3408652 29-Aug-2025 18:08

The same URL 'works for me'. I'm not clear what the issue is; I would check you MTU. If something in your path is breaking ipv6 then path mtu discovery could be a possible explanation. I run a 1500 MTU (even over PPPoE) just to try and reduce these sort of issues. Historically for me path MTU problems start when the first full sized segments are send.

I don't think it is a DNS issue (your resolved ipv6 is the same - [2620:1ec:bdf::31]). I also find IPv6 on geekzone is pretty good (thumbs up to Mauricio), and getting that ipv6 logo is a really simple check for ipv6.

What ICMPv6 are you allowing? Are you filtering ICMPv6 and thus breaking IPv6?

$ curl -v6 https://packages.microsoft.com/
* About to connect() to packages.microsoft.com port 443 (#0)
* Trying 2620:1ec:bdf::31...
* Connected to packages.microsoft.com (2620:1ec:bdf::31) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate:
* subject: CN=packages.microsoft.com,O=Microsoft Corporation,L=Redmond,ST=WA,C=US
* start date: Jun 16 10:07:26 2025 GMT
* expire date: Dec 13 10:07:26 2025 GMT
* common name: packages.microsoft.com
* issuer: CN=Microsoft Azure RSA TLS Issuing CA 03,O=Microsoft Corporation,C=US
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: packages.microsoft.com
> Accept: /

https://account.quic.nz/refer/722087

amanzi

Amanzi
1355 posts

Uber Geek
+1 received by user: 335

ID Verified

Trusted

Lifetime subscriber

#3408669 29-Aug-2025 19:21

amanzi:

gregb:

I would check you MTU. If something in your path is breaking ipv6 then path mtu discovery could be a possible explanation. I run a 1500 MTU (even over PPPoE) just to try and reduce these sort of issues. Historically for me path MTU problems start when the first full sized segments are send.

Ah - interesting.... I haven't configured any specific MTU settings. I'll need to figure out how to do this on my Mikrotik router.

That was it! I set the max MTU and max MRU to 1508 on the PPP connection, and that got the router to use 1500 MTU. This is also mentioned in the Quic docs: https://www.quic.nz/setup/

Those sites are working now!