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 ~~~~!

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)

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)
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)
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)
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)
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)

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)

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)

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)

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)

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)