nftables Conflict Help?

[harbinger27]

Hi all. My VPN app's killswitch appends to default nftables rules rather than remove / replace defaults when active / inactive. This creates redundancy and conflict when VPN rules are active since both default and VPN rules are marked "priority filter." I've tried to address this by making the default rules "priority +1" so that when the VPN killswitch is active, only VPN firewall rules are "priority filter," and when it's inactive, I still have basic drop rules in place for input and forward at "priority +1."

My expectation is that traffic will be dropped appropriately at the "priority filter" level when the VPN is active, but that when the VPN firewall rules are removed, the defaults will kick in, even though they are "priority +1."

Is this correct, or I have I poorly implemented this?

These are my default nftables rules without the VPN killswitch:

Code: Select all

table inet firewall {
	chain incoming {
		type filter hook input priority filter + 1; policy drop;
		iif "lo" accept
		iif "lo" ip saddr != 127.0.0.0/8 drop
		ct state established accept
	}

	chain forwarding {
		type filter hook forward priority filter + 1; policy drop;
	}
}

With the VPN kill switch on, the rules are as follows (I've edited them to highlight only the areas for potential conflict):

Code: Select all

table inet firewall {
	chain incoming {
		type filter hook input priority filter + 1; policy drop;
		iif "lo" accept
		iif "lo" ip saddr != 127.0.0.0/8 drop
		ct state established accept
	}

	chain forwarding {
		type filter hook forward priority filter + 1; policy drop;
	}
}
table inet vpn {
	chain prerouting {
		type filter hook prerouting priority -199; policy accept;
	}

	chain output {
		type filter hook output priority filter; policy drop;
		oif "lo" accept
		ct mark XXX accept
		[edit]
		udp dport 53 reject
		tcp dport 53 reject with tcp reset
		reject
	}

	chain input {
		type filter hook input priority filter; policy drop;
		iif "lo" accept
		[edit]
	}

	chain forward {
		type filter hook forward priority filter; policy drop;
		[edit]
		udp dport 53 reject
		tcp dport 53 reject with tcp reset
		reject
	}
}

Machine: Linux Mint 20.3 Cinnamon 64-bit
Networking: Forwarding is turned off in sysctl.conf (net.ipv4.ip_forward = 0)

[harbinger27]

Hi everyone - hope you're having a good weekend. Just thought I'd edit the above a bit for clarity and boost to see if anyone has thoughts on this nftables rule implementation. Thank you!

[Coggy]

According to these three docs:
- https://wiki.nftables.org/wiki-nftables ... lter_hooks
- https://wiki.nftables.org/wiki-nftables ... ing_chains
- https://wiki.nftables.org/wiki-nftables ... ithin_hook

If multiple chains attach to the same hook, packets traverse both (all) chains, the order being determined by the priority of the hook. Lower (more negative) priority first.

A drop verdict (or, I presume, a reject verdict) in a chain is terminal - the action is taken and packet processing stops there. Conversely, an accept verdict is not terminal - the packet processing skips the rest of the current chain and continues at the next chain.

The priority can be specified either numerically or by name, or by name-and-number which can be confusing. You really need to have that priority table.

Looking at your rules, both your non-vpn chains (input and forwarding) have priority of filter+1 which is numerically 1. I'm ignoring the [edit] lines.
The vpn prerouting chain (-199, accept) only accepts, so it can be ignored.
Both the input and output chains have priority filter (0).

For input traffic, packet will be processed by the vpn input chain (0) first, then if accepted, your input chain (1). Basically, drop all traffic except loopback from 127.0.0.0/8.

For output traffic, only the vpn output chain applies. I'm not sure about the ct (connection tracking) mark. I don't see where it is being set (if at all).

For forwarded traffic, both the vpn chain (0) and then yours (1) drop all traffic.

Hope this helps.

[harbinger27]

Thanks! It sounds like they should be working as intended without any conflicts. Appreciate the feedback