4

I'm running a Debian Linux server.

I need to open some firewall ports; usually this is easy as pie with iptables, but this server is running nftables.

When I open the conf file, it's not showing rules:

cx:/etc# cat nftables.conf 

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
        chain input {
                type filter hook input priority 0;
        }

        chain forward {
                type filter hook forward priority 0;
        }
        chain output {
                type filter hook output priority 0;

But if I list the rules, I can see them:

:/etc# nft list ruleset
table inet filter {
        chain input {
                jump phonesystem
        }

        chain phonesystem {
                ip daddr 224.0.1.75 counter packets 0 bytes 0 accept
                tcp dport { http, https, sip, sip-tls, 5062, 5090 } ct state new counter packets 0 bytes 0 accept
                udp dport { sip, 5090, 7000-10999 } counter packets 0 bytes 0 accept
        }
}
table ip filter {
        chain INPUT {
                meta l4proto tcp tcp dport 22 counter packets 0 bytes 0 accept
                jump phonesystem
        }

        chain phonesystem {
                ip daddr 224.0.1.75 counter packets 0 bytes 0 accept
                tcp dport { http, https, sip, sip-tls, 5062, 5090 } ct state new counter packets 0 bytes 0 accept
                udp dport { sip, 5090, 7000-10999 } counter packets 0 bytes 0 accept
        }

        chain FORWARD {
                type filter hook forward priority 0; policy accept;
        }

        chain OUTPUT {
                type filter hook output priority 0; policy accept;
                meta l4proto tcp tcp dport 22 counter packets 0 bytes 0 accept
        }
}
table ip6 filter {
        chain INPUT {
                jump phonesystem
        }

        chain phonesystem {
                tcp dport { http, https, sip, sip-tls, 5062, 5090 } ct state new counter packets 0 bytes 0 accept
                udp dport { sip, 5090, 7000-10999 } counter packets 0 bytes 0 accept
        }

        chain FORWARD {
                type filter hook forward priority 0; policy accept;
        }

        chain OUTPUT {
                type filter hook output priority 0; policy accept;
        }
}
table ip security {
        chain INPUT {
                type filter hook input priority 150; policy accept;
        }

        chain FORWARD {
                type filter hook forward priority 150; policy accept;
        }

        chain OUTPUT {
                type filter hook output priority 150; policy accept;
        }

Now I want to open, for example, port 4001.

I have tried numerous commands to the IP Table and the chain phonesystem, but I always get a syntax error. Curious where I am going wrong here!

e.g.

:/etc# nft add rule ip filter input tcp dport 4001 accept
Error: Could not process rule: No such file or directory
add rule ip filter input tcp dport 4001 accept

or

:/etc# nft add rule ip phonesystem tcp dport 4001 counter accept
Error: syntax error, unexpected tcp, expecting string
add rule ip phonesystem tcp dport 4001 counter accept

If I wanted to open a few more ports, how exactly would I add this to the phonesystem chain?

1
  • For the record, although not directly related to your question(s), your tables seem broken, as except ip security, the others do not have hook input base chains. Besides, if their policies (when they exist) are accept (and there's not an "ultimate" drop rule), you have nothing to "open additionally" since everything is open.
    – Tom Yan
    Apr 5, 2022 at 8:35

1 Answer 1

2

Your system by default uses iptables-nft rather than iptables-legacy:

Starting with Debian Buster, nf_tables is the default backend when using iptables, by means of the iptables-nft layer (i.e, using iptables syntax with the nf_tables kernel subsystem). This also affects ip6tables, arptables and ebtables.

The tool configuring iptables is thus using iptables-nft rather than iptables-legacy. So it is visible by nftables too. The same happens for ip6tables.

So what nft list ruleset actually displays is the inet family (dual IPv4+IPv6) defined natively by nftables through /etc/nftables.conf and the result of iptables commands done by an other configuration or tool.

You should not alter rules in the ip filter INPUT/OUTPUT/FORWARD chains etc. or iptables might fail later when not being able to translate back from the nftables compatibility API for iptables. Likewise, nft might not be able to decode all of iptables' chains, because they might still use untranslatable iptables matches or targets. That's not the case in the current ruleset (or lines with comments (#) would be displayed sometimes).

It still appears that ip filter INPUT (and also ip6 filter INPUT as well as inet filter input) was damaged somehow (there also has to be a wrong cut/paste in the question somewhere, the duplication of the chain phonesystem looks dubious), because it's not displayed as a base chain but as a user/regular chain: it should have begun with type filter hook input priority 0; policy accept; making it a base chain that hooks using Netfilter in the packet path. Without this no input filtering will happen here. Or if that was a cut/paste error, this prevents to know if the default input policy was to drop packets (else why would it be needed to accept them?) which affects my recommendations at the end.

To answer the question. You made each time a syntax error: either the wrong chain name, which is case sensitive, or missing the table name which is mandatory. Commands that would have worked, but then would have derailed further use of iptables commands would have been:

nft add rule ip filter INPUT tcp dport 4001 accept
nft add rule ip filter phonesystem tcp dport 4001 counter accept

Anyway don't do that.

Use iptables-save to display the ruleset in iptables format, and use iptables as usual to alter rules since it was created using iptables (as systematically seeing a counter rule hints):

iptables -A INPUT -p tcp --dport 4001 -j ACCEPT
iptables -A phonesystem -p tcp --dport 4001 -j ACCEPT

You're free to add rules in the inet filter table, since there will be no conflict of use. Or you can just create your own table to suit your needs as long as its name won't clash with iptables (-over nft API):

For example:

nft add table ip myowntable
nft add chain ip myowntable mycustominput '{ type filter hook input priority 10; policy accept; }'

Be aware that there are interactions. When a packet is dropped in a chain, it stays dropped forever. When a packet is accepted in a chain (eg: ip filter INPUT) it can still be dropped in a chain hooking in the same hook/type (eg: inet filter input or ip myowntable mycustominput). So this makes sense:

dropping packets won't be reverted:

nft add rule ip myowntable mycustominput tcp dport 5555 drop

but below won't help (accepting it in ip myowntable mycustominput won't prevent it to be dropped elsewhere before by other rules in ip filter INPUT):

nft add rule ip myowntable mycustominput tcp dport 4001 accept

Conclusion: if an other tool on the system is using iptables, keep using iptables or switch this tool to nftables first. Using both at the same time with cause you more troubles. If you need to use both, here are some additional related Q/A where I made an answer to help for this (hint: packet marks are probably needed):

1
  • 1
    So the 2 examples above "don't do that" is the actual answer without the gobbledygook
    – Roland
    Jan 13 at 0:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .