Subject says it all. I’m aware of this setting, but it’s global and affects all interfaces:
/ipv6/settings/set accept-router-advertisements
I need a hEX S to only accept RAs on the management interface, not on any others.
Cheers
Maurice
Subject says it all. I’m aware of this setting, but it’s global and affects all interfaces:
/ipv6/settings/set accept-router-advertisements
I need a hEX S to only accept RAs on the management interface, not on any others.
Cheers
Maurice
I think you can add a rule that block ICMPv6 message type 134 (RA) from interfaces other than the management interface. The rule must be above existing rules that accept ICMPv6 packets.
/ipv6 firewall filter
add action=drop chain=input icmp-options=134:0-255 in-interface-list=!MGMT protocol=icmpv6
MGMT is the list with the interfaces where RA is allowed.
Thanks @CGGXANNX, seems plausible. I tried that, but it has an unexpected side effect: It breaks IPv6 over LTE, which I configured like this:
/interface/lte/apn/set [ find default=yes ] add-default-route=no ipv6-interface=bridge1vlan8 use-peer-dns=no
When I add the firewall rule you suggested, IPv6 over LTE stops working entirely. bridge1vlan8 doesn’t get an IPv6 address anymore, and neither do any of the hosts in this VLAN.
It works if I exclude the lte1 interface from the firewall rule, but then a default route via LTE gets added automatically (which I don’t want and explicitly disabled in the APN settings).
What makes this even weirder: If I disable the firewall rule, but explicitly set accept-router-advertisements=no, IPv6 over LTE works just fine.
I think I’ll report this as a bug, unless it makes any sense to someone.
I have no experience with LTE interfaces and RouterOS. But it looks like the LTE interface doesn’t need accept-router-advertisements=yes to acquire the address, prefix and route information. PPPoE is also like that, it’s not required for the router to accept Router Advertisements with PPPoE to have working IPv6 (the route is the other end of the PPPoE connection, and prefixes & addresses are acquired by DHCPv6 clients). So maybe it works as intended? In the default configuration the router doesn’t accept RA either. The default setting value is “Yes if forwarding disabled”, and right above “IPv6 Forward” is on by default. Which means by default it acts as if accept-router-advertisements=no.
I understand. Then it all comes down to “accept-router-advertisements=yes” overriding “add-default-route=no” and “use-peer-dns=no”. This makes it impossible to use LTE without making it the systemwide default connection, while autoconfiguring a different interface with RAs. I now reported this as a bug, we’ll see.
Thanks for your input!
MikroTik support confirmed the LTE rogue default route bug and even provided me with an alpha firmware where it is already fixed.
I’m relatively new to MikroTik, but it has been a pretty good experience so far. Support seems to be way ahead of many competitors.
For standard Ethernet interfaces, your firewall workaround works fine. Problem solved!