All of lore.kernel.org
 help / color / mirror / Atom feed
* nftables: priority handling for changes on the same table
@ 2022-05-17 14:22 Florian Eckert
  2022-05-17 15:07 ` Kamil Jońca
  0 siblings, 1 reply; 2+ messages in thread
From: Florian Eckert @ 2022-05-17 14:22 UTC (permalink / raw)
  To: netfilter

Hallo Community

OpenWrt has recently switched to nftables for the new release 
openwrt-22.03 [1].
For this purpose, a new firewall service fw4 was created, which 
generates the rules for the nft and loads them into the kernel [2].

Since I am a package manager at openwrt I have a question regarding 
nftables.
I am in the process of making the strongswan and other packages mwan3 
fit for nftables because up now a lot of stuff is not working proper 
with fw4(nftables)
It works with iptables-nft and ip6tables-nft.

My problem now is that the strongswan iptables rules are set when a 
tunnel is up or down via the _updown script.
I wanted to port this to nft now.
To use the script approach with "nft rule add ..." seems to work, but 
deleting them is poor, because I have to search for the handle first.


Is there no other option here?
I have also tried to create my own chain "strongswan_filter_pre_forward" 
before the openwrt fw4 table chain "forward",
but somehow this does not not working as expected!

Not working:
root@G3-10483 ~ # nft list ruleset
table inet fw4 {
     ...
     chain strongswan_filter_pre_forward {
         type filter hook forward priority filter - 2; 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
         oifname "eth0" meta ipsec exists ipsec out reqid 1 ip saddr 
192.168.99.0/24 ip daddr 192.168.17.0/24 accept
     }
     ...
     chain forward {
         type filter hook forward priority filter; policy drop;
         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
     }
     ...
}
Working:
root@G3-10483 ~ # nft list ruleset
table inet fw4 {
     ...
     chain forward {
         type filter hook forward priority filter; policy drop;
         iifname "eth0" meta ipsec exists ipsec in reqid 1 ip saddr 
192.168.17.0/24 ip daddr 192.168.99.0/24 accept
         oifname "eth0" meta ipsec exists ipsec out reqid 1 ip saddr 
192.168.99.0/24 ip daddr 192.168.17.0/24 accept
         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
     }
     ...
}

I have specially lowered the 'priority' of the chain 
"strongswan_filter_pre_forward" by two so that it runs before the 
'forward' chain.

Is it possible that my approach is wrong and it doesn't work like this? 
I have not found anything in the documentation about that.

Kind regards
Florian

[1] https://github.com/openwrt/openwrt/tree/openwrt-22.03
[2] https://git.openwrt.org/?p=project/firewall4.git;a=summary

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: nftables: priority handling for changes on the same table
  2022-05-17 14:22 nftables: priority handling for changes on the same table Florian Eckert
@ 2022-05-17 15:07 ` Kamil Jońca
  0 siblings, 0 replies; 2+ messages in thread
From: Kamil Jońca @ 2022-05-17 15:07 UTC (permalink / raw)
  To: netfilter

Florian Eckert <fe@dev.tdt.de> writes:


>
> Not working:
> root@G3-10483 ~ # nft list ruleset
> table inet fw4 {
>     ...
>     chain strongswan_filter_pre_forward {
>         type filter hook forward priority filter - 2; 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
>         oifname "eth0" meta ipsec exists ipsec out reqid 1 ip saddr
>         192.168.99.0/24 ip daddr 192.168.17.0/24 accept
>     }
>     ...
>     chain forward {
>         type filter hook forward priority filter; policy drop;
>         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
>     }
>     ...
> }
> Working:
> root@G3-10483 ~ # nft list ruleset
> table inet fw4 {
>     ...
>     chain forward {
>         type filter hook forward priority filter; policy drop;
>         iifname "eth0" meta ipsec exists ipsec in reqid 1 ip saddr
>         192.168.17.0/24 ip daddr 192.168.99.0/24 accept
>         oifname "eth0" meta ipsec exists ipsec out reqid 1 ip saddr
>         192.168.99.0/24 ip daddr 192.168.17.0/24 accept
>         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
>     }
>     ...
> }
>
> I have specially lowered the 'priority' of the chain
> "strongswan_filter_pre_forward" by two so that it runs before the 
> 'forward' chain.
>
> Is it possible that my approach is wrong and it doesn't work like
> this? I have not found anything in the documentation about that.

Correct me if I am wrong but but "accept" in
strongswan_filter_pre_forward causes pass packet to normal forward
chain (where packet is dropped I believe)

If you want to keep "multpile chain" approach then I think the best way
is to "mark" packet (instead of "accept") in
strongswan_filter_pre_forward  and then in "forward"chain
- accept marked packets.


You can also wait for next release
(https://marc.info/?l=netfilter&m=165031449504497&w=2)
this release should have more set/map/vmap possiblities
and then should be possible to use something like (I know that this is
not the best example, but I am olso in migration process)

--8<---------------cut here---------------start------------->8---
add chain ip filter ipsec-fw-${PLUTO_REQID} \;\
add rule ip filter ipsec-fw-${PLUTO_REQID} iif ${PLUTO_INTERFACE} ipsec in reqid ${PLUTO_REQID}  ip saddr ${PLUTO_PEER_CLIENT} ip daddr ${PLUTO_MY_CLIENT} accept \;\
add rule ip filter ipsec-fw-${PLUTO_REQID} oif ${PLUTO_INTERFACE} ipsec out reqid ${PLUTO_REQID}  ip saddr ${PLUTO_MY_CLIENT} ip daddr ${PLUTO_PEER_CLIENT} accept \;\
add element ip filter ipsec_fw '{' ${PLUTO_REQID}  : jump ipsec-fw-${PLUTO_REQID} '}'\;\
--8<---------------cut here---------------end--------------->8---


where static config would  be:

map ipsec_fw {
typeof ipsec in reqid : verdict
flags interval
}

chain FORWARD {
                type filter hook forward priority filter; policy drop;
[...]
ct state established,related accept
ipsec out reqid vmap @ipsec_fw
ipsec in reqid vmap @ipsec_fw
}


I compiled modified sources and this works (in a way ;) )

KJ


-- 
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2022-05-17 15:07 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-05-17 14:22 nftables: priority handling for changes on the same table Florian Eckert
2022-05-17 15:07 ` Kamil Jońca

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.