I am working with trial 7.9.1 on a Mini-ITX x86 box. This is to establish RouterOS full working IPv4/IPv6 before I purchase a Netgear appliance. (Motivated by impending EOL of my CIsco RV34x router) The Cisco’s IPv6 to this ISP worked fine the first time with a bog standard configuration - pretty much the same WAN DHCP-PD, LAN 64-bit prefix from WAN, and RA settings that routerOS accepted.
I arrived at the current RouterOS configuration by extensive use of online documentation. For example, the set of IPv6 firewall rules is the oft-repeated set of 21 or so that you see everywhere on this forum. IPv4 is working fine, it is only for IPv6 that I turn to the forum for help.
A lot of things work (though possibly the router must sit for a bit before they start to work). For example, ping and traceroute from the Winbox Tools work fine (Winbox1.jpg). The PC plugged into the router gets valid-looking IPv6 addresses (PC ipconfig to routerOS.jpg) and (remarkably) the PC does a working ping6 and a mostly working tracert (PC to routerOS.jpg).
So what doesn’t work? All IPv6 websites FAIL from the Chrome browser (e.g. ipv6.cybernode.com which works only with IPv6).
I’ve looked and looked at the configuration, addresses, routing table and so on - I’m at wit’s end to solve this. I have attached the output of the routerOS configuration export.
If anyone has some tips on what works or what to try, I would appreciate enormously. I would even love a configuration export of a fully working IPv6 routerOS setup. I’m willing to go through it line by line to see any differences with what I already have. config.txt (5.98 KB)
My best guess is that since your PC doesn’t have an IPv6 DNS server the browser retrieves IPv4 address (the type=A record) which exists but presumably is ignored by the server.
To verify that, you can statically configure IPv6 on your PC to use a public IPv6 DNS server, e.g. 2620:fe::fe
If what @Kentzo suggests is indeed true, then it’s doing of a particular application. Normal DNS servers, even if they only work on IPv4 (e.g. DNS server itself only has IPv4 connectivity), will happily return AAAA records if asked for them. So it’s up to application (and resolving library used) to ask for AAAA records and do something about them.
Can you try also using other browsers? E.g. use Firefox, which is truly independent of Chrome; edge would be fine as well, but it’s related to chrome and might experience similar problems if they are indeed introduced by browser itself.
Do you have a connection to the ISP with less than 1500 byte MTU? E.g. a PPPoE connection often has that problem.
If so, first try to fix that. Try to set 1500 byte MTU and MRU on the PPPoE interface and see if that remains after re-negotiation.
If so, your problem is probably fixed.
If not remove that again, and reduce the MTU in the IPv6 ND settings to the MTU you actually get from the ISP.
Some other routers do that automatically, but MikroTik does not do it and always advertises 1500 bytes unless you configure it differently.
You might want to try https://test-ipv6.com. It works both over IPv4 and IPv6 and can detect whether a browser prefers IPv4.
E.g. on my system Safari prefers IPv4 while Firefox prefers IPv6.
Thanks for all these responses. I believe that one way or another I have already tried everything mentioned except the MTU check.
nslookup and DNS records reveal IPv6 addresses returned as expected.
Firefox and Edge browsers behave the same as Chrome. test-ipv6.com just confirms what ipv6.cybernode.com reports.
I will take a look but odd MTU is unlikely since the Cisco RV34x router and other router software works normally.
Also, I have brought up OpenWRT and pfSense routers with full concurrent IPv4/IPv6 stacks, working browsers.
What I have done is prepared an entirely new configuration file, taken from the routerOS man pages and ensuring that I understand each and every line.
This hasn’t been tested yet (reset with “import” throws cryptic error messages either non-specific, or if they point to the line/column there is nothing there to see).
I have another small x86 box coming in a few days (a Barracuda F12) and I will try the new configuration on a fresh routerOS install there.
Lots of babble babble but not even a reply to my question, let alone an attempt to try a solution.
I wish you good luck! (but will not help you further)
pe1chl:
Sorry - although I did mention that I would take a look at the MTU issue.
Usually, I concentrate my testing (where I need to disconnect the house network from the ISP) on the weekend.
I wasn’t planning on trying out the MTU until then, but I will eventually report on the result . . .
MTU Path looks very handy.
I ran it just now, not through the routerOS development router, but through my production router - the ISP is the same though.
The results using an IPv4 target:
C:\Users\xxx\Downloads\MTU Path>mtupath 8.8.8.8
MTU path scan to 8.8.8.8, ttl=64, limit=48
16 processing - best MSS 1472 (estimated MTU 1500) [pPPPPpPppPpppppp]
01 nearest minimum MTU on local interface
#1 MSS IN RANGE 1 <== 1471 ==> 1472
#2 MSS EXCEEDED 1473 <== 14911 ==> 16384
Telnet to an IPv6 address of google.com (2607:f8b0:4005:813::200e for me) over port 80, then enter a couple of chars and press enter. If connection is successful telnet will print some HTML output and then close the connection.
SOLVED. Thanks to all for your suggestions.
Aside from trying those, I spent the weekend going over about everything on the web about getting IPv6 working on routerOS.
IPv4 / IPv6 is now running on a Barracuda F12 (x86) box.
This is using what I considered a minimum set of IPv6 firewall filter rules for functionality and basic safety.
Notably, I didn’t add all the IPv6 “bogon” firewall filter rules at this stage.
I figured I could fine tune the firewall rules once basic connectivity was established.
Are the IPv6 bogon rules important for a real-world router?
For the record, here is the IPv6 portion of the export config output (defaults, not shown, play an important role in allowing this to work):
Depends on how your Mikrotik is connected to upstream.
In my case the router is a straight SOHO gateway, with WAN connected to a reliable ISP.
I was thinking, the ISP would keep those Bogons off their link.
My main concern about “extra” filter rules is performance impact.
Is that a known issue, or am I worrying about nothing?
Rule order does matter. With the first rule (in each chain) accepting all packets members of accepted and related connections, the majority of packets are already dealt with (in normal case that is). In abnormal cases (e.g. when you’re victim of a DDoS attack) your router will suffer anyway, so a few additional rulees won’t make situation much worse (because it will already be really bad).
