From ArchWiki

Bad practice and redundant code

Sitting beside the nftables maintainer, asking for feedback.

This page's sample rulesets could use a good cleanup. I'll do that soon.

TCP flag checks are not necessary, because you can just check for whether the packet is in an invalid state, or just not whitelist:

/* table of valid flag combinations - PUSH, ECE and CWR are always valid */
static const u8 tcp_valid_flags[(TCPHDR_FIN|TCPHDR_SYN|TCPHDR_RST|TCPHDR_ACK|
                                 TCPHDR_URG) + 1] =
        [TCPHDR_SYN]                            = 1,
        [TCPHDR_SYN|TCPHDR_URG]                 = 1,
        [TCPHDR_SYN|TCPHDR_ACK]                 = 1,
        [TCPHDR_RST]                            = 1,
        [TCPHDR_RST|TCPHDR_ACK]                 = 1,
        [TCPHDR_FIN|TCPHDR_ACK]                 = 1,
        [TCPHDR_ACK]                            = 1,
        [TCPHDR_ACK|TCPHDR_URG]                 = 1,

ICMPv6 rate limiting like in the example is just stupid, for it breaks neighbour discovery (IPv6 ARP), ICMP isn't expensive to process, and it's not ICMP in of itself that is the problem. Anyhow, QoS is the job of the traffic control subsystem.

