On 01.02.2025 11:30, Berto Furth wrote:
I went ahead and loaded your listed configuration into my /etc/nftables.conf file.
I got an error when I tried to load your configuration and as such IP traffic was allowed because there were essentially no nftables rules operating.
The lines that generated an error were as follows..
# nft -c -f /etc/nftables.conf
/etc/nftables.conf:27:26-40: Error: invalid priority expression value in this context.
type nat hook input priority dstnat; policy drop;
^^^^^^^^^^^^^^^
/etc/nftables.conf:41:27-41: Error: invalid priority expression value in this context.
type nat hook output priority srcnat; policy drop;
^^^^^^^^^^^^^^^
However when I replaced "dstnat" with "-100" and "srcnat" with "100" the nftables filers were accepted and IPv4 traffic to the unit stopped.
You are completely right. I must have messed up something. The ruleset that I have posted now causes the same errors at my side, and the only solution is to replace "dstnat" and "srcnat" by their numerical values as you have shown.
However, this clearly contradicts the documentation. The link below refers to table in the netfilter wiki which lists nft keywords (names) for priorities. "dstnat" and "srcnat" clearly are among them. So either the documentation is correct and our nft versions are too old, or the documentation is wrong.
https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks#Priority_within_hook
Sadly, it seems that I not only have messed up the syntax, but have made further mistakes, because I cannot reproduce the problem any more. With your changes applied, everything works as expected. That is, policy drop in an otherwise empty chain indeed is equivalent to having an explicit drop verdict for all packets in that chain.
Thank you very much for your help. I'd like to apologize for having wasted your time.
Best regards,
Binarus
The diffs between what I used and what you posted are as follows
*** /etc/nftables.conf.binarus 2025-02-01 21:25:46.418090954 +1100
--- /etc/nftables.conf 2025-02-01 21:25:22.198057049 +1100
***************
*** 24,30 ****
}
chain input-nat {
! type nat hook input priority dstnat; policy drop;
log prefix "ip4-input-nat:" drop;
}
chain input-filter {
--- 24,30 ----
}
chain input-nat {
! type nat hook input priority -100; policy drop;
log prefix "ip4-input-nat:" drop;
}
chain input-filter {
***************
*** 38,44 ****
}
chain output-nat {
! type nat hook output priority srcnat; policy drop;
log prefix "ip4-output-nat:" drop;
}
chain output-filter {
--- 38,44 ----
}
chain output-nat {
! type nat hook output priority 100; policy drop;
log prefix "ip4-output-nat:" drop;
}
chain output-filter {
I hope that helps.
Berto.
On Fri, 31 Jan 2025, at 06:35, Binarus wrote:
Dear experts,
this is a cross posting, see
https://unix.stackexchange.com/questions/789174/netfilter-not-dropping-packets-as-it-should.
Since I didn't get an answer there for a couple of weeks, I am
repeating the question here in the hope that the problem can easily be
reproduced. For me this is a very important key point in understanding
netfilter / nftables.
Please consider the ruleset that's at the end of this post. It doesn't
make any sense, but it lets everybody reproduce the problem easily.
With this ruleset, all IPv4 packets that come in via enp0s3 are
accepted in the ingress hook, but finally traverse a chain with a drop
policy. Each of these chains does not contain any explicit rule besides
the drop policy, and thus should behave as it would (only) contain an
explicit drop verdict for all packets.
Hence, applications on that machine should not see any IPv4 packets
that originate from other machines.
But they definitely do. For example, I have an SSH daemon running on
that machine. The daemon listens on an IPv4 address only (in fact, I
have disabled IPv6 on that machine completely by adding ipv6.disable=1
to the kernel command line). Even after I have loaded the ruleset
below, I can connect to the SSH daemon via IPv4 from the outside
without any issue.
Can somebody please explain why the rules below don't make the kernel
drop all incoming IPv4 packets? Did I misunderstand the purpose of the
drop policy?
Thank you very much in advance, and best regards,
Binarus
table netdev t_NETDEV_enp0s3 {
chain enp0s3-ingress-filter {
type filter hook ingress device "enp0s3" priority filter; policy drop;
ether type 0x0806 arp ptype 0x0800 accept
ether type 0x0800 accept
log prefix "foo: " drop
}
}
table ip t_IP {
chain prerouting-nat {
type nat hook prerouting priority dstnat; policy drop;
log prefix "ip4-prerouting-nat:" drop;
}
chain prerouting-filter {
type filter hook prerouting priority filter; policy drop;
log prefix "ip4-prerouting-filter:" drop;
}
chain input-nat {
type nat hook input priority dstnat; policy drop;
log prefix "ip4-input-nat:" drop;
}
chain input-filter {
type filter hook input priority filter; policy drop;
log prefix "ip4-input-filter:" drop;
}
chain forward-filter {
type filter hook forward priority filter; policy drop;
log prefix "ip4-forward-filter:" drop;
}
chain output-nat {
type nat hook output priority srcnat; policy drop;
log prefix "ip4-output-nat:" drop;
}
chain output-filter {
type filter hook output priority filter; policy drop;
log prefix "ip4-output-filter:" drop;
}
chain output-route {
type route hook output priority mangle; policy drop;
log prefix "ip4-output-route:" drop;
}
chain postrouting-nat {
type nat hook postrouting priority srcnat; policy drop;
log prefix "ip4-postrouting-nat:" drop;
}
chain postrouting-filter {
type filter hook postrouting priority filter; policy drop;
log prefix "ip4-postrouting-filter:" drop;
}
}
