Mwan3 feedback on IPv6 and missing features

Community Builds, Projects & Packages
22

Probably worth updating, IPv6 only interfaces should work better with mwan3 2.8.4 onwards. Changes to the mwan3track side made more recently mean that the track_ip tests are performed with the IPv6 source address obtained from the interface. This is more reliable than using the interface name as OpenWrt seems to have issues with selecting the right source address in some cases.

There are a few documented cases of this being a problem in certain scenarios.

This behaviour is also present when using the built in busybox ping utils vs the iputils-ping or iputils-ping6 tools as an example. You can get different outcomes from ping tests with the same commands across both tools (when using interface names). However if you specify the source address explicitly everything is fine.

This should improve compatibility with 6in4 and IPv6 only interfaces generally.

23

Try this

config rule ipv6_update
option dest_ip 64.62.200.2 #ipv4.tunnelbroker.net
option use_policy wan_only

config rule ipv6_server
option dest_ip 216.66.87.102 #tunnel server ip
option use_policy wan_only

You may need port forward p41 or dmz

24

I want to "+1" @reinerotto's request, because I want to build an image with no IPv6 to save space, but that breaks mwan3 which requires ip6tables. I can fix it by manually painstakingly removing all references to ip6tables in the scripts, but that is not an optimal solution...

25

Hello @feckert ,
thank you for this great piece of software. It works perfectly with IPv4 but getting it to work with IPv6 is giving me a headache.
I have two dual stack connections, one is fast and high ping and one is slow but low ping. I want to route Port 80 and 443 via the fast connection, so I'm able to stream video over it and everything else via the slow low ping line. I tried the same rules like for IPv4, but that results in a loss of IPv6 connectivity for port 80 and 443.
Is there a way to get this working somehow? I know that IPv6 multihoming does exist, but that does work only for IPs and not ports as far as I understand.
I'm running OpenWRT 20.204 and 2.8.8-1.0
Thank you for any help and information.

26

Have you followed the general IPv6 guidance with mwan3 here:

https://openwrt.org/docs/guide-user/network/wan/multiwan/mwan3#mwan3_and_ipv6

The support for IPv6 should be better in 2.8.8 and newer versions thanks to various changes by @aaronjg, but there are still known issues and quirks, some which have been hacked around in mwan3 itself.

I have can confirm I have a working dual stack IPv6 configuration working on the 19.07 branch. I can't comment on 20.x, the kernel is different between these two branches. Have you tried your configuration on the latest stable release to ensure it's not something related to this. There was another case of someone unable to have Wireguard work correctly with mwan3 and it seems to be something different in the 5.x kernel with snapshot builds compared to the 4.14.x release the stable branch is currently.

1 Like
27

Yes i have followed it. Basic Setup does work but as soon as you do advanced rules IPv6 stops working.

28

Can you try version 2.8.11, there was some changes between 2.8.8 and 2.8.11 that might help.

Can you post your mwan3 config and rule that isn't working?

30

It is not visible from your output. However preparing the wan interfaces with metrics on the default route is the first step before configuring mwan3.

31

The default route warning might be a bit of red herring to be honest. I'm not sure the LuCI interface is as aware of IPv6 parameters than it could be. I have this error on all of my IPv6 interfaces, but they work OK.

Metrics is definitely one of the first things to look at though.

32

That are the settings i have done in /etc/config/network
in my mind I have set a metric with that

config interface 'wan6'
option ifname 'eth2'
option proto 'dhcpv6'
option reqprefix 'auto'
option iface_dslite '0'
option reqaddress 'force'
option metric '10'

config interface 'wanb6'
option ifname 'pppoe-wanb'
option proto 'dhcpv6'
option reqaddress 'try'
option reqprefix 'auto'
option metric '20'

config interface 'wan'
option proto 'dhcp'
option ifname 'eth2'
option metric '11'

config interface 'wanb'
option ifname 'lan4'
option proto 'pppoe'
option password 'xxx'
option username 'xxx'
option ipv6 '1'
option metric '21'

Or is something else to do to set it properly?

33

I would prefer the ifname @wanb, but otherwise it looks fine.

34

I think it is solved.
The update to 2.8.12 was good.
I had to remove the ::/0 default rule and for https the 0.0.0.0/0 target. Now it seems to work, but needs around 5 mins after a reboot of the router until the routes are sorted out, in that time IPv6 doesn't work at all even though there are allready 2 prefixes attached to the LAN.
Thank you @jamesmacwhite and @trendy for you help.

1 Like
35

There was a change to the default config recently here:

Technically it has been wrong for a while, however opkg will not update your config if it's been modified so you might need to update it to be in line with the default rules here.

Maybe double check you are in sync and retry.

1 Like
36

Hello,
i have the problem that my wanb6 goes red after around 15 seconds. Sadly i haven't noticed that for a long time, so don't know since when this happens. Ping does work over that interface, does somebody have a clue how to debug what is going wrong there?

Thanks for help

37

Which mwan3 version?

38

Version 2.8.15-1

39

Which openwrt 19.07 version do you have 19.07.5 19.07.6, there was a bug fixed in the kernel. i removed the hack for openwrt-19.07. But there are problems if someone has an older base version than 19.07.6.

40
Firmware Version TurrisOS 5.1.8 11f4918ebb32f658e419225ef218f82d66b482cc / LuCI branch git-21.022.31068-7129723
Kernel Version 4.14.216
41

I'm having issues with default routes that get lost.

mwan3 is configured to remove the source address selector when copying the routes from the main table to the interface specific ones. This works as it intended.

When routes from the main table are removed, the same happens: The source address selectors is removed and this adjusted route is removed from the interface specific tables. This works, too.

The problem occurs when the main routing table contains multiple different routes that are equal after removing the source address selector. Then, removing one of them from the main table deletes the derived routes from all of them from the interface specific tables.

If this happens with the default route, then the interface specific tables contain no default route and all internet traffic that should use this interface is not forwarded anymore.

And yes, this happens with the default route for me. When my IPv6 address changes, new routes are added and some old default routes are removed some time later.

I'm using the following workaround now: modify /usr/sbin/mwan3rtmon; between route_line=... and handle_route, add the following:

if [ "$action" = "del" ]; then
	if mwan3_get_routes | grep -qxF "$route_line"; then
		LOG debug "deleted but route still exists - $route_line"
		return
	fi
fi

This does not correctly update the list of connected networks, but it's only a workaround.

However, I think that this is very inefficient with calling mwan3_get_routes. I think that it would be simpler to use ip monitor just as a trigger to regenerate the interface specific tables - or use it as a trigger for a complete regeneration in case of a removed route that has a source address selector.