They are. I have peerdns disabled and resolv conf ignored in dnsmasq, the default DNS lookup on the router would be itself 127.0.0.1, the DNS chain on the LAN is pushed through DHCP, but DNS works fine.
I haven't actually started using mwan3 for IPv6 yet, given the IPv6 routing table can at least handle that for now, WAN6 is the default, which works fine. I am currently looking to implementing IPv6 into the configuration, I can see the default config has IPv6 examples which I'll look at soon:
I don't understand though why some IPv6 domains/addresses return permission denied, while others don't. Would it suggest a routing problem somewhere?
I had the same issues more or less with mwan3.
Since I have a single wan6 I thought it wouldn't be necessary to configure it in mwan3, but I had erratic behaviour until I configured it properly.
You can test it with mwan3 disabled to verify.
Interesting you say that, as I have been doing some IPv6 related testing with mwan3 and it does seem to be causing issues in some cases, mainly it breaks connectivity with 6in4, although certain combinations of restarting the interface seem to bring it back.
My WAN6 is actually 6in4 from HE, I then have WAN2 which has both IPv4 and IPv6 but in order for IPv6 to work on WAN2 I need to have a virtual interface WAN2_6 which uses DHCPv6 to obtain a prefix, that also works with the exception of the weird sendto: permissioned denied errors only on some IPv6 request though, although that's specific to this interface, the 6in4 interface doesn't have those issues.
I'm a little confused about the mwan3 config though, the default rule uses 0.0.0.0/0 to me that's IPv4 address family only? Yet mwan3 seems to add a default ::/0 rule when looking at the mwan3 status output, even though no specific IPv6 rule is specified for this. I assume it's tied to the interface family value.
Maybe for now it would be better to disable any IPv6 members or interfaces so no default rule is added in MWAN3 and let the IPv6 routing table handle it.
Thanks for the tip. I'll look at implementing IPv6 into mwan3, it is something I was looking into, The default config isn't actually too far my setup with two WAN with v6 anyway. I'll see if it makes a difference.
Unfortunately, like other similar reports, it appears mwan3 is breaking 6in4 connectivity, if I disable it completely, everything is fine. The interface is configured in the config but is reporting as down according to the mwan3 status (because ping track_ip is failing). Although for a short period of time, the interface appear up.
Yeah sorry, I set an expiry to make sure I didn't leak my entire network config for all to see. I can re-post it again, if it would be helpful. Although I'm starting to think the original ping6 problem with the second WAN isn't related to mwan3 as it seems to happen regardless if the service is running or not.
I have this route configured to make sure the router uses the 6in4-wan6 interface as the default IPv6 gateway:
Likewise I also have to set a static IPv4 route to the HE.net IPv4 tunnel endpoint, as it seems with two WANs a static route to the HE tunnel endpoints gets created on the wrong WAN automatically, so by creating the static route this makes sure it goes through the right WAN, even though the route might be added to the second WAN.
If you remove all sensitive data like usernames, passwords, keys, mac there is nothing to leak and can serve as base configuration for others with the same problem.
The route6 is not necessary as you are getting the default gateway from both 6in4 and wan2_6. If you want to give priority to one of them, you can change the metric.
The route for he[.]net server is also pointless because with mwan3 alternative routing tables are used, so the main routing table is not looked up by default. What you need is a policy in mwan3 for the IP of he[.]net server.
Thanks, but it's still the same and no packets being received on that rule, so proto 41 doesn't seem to be marking it this far.
0 0 mwan3_policy_wan_only 41 -- * * 0.0.0.0/0 126.96.36.199 mark match 0x0/0x3f00 /* he_net *
Having another SSH connection open when restarting mwan3 I can see ping responses to the 6in4-wan6 interface happen very briefly I assume before the mwan3 routing/firewall rules are implemented and then it's dead. If stop mwan3 6in4-wan6 ping works.
Yes it is, highest rule. No traffic is hitting the rule at all, even when 6in4 is working. (I have to disable the wan6 interface and set the default rules to family ipv4 in mwan3 for that though). iptables shows no packets or bytes on the rule when it's active.
At this point I'm going to have to give up with trying to handle IPv6 through mwan3 and just live with it for now, works fine for IPv4, it will have to do. Perhaps it's better if wan6 was native IPv6, maybe less complexity here, but I'm not expert enough and I've been messing around with for the past few days.
I'll revisit it at some point, I've stared at too many config files lately, going crazy!
ping -I 2001:470:xxxxx:xx::2 -c 3 2001:4860:4860::8888
PING 2001:4860:4860::8888 (2001:4860:4860::8888) from 2001:470:xxxx:xx::2: 56 data bytes
64 bytes from 2001:4860:4860::8888: seq=0 ttl=58 time=37.825 ms
64 bytes from 2001:4860:4860::8888: seq=1 ttl=58 time=21.830 ms
64 bytes from 2001:4860:4860::8888: seq=2 ttl=58 time=20.996 ms
--- 2001:4860:4860::8888 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 20.996/26.883/37.825 ms
This leads back to the original issue issue with my other wan interface, OpenWrt does not seem to be able to correctly use the source address in some cases, hence the weird behaviour, that's what I've found anyway.
However, installing ping6 from iputils-ping6, pinging the interface name 6in4-wan6 works, but because mwan3 using ping and not ping6 even with the iputils-ping version, this just throws "ping: unknown host 2001:4860:4860::8888"