3

For example:

#!/usr/sbin/nft -f

add table ip filter_4


add chain ip filter_4 input {
    type filter hook input priority filter; policy drop;
}


add chain ip filter_4 new_in_4 {
    comment "New input IPv4 traffic"
}


Note it's goto not jump! (thus no way out of new_in_4 chain)


add rule ip filter_4 input ct state new goto new_in_4


Is this block drop or accept rule?


add rule ip filter_4 new_in_4 log prefix "some comment: "

The rule has no excplicit accept or drop verdict, so which is the default?

Giacomo1968
  • 58,727
metablaster
  • 296

1 Answers1

5

The rule has no excplicit accept or drop verdict, so which is the default?

None. A rule is not required to have a final verdict – if you don't specify one, then it doesn't have one. Packet processing will continue to the next rule.

If the packet reaches the end of a chain that you did goto to, then the result is as if it reached the end of the parent chain – in this case, the "input" chain has policy drop, so that will be applied.

(In other words, there is a way out of the new chain, just like there is a way out of the 'input' chain – the chain policy can be thought to be at the beginning of call stack and is the final place that you will "return" to. With 'jump' the stack would be policy > chain input > chain new_in_4, and with 'goto' it would be policy > chain new_in_4.)

The above is not unique to nftables; it's approximately the same in iptables (which also has both 'JUMP' and 'GOTO', chain policies, and rules without a final verdict).

nftables lets you see packet processing rule-by-rule – apply the rule nftrace set 1 to your packets (preferably as early as possible) and run nft monitor trace.

A more readable way to write your ruleset would be:

#!/usr/bin/nft -f

table ip filter4 {
    chain input {
        type filter hook input priority filter; policy drop;
        ct state new goto new_in_4
    }


chain new_in_4 {
    comment "New input IPv4 traffic"
    log prefix "some comment: "
}



}

Usually the opposite of chain new is done – the input chain would have a single rule to blanket accept established packets, then everything else would be "new" and you wouldn't need the second chain at all.

table ip filter4 {
    chain input {
        type filter hook input priority filter; policy drop;
        ct state established,related accept

    comment "New input IPv4 traffic"
    log prefix "some comment: "
}



}
grawity
  • 501,077