[PATCH firewall4] ruleset: add missing pre_* chains

[Florian Eckert]

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