WAN6 had obtained an IPv6 address, but when pinging a public IPv6 address on OpenWrt, it immediately returned:
ping: sendto: Network unreachable
The cause turned out to be an unreachable rule with a mark that was consistent with mwan3. After deleting it, IPv6 connectivity was restored. This case demonstrates that seeing a default route does not mean actual traffic will necessarily use it.
This article documents an actual troubleshooting session. The public source address has been replaced with an example address used in the document; device names, rule priorities, and marks should be based on your own device. The uninstallation commands apply to OpenWrt installations that use opkg.
The default route exists, but the network is still unreachable
During the initial investigation, the default route was suspected to be missing, but the subsequent output already showed default routes with source-address conditions:
default from 2001:db8:1234:5600::4 via fe80::1 dev eth1 proto static metric 512 pref medium
default from 2001:db8:1234:5600::/64 via fe80::1 dev eth1 proto static metric 512 pref medium
A regular default route was also temporarily added during the investigation:
ip -6 route add default via fe80::1 dev eth1 metric 1024
However, ping still immediately returned Network unreachable. At this point, adding more default routes would no longer help; actual route selection and policy rules needed to be checked.
First confirm that the upstream gateway is reachable
ping -6 -I eth1 -c 3 fe80::1
All three requests received replies, indicating that link-local communication from OpenWrt to the upstream gateway was working. It is normal for IPv6 to use a link-local address beginning with fe80:: as the next hop; specifying the device here is to determine which link the address belongs to.
This step can only confirm that the gateway is reachable; it does not prove that the public Internet egress is working.
Route lookup succeeds, but packet transmission fails
ip -6 route get 2606:4700:4700::1111
Example output:
2606:4700:4700::1111 from :: via fe80::1 dev eth1 src 2001:db8:1234:5600::1234 metric 1024 pref medium
The egress interface, gateway, and source address had all been selected, but regular ping still failed. The same thing happened even after specifying the source address from the lookup result:
ping -6 -I 2001:db8:1234:5600::1234 -c 3 2606:4700:4700::1111
The source address above is only an anonymized example; actual testing must use a real address owned by the device.
Turning off sing-box did not eliminate the issue, so policy routing was checked next.
Key evidence: the unreachable rule
ip -6 rule show
Output on the affected system:
0: from all lookup local
2061: from all fwmark 0x3d00/0x3f00 blackhole
2062: from all fwmark 0x3e00/0x3f00 unreachable
32766: from all lookup main
The rule with priority 2062 means that traffic whose mark matches 0x3e00 under mask 0x3f00 is directly deemed unreachable. It is located before the lookup in the main table.
A regular ip -6 route get lookup does not specify a mark and does not run through the firewall marking process used when packets are actually sent. If actual traffic is marked on the output path, the subsequent route lookup may match this unreachable rule. This explains why the lookup appeared normal while ping failed immediately.
This rule was temporarily deleted on the affected system for verification:
ip -6 rule del pref 2062
ping -6 -c 3 2606:4700:4700::1111
Communication was restored after the deletion, confirming the rule’s direct relationship to this incident.
This set of rules matches the form of mwan3 rules. However, because the affected system did not retain the marking-chain counters or the complete mwan3 configuration, it cannot be asserted which specific interface probe or policy setting caused traffic to enter the unreachable branch. The mere presence of the rule does not mean that “having it causes a failure”; the key is why the traffic matches it.
Uninstall mwan3 when multiple WANs are not needed
If you still depend on multi-WAN traffic separation or failover, you should correct the mwan3 configuration. In this case, it was decided not to use it any longer. The following are the subsequent uninstallation steps; they are not presented as having already been executed.
First, back up the configuration:
[ ! -f /etc/config/mwan3 ] || cp -p /etc/config/mwan3 /root/mwan3.conf.bak
Stop the service and disable it from starting automatically:
if [ -x /etc/init.d/mwan3 ]; then
/etc/init.d/mwan3 stop
/etc/init.d/mwan3 disable
fi
Uninstall the installed packages one by one:
for pkg in luci-i18n-mwan3-zh-cn luci-app-mwan3 mwan3; do
if opkg list-installed "$pkg" | grep -q "^$pkg "; then
opkg remove "$pkg"
fi
done
If a dependency conflict occurs, first check the dependent package; do not use forced removal, and do not casually remove low-level dependencies that may be shared with other services.
Then check:
ip -6 rule show
ping -6 -c 3 2606:4700:4700::1111
If rules exactly identical to those in this article remain, delete them using the full conditions:
ip -6 rule del pref 2061 fwmark 0x3d00/0x3f00 blackhole
ip -6 rule del pref 2062 fwmark 0x3e00/0x3f00 unreachable
Skip a rule if it does not exist. Do not clear the entire policy routing table. Check again after rebooting at an appropriate time to make sure that no other startup scripts recreate the rules.
Clean up the temporary route
The default route with metric 1024 added during troubleshooting was not the verified root fix. After confirming that the automatic WAN6 default route exists:
ip -6 route show default
Delete the corresponding temporary route, then verify:
ip -6 route del default via fe80::1 dev eth1 metric 1024
ping -6 -c 3 2606:4700:4700::1111
If it fails again at this point, separately troubleshoot automatic routing and source-address selection. Do not assume that all other configurations are correct just because one problem has been found.
When encountering similar symptoms next time
For cases that immediately report Network unreachable, checking the local routing table and policy rules is more direct than starting to troubleshoot DNS or packet loss on the public Internet:
ip -6 route show default
ip -6 route get 2606:4700:4700::1111
ip -6 rule show
Having an IPv6 address on the WAN, obtaining a delegated prefix for use by the LAN, and having a usable default route are distinct states. This example further demonstrates that even when the regular default route is working, policy rules with a mark can still block actual traffic.