The resolv.conf and the other files in /tmp are indeed empty? Are you able to query them without packet loss or going out of the wrong interface?
The mwan3 configuration doesn't have any ipv6 configuration except the interfaces. I have in every policy a member of each address family and the default rule doesn't specify addresses.
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.
You can try that, but if I recall correctly that didn't make much of a difference for me.
The guideline of the example is what I use now and it works fine.
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.
Is there any policy to use the same interface for the he[.]net tunnel? (pastebin expired)
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:
config route6
option source '::'
option target '::/0'
option interface 'wan6'
config route
option interface 'wan'
option target '216.66.80.26'
option netmask '255.255.255.255'
option gateway '82.15.xx.x'
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 for the clarification on the routing tables.
So it sounds like I have been missing a potential critical rule for protocol 41 to work under mwan3. Something like this?
config rule 'he_net'
option proto 'all'
option dest_ip '216.66.80.26' # Adjust for other endpoints
option family 'ipv4'
option use_policy 'wan_only'
Thus forcing 6in4 to the correct WAN interface as one of the highest rules to ensure it doesn't get swallowed by anything else?
If I get this working, I'll post the full config information with sensitive info redacted to help others for sure!
Looks good, just verify in table mangle of iptables that it is not using tcp/udp.
Unfortunately, with that rule in place mwan3 still breaks 6in4, this was the rule generated based on the iptables mangle table:
0 0 mwan3_policy_wan_only all -- * * 0.0.0.0/0 216.66.80.26 mark match 0x0/0x3f00 /* he_net */
Interestingly though no bytes recorded, so it doesn't seem like the rule it being hit. Given the known problems I might just have to give up on trying to shape 6in4 with mwan3.
You need to change the protocol to 41.
Choose "Custom" in the drop down list and add 41 and press Enter.
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 216.66.80.26 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.
I hope it is higher in the bucket that other more generic policies.
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!
I came across another thread recently, which was identical to this:
I've found, adding this route, resolves the permission denied errors from ping6, traceroute6 etc on the wanb6 interface:
config route6
option interface 'wanb6'
option target '::/0'
Just for other people's benefit, I've also found I may be hitting this bug as well around my wan6 with 6in4:
The ping test from mwan3 will always fail because the wrong source address is being used.
Without the source address explicitly defined, the ping test does indeed fail:
ping -I 6in4-wan6 -c 3 2001:4860:4860::8888
PING 2001:4860:4860::8888 (2001:4860:4860::8888): 56 data bytes
^C
--- 2001:4860:4860::8888 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
With source address defined, works fine.
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"
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.