Mark target not being used in routing decisions (firewall)

[cbz]

Hi -

In preparation for moving to 22.XX I'm moving all the rules I had in /etc/firewall.user on various routers to their equivalent in /etc/config files. On one router I have a wireguard VPN set up, with this routing table defined in network:

config route 'wg0_route'
        option interface 'wg0'
        option target '0.0.0.0'
        option netmask '0.0.0.0'
        option table 'wireguard0'

With the following rule set up:

config rule
        option in 'lan'
        option mark '0x64'
        option priority '100'
        option lookup 'wireguard0'

If I look in ip rule list I can see a rule against the mark being generated:

0:      from all lookup local
100:    from all fwmark 0x64 iif br-lan lookup wireguard0
32766:  from all lookup main
32767:  from all lookup default

I think so far everything is correct - for reasons I'll get into later.

I then have a rule in firewall:

config rule
        option name 'route ipset packets'
        option src 'lan'
        option ipset 'ipset'
        option target 'MARK'
        option set_mark '0x64'
        list proto 'all'

If I look at fw3 - this generates a rule that looks like this:

iptables -t mangle -A INPUT -i br-lan -m set --match-set ipset dst -m comment --comment "!fw3: route ipset packets" -j MARK --set-xmark 0x64/0xffffffff

This does not appear to affect routing at all. However, if I go back to the previous rule I had in /etc/firewall.user then it does work. The rule is shown here:

iptables -t mangle -A PREROUTING -m set --match-set ipset dst -j MARK --set-xmark 100

So the only difference is the chain of the mangle table in which this route is being added. If I look at reference material such as this one: https://erlerobotics.gitbooks.io/erle-robotics-introduction-to-linux-networking/content/security/img9/iptables.gif

It would seem that both the INPUT and PREROUTING chains are run before the routing decision in the output stage, but in this case the effect of the mark being done in INPUT instead is such that the routing decisions aren't affected - and the default table is being used instead.

(As a sidenote - in case people mention it, i'm also aware that I can't move this setup to 22 until the newer version of dnsmasq supporting nft style ipsets is in the release).

[dave14305]

Try setting the dst zone to any or *. That should put the rule in PREROUTING in fw3 (I think).

[cbz]

Thanks that seems to have worked - looking a the diagram more closely I can see that what I thought is a Routing decision on the output side, is really additional handling for NAT cases. Presumably your solution is alluded to in the manual when it says "If specified, the rule applies to forwarded traffic; otherwise, it is treated as input rule." against dest.