Connection error when trying to access Mikrotik’s websites over IPv6

[publio]

Hello everyone, I need your help to understand whether this issue is with my ISP or with Mikrotik’s websites.

When I try to access any *.mikrotik.com domain, I get a timeout during the SSL handshake.

❯ curl -v https://mikrotik.com/support/
* Host mikrotik.com:443 was resolved.
* IPv6: 2a02:610:7501:2000::205
* IPv4: 159.148.172.205
*   Trying [2a02:610:7501:2000::205]:443...
*   Trying 159.148.172.205:443...
* Connected to mikrotik.com (2a02:610:7501:2000::205) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /usr/lib/ssl/cert.pem
*  CApath: /usr/lib/ssl/certs
* SSL connection timeout
* closing connection #0
curl: (28) SSL connection timeout

I can ping the Mikrotik domains normally.

❯ mtr mikrotik.com --show-ips --aslookup --report-wide --mpls
Start: 2025-06-29T17:06:36-0300
HOST: daktor                                                     Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS18881  2804:[REDACT]                                       0.0%    10   54.2  41.7   2.1 115.7  36.5
  2. AS???    ???                                                100.0    10    0.0   0.0   0.0   0.0   0.0
  3. AS???    2001:12e0:500:c067:201:1:224:160                    0.0%    10   12.3  41.5   4.9  79.2  29.2
  4. AS???    2001:12e0:100:1017:a002:1028:a005:10                0.0%    10   75.3  33.8   4.9  75.3  28.0
  5. AS???    2001:12e0:100:1017:a001:1017:a002:20               90.0%    10    7.8   7.8   7.8   7.8   0.0
  6. AS12956  2001:1498:1:966:1::1721                            60.0%    10   87.4  71.8   9.5  95.3  41.6
  7. AS12956  2001:1498:1::100:145                               50.0%    10  214.1 155.8 126.9 214.1  33.6
  8. AS???    ???                                                100.0    10    0.0   0.0   0.0   0.0   0.0
  9. AS3356   lo0.0.edge8.Frankfurt1.level3.net (2001:4c08::8e)   0.0%    10  218.0 256.2 218.0 299.6  33.8
 10. AS3356   2001:1900:5:2:2::9a26                              50.0%    10  326.9 367.6 306.7 474.4  65.7
 11. AS???    ???                                                100.0    10    0.0   0.0   0.0   0.0   0.0
 12. AS???    ???                                                100.0    10    0.0   0.0   0.0   0.0   0.0
 13. AS???    ???                                                100.0    10    0.0   0.0   0.0   0.0   0.0
 14. AS51894  2a02:610:7501:2000::205                             0.0%    10  352.9 307.1 243.7 392.6  59.5

Some points:

• This error isn’t tied to my computer; it happens on every device.
• Forcing the connection over IPv4 works normally.
• Only Mikrotik domains appear to be affected.

When I try to access their sites, I just get a timeout.

[ID1]

All fine here. Something interfering your connection to mikrotik site.

[CGGXANNX]

If ping works, but HTTPS doesn’t, then one of the probable causes is a MTU issue / PMTUD issue. How are you connected to the internet? Does your ISP use PPPoE?

[rextended]

@ID1
the same

@CGGXANNX
Same thing I was thinking, a “fake” 1492 or pings stuck on the route…

[publio]

That’s exactly it! I created a rule changing it to 1432 and it started working.

[admin@MikroTik] > ipv6/firewall/mangle/print
Flags: X - disabled, I - invalid; D - dynamic 
 0    chain=forward action=change-mss new-mss=1432 passthrough=yes protocol=tcp tcp-flags=syn tcp-mss=!0-1432 log=no log-prefix="" 

What raised my doubts and what I’d like your help to understand is why only the Mikrotik domain was affected and why my ping tests, even when changing the packet size, didn’t show any problems.

My PPPoE Client:

[admin@MikroTik] /interface/pppoe-client> monitor VIVO-PPP duration=1s
               status: connected               
               uptime: 5h34m21s                
         active-links: 1                       
             encoding:                         
         service-name:                         
              ac-name: i-br-sp-spo-cvd-hl4-01  
               ac-mac: 74:E9:BF:A7:06:95       
                  mtu: 1492                    
                  mru: 1492                    
        local-address: 200.000.000.000         
       remote-address: 200.204.204.140         
   local-ipv6-address: fe80::12                
  remote-ipv6-address: fe80::76e9:bfff:fea7:695

