Tunnel problems

[holgersson]

I've been using an IPv6 tunnel at home on a fiber optic/PPPoE connection. It's terminated by a Mikrotik RB450Gx4 router with latest stable firmware (6.45.7). It used to work fine, but now that I want to test a few services it doesn't work. I'm using the default Mikrotik template script the site is offering generated for my IP (see below) for the /64 subnet. Pings are working, but TCP connections are not working, or at least partially. MTU can't be a problem at 1280 bytes (it used to work up to 1460 on this connection). I don't understand why. The same configuration on different Mikrotik models work with the 2 other tunnels without issues. Both are in Prague, so I thought maybe there's some problem with The Budapest endpoint in some circumstances.

Some examples (on the router, RouterOS to exclude potential forwarding issues):

OK: /tool fetch url=http://ip6only.me/ keep-result=yes dst-path=aaa
not OK: /tool fetch url=https://ipv6.google.com/ keep-result=yes dst-path=aaa
not OK: /tool fetch url=https://xxxx:yyyy:zzzz:8214::c001/ keep-result=yes dst-path=aaa  # own server with native IPv6

The not OK ones simply time out.

Mikrotik ROS script:

Code Select Expand

/interface 6to4 add comment="Hurricane Electric IPv6 Tunnel Broker" disabled=no local-address=a.b.c.d mtu=1280 name=sit1 remote-address=216.66.87.14
/ipv6 route add comment="" disabled=no distance=1 dst-address=2000::/3 gateway=2001:470:xxxx:45::1 scope=30 target-scope=10
/ipv6 address add address=2001:470:xxxx:45::2/64 advertise=no disabled=no eui-64=no interface=sit1

Could you please help me diagnosing this. I suspect issues with the Budapest endpoint.

[kumowoon1025]

Can you do some more tests to see if ssl is the problem? also the url is not complete, I don't know if that's relevant, not too familiar with microtik. What is the tunnel server mtu set to? maybe packets sized 1400 are being dropped for example?? (On Cisco line card chassis types interface will tell you a different mtu each for tunnel, the tunnel encap pseudo-interface, ethernet, and all different values when you ask a specific processor instead of the supervisor. I'd do a sweep just to make sure that's not what's causing the issue, that the ssl handshake can't happen)

[holgersson]

Sorry, I didn't notice your reply as I forgot to turn on email notifications. The MTU is 1280. I did a tracepath MTU discovery and it also reports 1280 with an asymmetric return route, so no problems there. I teared down and rebuilt the tunnel multiple times to no avail.

---

New info: now while posting this reply, I decided to do some quick tests again after weeks of failure and testing IPv6 elsewhere where it worked. Without touching any of the related configs, sites that refused to work earlier now do work. Weird. I suspected an issue with the Budapest endpoint, it might have been fixed. I'll be testing more soon. Thanks for the help.