[firewall4] ruleset: add missing pre_* chains

There is the option to add a user change, but if the rule applies, the
fw4 rules are still processed. This is because these chains are
top-level chains that only have a different priority.

This priority indicates whether they are processed before or after the
fw4 chains.

So that rules can also be processed in the context of the fw4 and are
not passed on to the next toplevel chain in the event of an apply. The
rule must be processed in the context of the fw4 tables. This commit
adds a pre chain for input, output and forward.

Firewall rules, that are not handeled by the fw4  can then be hooked into
this, which are then processed in the context of the fw4 and are thus
allowed through by the fw4 in the event of an accept.

Signed-off-by: Florian Eckert <fe@dev.tdt.de>
(cherry picked from commit 596f9f7973560210a8ccf386d7017aaa07ea77d2)
---
 root/usr/share/firewall4/templates/ruleset.uc | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

Hi,

can't you do the same by dropping a snippet into /etc/nftables.d/ which simply
registers chain with lower priority hooks? In fact there already is an example
[1].

So in order to achieve what you want, create an
`/etc/nftables.d/10-pre-chains.nft with the following contents:

-- 8< --
chain pre_input {
  type filter hook input priority -1; policy accept;
}

chain pre_forward {
  type filter hook forward priority -1; policy accept;
}

chain pre_output {
  type filter hook output priority -1; policy accept;
}
-- >8 --


Since nftables makes it easy to have many hooks, I doubt that such a generic,
mostly unused facility is needed at all. If your package/process/use case
requires staging custom rules before the default ones, drop a partial into
/etc/nftables.d/ which declares own chains with lower priority hooks along
with the rules you need.

~ Jo


1:
https://git.openwrt.org/?p=project/firewall4.git;a=blob;f=root/etc/nftables.d/10-custom-filter-chains.nft;h=4cb421308f2f8b084add77fc51f8430596d83abf;hb=b2682251a173103490a4a2556fb87e4df1d627b3#l8

Hi,


> can't you do the same by dropping a snippet into /etc/nftables.d/ which 
> simply
> registers chain with lower priority hooks? In fact there already is an 
> example
> [1].

Specifically, it's about the firewall rules that the strongswan sets 
with the updown plugin on a connection SA up/down.
Currently, the iptables or ip6tables command is used on updown.
By using nft with fw4, iptables-nft or ip6tables-nft is now used 
trancperently used.
Currently strongswan updown is broken when using fw4 with 
iptables-nft/ip6tables-nft
So I rewrite the updown script to use native nft instead of 
iptables-nft/ip6tables-nft.


> So in order to achieve what you want, create an
> `/etc/nftables.d/10-pre-chains.nft with the following contents:
> 
> -- 8< --
> chain pre_input {
>   type filter hook input priority -1; policy accept;
> }
> 
> chain pre_forward {
>   type filter hook forward priority -1; policy accept;
> }
> 
> chain pre_output {
>   type filter hook output priority -1; policy accept;
> }
> -- >8 --

I have already seen that and I have also tried it and put my rules for 
my task in separate toplevel chains as you suggest.
But this does not work as expected. The packages are recognized by my 
new chain with a less priority.
However, they are then discarded by the next chain with a higher 
priority of fw4.

> Since nftables makes it easy to have many hooks, I doubt that such a 
> generic,
> mostly unused facility is needed at all. If your package/process/use 
> case
> requires staging custom rules before the default ones, drop a partial 
> into
> /etc/nftables.d/ which declares own chains with lower priority hooks 
> along
> with the rules you need.

Rules for strongswan in seperate chains with lower priority (not 
working):
         chain s_pre_input {
                 type filter hook input priority filter - 1; policy 
accept;
                 iifname "eth0" meta ipsec exists ipsec in reqid 1 ip 
saddr 192.168.17.0/24 ip daddr 192.168.99.0/24 accept comment 
"!strongswan: reqid in 1 input"
         }

         chain s_pre_forward {
                 type filter hook forward priority filter - 1; policy 
accept;
                 iifname "eth0" meta ipsec exists ipsec in reqid 1 ip 
saddr 192.168.17.0/24 ip daddr 192.168.99.0/24 accept comment 
"!strongswan: reqid in 1 forward"
                 oifname "eth0" meta ipsec exists ipsec out reqid 1 ip 
saddr 192.168.99.0/24 ip daddr 192.168.17.0/24 accept comment 
"!strongswan: reqid out 1 forward"
         }

         chain s_pre_output {
                 type filter hook output priority filter - 1; policy 
accept;
                 oifname "eth0" ipsec out reqid 1 ip saddr 
192.168.99.0/24 ip daddr 192.168.17.0/24 accept comment "!strongswan: 
reqid out 1 output"
         }

         chain s_pre_srcnat {
                 type nat hook postrouting priority srcnat - 1; policy 
accept;
                 ip saddr 192.168.99.0/24 ip daddr 192.168.17.0/24 accept 
comment "!strongswan: reqid none 1 srcnat"
         }

