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.