10

Interesting. Since I could not successfully run a “mwan3 start” command, I rebooted the router. I presume that this would restart the firewall as that is the configured state and manually stopping it should not be “remembered” across a reboot.

Comparing the “iptables -L -vv” output, I find that it is identical to the output of that command when I ran it after stopping the firewall.

Comparing to an earlier iptables listing, I can confirm that the ROUTE_POLICY rule is still gone. That rule earlier was:

Chain ROUTE_POLICY (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       all  --  br-lan any     anywhere             anywhere             mark match 0x40000/0x40000
  50M 4166M ACCEPT     all  --  br-lan any     anywhere             anywhere             mark match 0x80000/0x80000
    0     0 DROP       all  --  br-guest any     anywhere             anywhere             mark match 0x40000/0x40000
    0     0 ACCEPT     all  --  br-guest any     anywhere             anywhere             mark match 0x80000/0x80000

Could those -mark fields have been a leftover from some previous VPN routing policy which was once configured on that router, but is no longer used?

Of course, the ACCEPT/DROP selections - as displayed - don’t really route traffic, just filter them.

However, previous analysis of gl-iNet’s VPN policy routing implementation does use the ROUTE_POLICY table and mark sets with a value of 0x80000 and another value.

I am wondering if this was some remnant that was not removed and if subsequent “messing around” trying to solve this problem did not finally remove that iptable entry?