7.19 / 7.19.1 failure: SSL: handshake timed out

RouterOS General
1

I’ve had an RB5009 on 7.19 since its release and all of a sudden, last 30mins, it can no longer access https URL’s. I found out because the once per minute healthchecks.io check failed and generated alerts. I was using the new bundled CA root certs now included in 7.19 (I had deleted all my downloaded CA root certs that I was previously keeping updated via scheduled script).

I have tried on a different 7.19.1 device and it can run the /fetch command fine.

DNS resolution works, can ping internet IP’s etc.

I know there were some bugs with certificates in 7.19 that were resolved in 7.19.1 but I have upgraded this RB5009 to 7.19.1 and still can’t fetch on a https URL (it’s not only this URL):

[xxxx@RB5009] > :put [resolve hc-ping.com]
159.69.66.229
[xxxx@RB5009] > ping hc-ping.com
  SEQ HOST                                     SIZE TTL TIME       STATUS
    0 188.40.122.95                              56  40 291ms939us
    1 188.40.122.95                              56  40 291ms408us
    2 188.40.122.95                              56  40 291ms431us
    3 188.40.122.95                              56  40 292ms844us
    4 188.40.122.95                              56  40 291ms477us
    5 188.40.122.95                              56  40 291ms642us
    sent=6 received=6 packet-loss=0% min-rtt=291ms408us avg-rtt=291ms790us max-rtt=292ms844us

[xxxx@RB5009] > /tool fetch url="https://hc-ping.com/xxxx" output=none check-certificate=no
  status: failed
failure: SSL: handshake timed out (6)
[xxxx@RB5009] >
2

Not related to CA changes due to

check-certificate=no

Have you tried with some other URLs that are known to be working with cURL? There is high chance that this specific service has decided to implement some protections against AI and it resulted in MikroTik devices being blocked. The error provided is indicative of server ghosting client after initial TLS handshake request (which is enough to get JA3 fingerprint).

3

Thats what I assumed. Looking at other ISO related issues. Can ping, :resolve but can’t pass http/s traffic.

I don’t think this is rOS related now.

4

Someone on the /r/mikrotik Reddit group suggested disabling and re-enabling queues. I did and now it’s working again.

*EDIT - celebrated too early. Issue remains.

5

It seems to be an MTU issue:

[xxxx@RB5009] > /tool/ping address=159.69.66.229 do-not-fragment size=1478
  SEQ HOST                                     SIZE TTL TIME       STATUS
    0 159.69.66.229                            1478  44 296ms665us
    1 159.69.66.229                            1478  44 289ms365us
    2 159.69.66.229                            1478  44 298ms746us
    3 159.69.66.229                            1478  44 289ms161us
    sent=4 received=4 packet-loss=0% min-rtt=289ms161us avg-rtt=293ms484us max-rtt=298ms746us

[xxxx@RB5009] > /tool/ping address=159.69.66.229 do-not-fragment size=1479
  SEQ HOST                                     SIZE TTL TIME       STATUS
    0 159.69.66.229                                                timeout
    1 159.69.66.229                                                timeout
    2 159.69.66.229                                                timeout
    3 159.69.66.229                                                timeout
    sent=4 received=0 packet-loss=100%

This service has run at MTU 1500 for years. Tonight it stopped working. 1478 is the highest MTU I can go before the ICMP packet is fragmented.

ISP blaming us.

6

Might be something on the way between your router and the host. From my place, 1500-byte IP packets can still be sent to that host.
mtu-hc-ping.png

7

That’s just an arbitrary host. I believe this is an issue with our ISP.