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
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