[CGGXANNX]

Great! In that case you can try these two alternatives to the mangle rule, see this thread for an example:

One Website not accessible - RB5009

Because your WAN connection is using PPPoE which is point-to-point, the gateway is always the other peer, and you should neither accept router advertisements (keep the setting at “yes if forwarding disabled”), nor set “add default route” to “yes” for DHCPv6 Client. Set it to “no” and you’ll only have one default route with pppoe-WAN as gateway left. Your issue that only happens with one website might be MTU related. Because you are using PPPoE for your WAN and I don’t see max-mru=1500 max-mtu=1…

Ideal would be to be able to use MTU = 1500 with RFC 4638 from the ISP, by trying to set Max MRU = Max MTU = 1500 on the PPPoE client VIVO-PPP. Only if that’s not possible, try to announce the MTU value of 1492 with router advertisement instead.

Please note that if you currently only have one IPv6 → ND entry with the interface all then you can set the value directly there like in the linked post. Or you can create separate copies of the ND entry, one for each of your LAN/VLAN interface and set the value on them (then you can disable the default entry for the all interface).

If one of those alternatives can be applied, then you don’t need the mangle rule anymore (the mangle rule only helps TCP connections).

@publio

What raised my doubts and what I’d like your help to understand is why only the Mikrotik domain was affected and why my ping tests, even when changing the packet size, didn’t show any problems.

Did you specify the ping size up to the limit of the MTU 1500 packet? Under Windows the size parameter would be 1452 for example:

ping -l 1452 2001:4860:4860::884

As for the reason why it only happens with some sites:

Most of the websites with IPv6 support only send packets much smaller than the 1500-byte limit. You can read this old Cloudflare article describing the reason for that Fixing an old hack - why we are bumping the IPv6 MTU.

And normally, if Path MTU Discovery was fully working on the path between you and the remote host, then it wouldn’t be a problem neither. But for PMTUD to work, all the hops between you and the remote host must allow ICMPv6 forwarding.

So, the problem you experienced is probably a combination of the MikroTik server sending full size (1500 bytes) response packet and something on the way between you and that server blocking ICMPv6.

[nmt1900]

This problem seems to be resurfacing occasionally - and even if I lower MSS value it does not seem to help.

All other mikrotik.com sites are affected as well.

P. S. There are no problems with other websites/services over IPv6.

[DuctView]

Yes, all of Mikrotik, including forum has gone dead for me on ipv6 this evening and remains dead.

[CTassisF]

I’m also experiencing random connectivity problems when trying to access MikroTik web services using IPv6. Interestingly, these issues don’t happen consistently across all origins. For example, in Brazil, I can access cdn.mikrotik.com, upgrade.mikrotik.com and mikrotik.com over IPv6. However, from my server located in OVH, Canada, I’m unable to access MikroTik services in these hostnames using IPv6. These issues began yesterday, March 3, 2026, at approximately 3:20 PM UTC.

[nmt1900]

Mikrotik should understand that absence of IPv6 connectivity on web services is better than non-working IPv6 connectivity. This makes networking company look like amateurs…

[stevijo]

Can confirm the same issue. Reachable via mobile, but not from my server or residential ipv6.
The host itself is pingable from all of my hosts, but http requests just time out.
All my devices will not automatically fallback to ipv4 in this case and making the forum, help pages, website, etc unusable right now.

[dudleyrees]

I have exactly the same thing; IPv4 works fine, IPv6 doesn’t. All other IPv6 websites seem fine.
Problem started yesterday evening. Using a L009 and Quad9 as my DNS service.

[nmt1900]

This time it has nothing to do with MTU as same problem is occurring over multiple connections from different ISP’s - both fixed and mobile data connections.

[Christophe999]

Can confirm too, only happens to Mikrotik sites, and only over IPv6

curl -vvvv https://mikrotik.com            
* Host mikrotik.com:443 was resolved.
* IPv6: 2a02:610:7501:2000::205
* IPv4: 159.148.172.205
*   Trying [2a02:610:7501:2000::205]:443...
* Connected to mikrotik.com (2a02:610:7501:2000::205) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
^C