Rules for strongswan in a pre chain with a jump (working):

         chain pre_input {
                 iifname "eth0" meta ipsec exists ipsec in reqid 1 ip 
saddr 192.168.17.0/24 ip daddr 192.168.99.0/24 accept comment 
"!strongswan: reqid in 1 input"
         }

         chain input {
                 type filter hook input priority filter; policy drop;
                 iifname "lo" accept comment "!fw4: Accept traffic from 
loopback"
                 jump pre_input
                 ct state established,related accept comment "!fw4: Allow 
inbound established and related flows"
                 tcp flags syn / fin,syn,rst,ack jump syn_flood comment 
"!fw4: Rate limit TCP syn packets"
                 iifname "eth1" jump input_lan comment "!fw4: Handle lan 
IPv4/IPv6 input traffic"
                 iifname "eth0" jump input_wan comment "!fw4: Handle wan 
IPv4/IPv6 input traffic"
                 jump handle_reject
         }

         chain pre_forward {
                 iifname "eth0" meta ipsec exists ipsec in reqid 1 ip 
saddr 192.168.17.0/24 ip daddr 192.168.99.0/24 accept comment 
"!strongswan: reqid in 1 forward"
                 oifname "eth0" meta ipsec exists ipsec out reqid 1 ip 
saddr 192.168.99.0/24 ip daddr 192.168.17.0/24 accept comment 
"!strongswan: reqid out 1 forward"
         }

         chain forward {
                 type filter hook forward priority filter; policy drop;
                 jump pre_forward
                 ct state established,related accept comment "!fw4: Allow 
forwarded established and related flows"
                 iifname "eth1" jump forward_lan comment "!fw4: Handle 
lan IPv4/IPv6 forward traffic"
                 iifname "eth0" jump forward_wan comment "!fw4: Handle 
wan IPv4/IPv6 forward traffic"
                 jump handle_reject
         }

         chain pre_output {
                 oifname "eth0" ipsec out reqid 1 ip saddr 
192.168.99.0/24 ip daddr 192.168.17.0/24 accept comment "!strongswan: 
reqid out 1 output"
         }

         chain pre_srcnat {
                 ip saddr 192.168.99.0/24 ip daddr 192.168.17.0/24 accept 
comment "!strongswan: reqid none 1 srcnat"
         }

         chain srcnat {
                 type nat hook postrouting priority srcnat; policy 
accept;
                 jump pre_srcnat
                 oifname "eth0" jump srcnat_wan comment "!fw4: Handle wan 
IPv4/IPv6 srcnat traffic"
         }



I'm not sure yet. But I suspect that if a package in a chain with a 
lower priority is recognized as accepted,
it will simply be passed on to the next chain with a higher priority.
And this is then the filter chain fw4, where the package is dropped.
Because no rules matches.

I have not found anything in the documentation of nftables.
But if I put the rules in a pre_* chain with a jump then the strongswan 
works with nft and if I put the rules with a lower priority in a 
separate toplevel chain without a jump then it doesn't work.

In order for this to work with ipsec and nft, the kernel module 
kmod-nft-xfrm must be built [1].

Best regards

Florian

[1] https://github.com/openwrt/openwrt/pull/9909

Hello Jo-Philipp

I found the following summary that describes my problem. See my link 
[1].
And why me need this pre_* hooks in fw4 as I suggested.

I have found the following description about priority and accept.
This is the paragraph:

Base chain priority:

Each nftables base chain is assigned a priority that defines its 
ordering among other base chains, flowtables, and Netfilter internal 
operations at the same hook. For example, a chain on the prerouting hook 
with priority -300 will be placed before connection tracking operations.

NOTE: If a packet is accepted and there is another chain, bearing the 
same hook type and with a later priority, then the packet will 
subsequently traverse this other chain. Hence, an accept verdict - be it 
by way of a rule or the default chain policy - isn't necessarily final. 
However, the same is not true of packets that are subjected to a drop 
verdict. Instead, drops take immediate effect, with no further rules or 
chains being evaluated.

 From my point of view it makes sense to add my changes in fw4, otherwise 
it won't work.
When I read it like this then your suggestion does not work?



Kind regards

Florian

[1] 
https://wiki.nftables.org/wiki-nftables/index.php/Configuring_chains#Base_chain_types