We probably should make not of kernel requirements for rulesets (e.g., 3.18+, so won't work with 3.14 linux-lts).

Maybe we should also provide guidance for getting upstream documentation, and troubleshooting. Attendance to netdev01 confirmed that it is in quite active development, and lots of usability features and fixes are in the pipeline.

Allowing all ICMP is not necessary, and is already handled by conntrack RELATED,ESTABLISHED. -- —This unsigned comment is by Alp (talk) 20:41, 17 February 2015‎ (UTC). Please sign your posts with ~~~~!Reply[reply]

Did you fix above issues? It is a long time and hard to check one by one. Or we could close this and open new topic for more specific section? --Fengchao (talk) 01:24, 14 February 2023 (UTC)Reply[reply]

syntax improvements

I noticed there is a request to add italics for pseudo variables. I am planning on doing that.

However, I would also want to rename some of those variables to make it even more apparent that they can be changed to whatever you want. For example, table inet filter I would change to table inet my_filter. Any objections?

Igo95862 (talk) 01:41, 18 January 2020 (UTC)Reply[reply]

No, absolutely no objections. Though, my personal preference would be to stick to filter respectively something which can be copy pasted without having to adapt it. In other words, a name which a sysadmin might reasonably choose on his or her system. IMHO this makes it easier for users who want to do exactly the thing that is described in the article and spares them from having to rename my_filter to something sensible. Edh (talk) 08:24, 18 January 2020 (UTC)Reply[reply]
I have no opinion on filter vs my_filter. My main concern is that pseudo-variables should not match the nft syntax keywords (see examples in the style template in nftables#top). -- nl6720 (talk) 10:09, 18 January 2020 (UTC)Reply[reply]
Exactly. filter is actually keyword in some statements. my_filter is not and probably never will be. Igo95862 (talk) 20:36, 18 January 2020 (UTC)Reply[reply]
Ok. I went over the page. Psedo variables are should be *_name or *_type. The examples use my_* naming scheme for non key word arguments. Igo95862 (talk) 23:37, 18 January 2020 (UTC)Reply[reply]
For those wondering, like myself: this section probably related to special:diff/603849. Which is probably related to special:diff/595487. I think the section here should now be deleted, since it was resolved. Other than filterName vs my_filter, aren't all comments in agreement? As an aside, other then differently emphasizing the keyword and the name, I think nft(8) is using exactly what claimed here to be confusing. Regid (talk) 12:42, 3 April 2020 (UTC)Reply[reply]

Imperative vs Declarative syntax.

nftables supports two types of syntax.

Imperative. Used in nft command, interactive mode and scripts:

nft add table family_type table_name

can also be in the file with shebang

#/usr/bin/nft -f
add table family_type table_name

Declerative. Only used in configuration:

table family_type table_name {

Right now the Configuration section only gives examples in the imperative syntax, however, Example section only show declarative syntax. What do you think about showing how to use declarative syntax in configuration alongside the nft commands? At the top of Configuration section will be the explanation when each syntax is used.

So the Create table section would look like this:

Create table

The following adds a new table at run-time:

# nft add table family_type table_name

Declaring table in configuration file:

table family_type table_name {

I also added some Accuracy templates in the areas I thought the examples in the article were not accurate. Tell me what you think of accuracy of those sections.

I agree, declarative syntax is much easier to understand, and translates directly to imperative syntax. I plan on writing a subsection on configuration explaining the differences and use cases of each before touching on the already existing subsections, but the configuration section needs some improvements for clarity as well. Ivanmlerner (talk) 17:28, 18 April 2020 (UTC)Reply[reply]

Not very simple firewall?

> The factual accuracy of this article or section is disputed.
> Tango-inaccurate.png
> Reason: This is not a very simple firewall. I would consider what Arch
> Linux ships in /etc/nftables.conf simple. Recommend replacing this
> section with that script and give some directions on how to expand it
> for specific needs. (Discuss in Talk:Nftables#)

Just My2cents. I'm a neophyte and I didn't have any problem following the instructions. I was briefly stuck after I changed my in my_something to something relevant to my host name (helps me later see pick-out what I create). In a few places I failed to replace a my_ reference and the command didn't work. So, I had a few minutes of grr.

I much prefer the step-by-step (interactive) pattern. Let's me review each line, together with instructions in earlier sections, to better understand what's doing what.

That said, I agree a simple default example you can just load and run is good. Rather than replacing the section, another option is just show the completed ruleset. That's what `nft list ruleset` does anyway, right? Anyone who wants to can copy and paste. Later, peeps can add tips for config and build on the same example.

Xtian (talk) 18:51, 1 January 2021 (UTC)Reply[reply]

Whether this is a 'simple firewall' or not isn't really the issue. The wiki has a long-standing page explaining how to use iptables to set up a 'simple stateful firewall'. I think it's important that something labelled a 'simple stateful firewall' here be functionally equivalent (if possible) to what's explained there. I don't think 'simple stateful' should be read as simply 'simple'. It's supposed to be a simple configuration of a particular kind. If the use of 'simple' here isn't acceptable, I think the wiki needs to use some other term for both pages and probably add something saying it used to be called 'simple stateful'. But, personally, I don't see the case for that kind of complication.

I'm not entirely clear whether this is better here or if it should be on the 'simple stateful firewall' page. It's a bit confusing that that page is all about iptables except for a link to this part of the nftables page. I don't know what the best way of resolving that is, but it means somebody looking to setup this kind of firewall is likely to do it with iptables if they just follow the wiki. (I have basically this setup but nftables wasn't a thing/was less of a thing when I followed those instructions.)

The simple stateful firewall page I really like precisely because it isn't a cut-and-paste-just-trust me. I think it would be a shame to lose that if nftables takes over. --cfr (talk) 18:44, 5 September 2022 (UTC)Reply[reply]

Also, I don't see anything in the comments here which justifies the factual-accuracy-disputed tag. If anything, the disagreement is over the name of the section or how to present the information. Nothing said here suggests the content of the section is factually inaccurate. The tag is alarmist in this context. When I see that tag, I assume I can't trust the content because it contains false, misleading or outdated information. But no reasons have been given to think that's true here.

If it is factually inaccurate, does that apply to simple stateful firewall too? --cfr (talk) 18:51, 5 September 2022 (UTC)Reply[reply]

How is it not simple? I've not even used nftables (or even iptables/ipchains) before (all my experience is with pf) and it makes sense to me. This is just about as simple as you can get. I'm removing the warning on this section since it's been more than two years since it was added and we're nowhere closer to a resolution (because, IMO, there is no issue here). Luna (talk) 23:28, 21 May 2023 (UTC)Reply[reply]

dnat/snat rules are not recognized

So for example this doesn't work because dnat is not recognized.

According to CONFIG_NFT_REDIR_IPV4 needs to be set in-order to access redirect ruleset which may explain this.

Sigmasd (talk) 10:20, 8 October 2021 (UTC)Reply[reply]

Working with Docker (clarifications)

This section is a little confusing to me, could someone help clarify the following points, and I can update the section accordingly:

1. "Adjust the 10.0.0.* IP addresses if they are not appropriate for your setup." Is this adjusted to the IP of the host interface, or the docker interface?

2. "Enable IP forwarding and set-up NAT for docker0 with the following postrouting rule" Does this mean create a new chain in my current table, like so?

table inet filter{
    chain postrouting {
        iifname docker0 oifname eth0 masquerade

3. "Now you can setup a firewall and port forwarding..." Isn't that what the rule above would do, or does this mean additional setup is required? In0ni (talk) 23:56, 14 October 2021 (UTC)Reply[reply]

I also don't understand what's exactly going on this section. It seems the drop-in file here creates a new dedicated network namespace for Docker, but I don't get this line especially.ExecStartPre=sh -c 'nsenter -t 1 -n -- ip link set docker0_ns netns "$$BASHPID" && true'
  • Why does only this line use sh instead of nsenter in other lines?
  • Why does it use $$BASHPID instead of $$ or $BASHPID?
  • What's the purpose of && true?
I also found this gist referenced with this page, and there are no tricks that I mentioned above. Would someone add a little more explanation in this section, or lead me to the right direction to learn more about nftables settings for Docker?
Ynakao (talk) 12:01, 18 November 2023 (UTC)Reply[reply]
Have just finished my own learning and troubleshooting about how to get this working.
One good source for the learning part:
Here is my whole working summary: the diffe22
One needs to understand the whole big picture first (and see the difference between main host, network namespace and docker "space"), to be able to answer any of these questions:
  1. the "10.0.0.*" is the inner subnet of the network namespaces, no need to change here anything
  2. see my working summary for example
  3. see my working summary for example
Logic clearly dictates that the needs of the many outweigh the needs of the few. (talk) 13:38, 19 November 2023 (UTC)Reply[reply]

Poor explanation

This paragraph makes no sense to me:

Chains have two types. A base chain is an entry point for packets from the networking stack, where a hook value is specified. A regular chain may be used as a jump target for better organization.

I don't know what an "entry point", a "hook value", or a "jump target" are in this context. Can somebody rewrite this assuming the audience isn't comprised of network experts? Chowbok (talk) 02:53, 23 February 2022 (UTC)Reply[reply]

QoS (Quality of Service)

The article does not mention how to build a basic QoS in a machine.--Xan (talk) 20:59, 14 July 2023 (UTC)Reply[reply]


The article mentions nftable official wiki but it does not mention in which file the nft will log traffic. On the other place, official site mention logd2 but it is not available in arch Xan (talk) 19:24, 12 October 2023 (UTC)Reply[reply]

nftables lives in the kernel so it logs to the kernel ring buffer which can be read with dmesg or journalctl. -- nl6720 (talk) 11:29, 13 October 2023 (UTC)Reply[reply]
But it does not log anything in my system. I have

       chain lanconn {
               tcp dport 22 accept comment "[nftables] Allow SSH from LAN"
               icmp type echo-request accept comment "[nftables] Allow unlimited pings from LAN"
       chain my_input {
               type filter hook input priority filter; policy drop;
               iifname "lo" accept comment "Accept anything from lo interface"
               ct state vmap { invalid : drop, established : accept, related : accept }
               icmp type echo-request limit rate 5/second accept comment "[nftables] Allow (but limit) pings from WLAN with rate less than 5/seconds"
               icmp type echo-request limit rate over 5/second drop comment "[nftables] Drop ping over limit of 5/seconds from WLAN"
               tcp dport { 80, 8443 } ct state new limit rate 10/second accept comment "[nftables] Allow HTTP/HTTPS traffic but limit them to 10 new connections per second"
               tcp dport 1965 accept comment "[nftables] Accept Gemini project protocol (without limits)"
               ip saddr jump lanconn
               ip saddr @badips drop comment "[nftables] Block ban IP"
               log prefix "[nftables log] " flags all
       chain my_forward {
               type filter hook forward priority filter; policy drop;
       chain my_output {
               type filter hook output priority filter; policy accept;

but no entry in dmesg appears.--Xan (talk) 18:58, 13 October 2023 (UTC)Reply[reply]