other IPv6 sites work fine

curl -vvvv https://ipv6test.google.com -6
* Host ipv6test.google.com:443 was resolved.
* IPv6: ::ffff:172.217.16.196
* IPv4: (none)
*   Trying [::ffff:172.217.16.196]:443...
* Connected to ipv6test.google.com (::ffff:172.217.16.196) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256 / [blank] / UNDEF
* ALPN: server accepted h2

I already had MSS set to 1440 on my RB5009.
I first noticed it yesterday evening around 19.00 CET.

[malobert]

Same problem as everybody else above, and it is getting annoying how long is takes to resolve.

I had to turn off ipv6 to post this…

[bschapendonk]

I’m having the same issue.

Using IPv4 works

 ~  curl -v -4 https://forum.mikrotik.com
* Host forum.mikrotik.com:443 was resolved.
* IPv6: (none)
* IPv4: 159.148.147.244
*   Trying 159.148.147.244:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* SSL Trust Anchors:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
*   CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / x25519 / id-ecPublicKey
* ALPN: server accepted h2
* Server certificate:
*   subject: CN=mikrotik.com
*   start date: Feb 26 04:36:27 2026 GMT
*   expire date: May 27 04:36:26 2026 GMT
*   issuer: C=US; O=Let's Encrypt; CN=E7
*   Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA384
*   Certificate level 1: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
*   subjectAltName: "forum.mikrotik.com" matches cert's "*.mikrotik.com"
* SSL certificate verified via OpenSSL.

Using IPv6 doens’t, just freezes before the TLS handshake.

~  curl -v -6 https://forum.mikrotik.com
* Host forum.mikrotik.com:443 was resolved.
* IPv6: 2a02:610:7501:3000::244
* IPv4: (none)
*   Trying [2a02:610:7501:3000::244]:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* SSL Trust Anchors:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
*   CApath: /etc/ssl/certs

It’s pingable over IPv4 and IPv6 and I checked the max v6 MTU and that also works, so it isn’t a MTU issue afaik.

My ISP gives me native IPv6 (no PPPOE or other shenanigans afaik), all other IPv6 sites I visit regulary have no issues.

I’m posting this using my corporate laptop which enforces “enterprise vpn“ aka IPv4 only (the irony).

[nmt1900]

All we know is all works completely OK for some users while not for others.

This thread tries to indicate being “solved” but I posted ticket to support and linked this thread to that.

[nmt1900]

It is either an accidental fluke or problem is finally solved

[~]$ curl -v6 https://mikrotik.com
* Host mikrotik.com:443 was resolved.
* IPv6: 2a02:610:7501:2000::205
* IPv4: (none)
*   Trying [2a02:610:7501:2000::205]:443...
* Connected to mikrotik.com (2a02:610:7501:2000::205) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256 / [blank] / UNDEF
* ALPN: server accepted h2
* Server certificate:
*  subject: jurisdictionCountryName=LV; businessCategory=Private Organization; serialNumber=40003286799; C=LV; L=Riga; O=SIA "Mikrotikls"; CN=mikrotik.com
*  start date: Jan  5 00:00:00 2026 GMT
*  expire date: Feb  5 23:59:59 2027 GMT
*  subjectAltName: host "mikrotik.com" matched cert's "mikrotik.com"
*  issuer: C=US; O=DigiCert Inc; CN=DigiCert EV RSA CA G2
*  SSL certificate verify ok.
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://mikrotik.com/
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: mikrotik.com]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: curl/8.7.1]
* [HTTP/2] [1] [accept: */*]
> GET / HTTP/2
> Host: mikrotik.com
> User-Agent: curl/8.7.1
> Accept: */*

[CGGXANNX]

@nmt1900

This thread tries to indicate being “solved”

That's because if you scroll up, you'll see that you've ressurected an 8-month-old thread :

And as we can see now, the current issue (some problem with IPv6 at MikroTik hosting provider / CDN) is not related to the issue of the OP (which was MTU issue), that the "solved" mark was set for.

[nmt1900]

Of course I understand that - but this is essentially the same problem. It looks like they finally caught on…