Ahoy friends. Currently i'm using mwan3 again and unfortunately having massive trouble.
I got 2 WAN interfaces as well as WAN6 interfaces, each one with some IPv6 prefix from my ISP.
Unfortunately DNS resolving is terribly slow, and pinging google.com doesn't work at all.
According to ipv6-test.com IPv6 works fine. Currently i'm using the suggested NAT6 approach.
Is there any other way in order to get such a setup working fine with IPv6?
In theory there should be also a way to work with NETMAP, 6in4, maybe even LISP.
How about 6in4? Because IPv4 works really fine with mwan3, is this a considerable option?
I hope to find some suggestion, maybe someone has used 6in4 already or any other approach.
Currently it takes years in order to access webpages at all, so i'm looking forward to hear from you guys!
Thanks in advance!
As much as people hate it IPv6 masquerading makes things work with mwan3. I know of @luizluca who uses NETMAP with mwan3, so you aren't tied to NAT6, realistically NAT6 is often the final option when you don't have a prefix or a large enough prefix to delegate across a WAN interface.
I use NAT6 and mwan3 with many WAN connections which all have IPv6 and it works OK.
What version of mwan3 are you using? Your issue sounds like something I encountered on the newer 2.10 versions of mwan3, I however use 2.8.14 currently on 19.07 and it works much better in my setup. I will eventually debug why IPv6 doesn't seem to work so well on the newer version, but maybe you might be hitting the same issues I did, as I found IPv6 was working but often going to ipv6.google.com would timeout but then work for a brief period then fail again, it would be interesting if you are experiencing that same problem.
I would strongly recommend netmap, fixing the prefix when source address does not math the ISP. If IPv6 works natively, I would not try to use any transition protocol. Netmap will work even in a future without IPv4.
I advertise both isp prefixes, hoping for mptcp, but advertising only one prefix is simpler and it would work too. I do not recommend ULA->ISP prefix netmap because, even forcing ULA to be routable to internet, client OS will still use IPv4 before using an ULA IPv6 to access an internet service.
I have no issues with slow dns resolution, including google and from an internal recursive server. I'm using it t for about 900 simultaneous machines.
If ping is not working, something or everything is not working. Packets leaving the wrong interface will make half of connections fail, even if individual connections eventually work.
If you have a 50% chance of failing for each connection, and a browser does open many of them, it will looks like a terrible lag when, in fact, the browser is simply, after a timeout, trying again and again some connections until they works.
Wireshark is your friend. Capture each interface individualy. If you need to debug a packet leaving the wrong interface, I would recommend a TRACE target in ip6tables raw table
chairman@kali:~$ sudo ping google.de
PING google.de(fra15s16-in-x03.1e100.net (2a00:1450:4001:81b::2003)) 56 data bytes
From 2a02:908:236:fa80::1 (2a02:908:236:fa80::1) icmp_seq=1 Destination unreachable: No route
From 2a02:908:236:fa80::1 (2a02:908:236:fa80::1) icmp_seq=2 Destination unreachable: No route
From 2a02:908:236:fa80::1 (2a02:908:236:fa80::1) icmp_seq=3 Destination unreachable: No route
64 bytes from fra15s16-in-x03.1e100.net (2a00:1450:4001:81b::2003): icmp_seq=4 ttl=117 time=12.3 ms
64 bytes from fra15s16-in-x03.1e100.net (2a00:1450:4001:81b::2003): icmp_seq=5 ttl=117 time=10.6 ms
64 bytes from fra15s16-in-x03.1e100.net (2a00:1450:4001:81b::2003): icmp_seq=6 ttl=117 time=11.1 ms
64 bytes from fra15s16-in-x03.1e100.net (2a00:1450:4001:81b::2003): icmp_seq=7 ttl=117 time=12.0 ms
64 bytes from fra15s16-in-x03.1e100.net (2a00:1450:4001:81b::2003): icmp_seq=8 ttl=117 time=10.8 ms
64 bytes from fra15s16-in-x03.1e100.net (2a00:1450:4001:81b::2003): icmp_seq=9 ttl=117 time=10.5 ms
64 bytes from fra15s16-in-x03.1e100.net (2a00:1450:4001:81b::2003): icmp_seq=10 ttl=117 time=11.1 ms
64 bytes from fra15s16-in-x03.1e100.net (2a00:1450:4001:81b::2003): icmp_seq=11 ttl=117 time=16.9 ms
64 bytes from fra15s16-in-x03.1e100.net (2a00:1450:4001:81b::2003): icmp_seq=12 ttl=117 time=11.6 ms
64 bytes from fra15s16-in-x03.1e100.net (2a00:1450:4001:81b::2003): icmp_seq=13 ttl=117 time=10.6 ms
64 bytes from fra15s16-in-x03.1e100.net (2a00:1450:4001:81b::2003): icmp_seq=14 ttl=117 time=10.4 ms
64 bytes from fra15s16-in-x03.1e100.net (2a00:1450:4001:81b::2003): icmp_seq=15 ttl=117 time=10.5 ms
64 bytes from fra15s16-in-x03.1e100.net (2a00:1450:4001:81b::2003): icmp_seq=16 ttl=117 time=11.6 ms
64 bytes from fra15s16-in-x03.1e100.net (2a00:1450:4001:81b::2003): icmp_seq=17 ttl=117 time=10.4 ms
64 bytes from fra15s16-in-x03.1e100.net (2a00:1450:4001:81b::2003): icmp_seq=18 ttl=117 time=11.7 ms
64 bytes from fra15s16-in-x03.1e100.net (2a00:1450:4001:81b::2003): icmp_seq=19 ttl=117 time=15.9 ms
Pinging a target inside of my network.
chairman@kali:~$ sudo ping raspberrypi.lan
PING raspberrypi.lan(raspberrypi.lan (fdfb:9584:eb33::1fa)) 56 data bytes
From kali.lan (fdfb:9584:eb33::40f) icmp_seq=1 Destination unreachable: Address unreachable
From kali.lan (fdfb:9584:eb33::40f) icmp_seq=2 Destination unreachable: Address unreachable
From kali.lan (fdfb:9584:eb33::40f) icmp_seq=5 Destination unreachable: Address unreachable
From kali.lan (fdfb:9584:eb33::40f) icmp_seq=6 Destination unreachable: Address unreachable
I moved to another version of OpenWRT, at least DHCPv6 leases are working now.
I will check for the mwan3 version.
I will take a look onto NETMAP, but currently i am also trying a 6in4 and also a LISP approach, but being quite complicated to realise.
Unfortunately even with NAT6 i wasn't able to get a working IPv6 setup at all.
Just in theory, when IPv4 loadbalancing works fine, so IPv6 over IPv4 tunnel may work the same way?
Can someone suggest some OpenWrt version for a well working mwan3 version?
19.07.5 and mwan3 2.8.14 and 2.8.15 (soon to be available via opkg) should work. I personally have multiple IPv6 interfaces configured with NAT6 under this 19.07.5 and the snapshot builds have a specific kernel patch which resolves issues with some tunnel interfaces, that can effect mwan3 usage, so you ideally want to be running a build with the kernel patched.