Do you use NFTables or IPTables (or both) ?

Most major Linux distributions have adopted nftables as their default firewall framework, often using it under the hood for iptables commands. Here are some of the key distributions that support nftables:

  1. Debian: Starting with Debian Buster, nftables is the default backend for iptables.
  2. Ubuntu: From Ubuntu 20.10 (Groovy Gorilla) onwards, nftables is included and can be used as the default firewall framework.
  3. Fedora: Fedora has integrated nftables and uses it as the default firewall framework.
  4. Arch Linux: Arch Linux includes nftables and provides packages for easy installation and configuration.
  5. Red Hat Enterprise Linux (RHEL): RHEL 8 and later versions use nftables as the default packet filtering framework.

Let’s examine a fresh installed Ubuntu 24.04 LTS on an RPI:

What is iptables -V telling me ?

The system does not use the legacy iptables framework, instead it uses the nf_tables version of iptables which provides a bridge to the nftables infrastructure/framework.

to complete the knowledge we check the symbolic link of iptables:

Iptables-nft ruleset appears in the rule listing of nftables.

Is iptables-nft and nftables then the same ? No, but they share the infrastructure of nftables.

Here’s how they work together:

Compatibility Layer
iptables-nft: This is a variant of iptables that uses the nftables kernel API. When you use iptables commands, they are translated into nftables rules by this compatibility layer. This allows you to continue using familiar iptables commands while benefiting from the advanced features of nftables.
iptables-legacy: This is the traditional iptables that directly interacts with the kernel’s iptables API. If you use iptables-legacy, it operates independently of nftables and does not translate rules into nftables format.
Interaction
Rule Management: When you use iptables-nft, the rules you create are managed by nftables under the hood. This means that nftables takes precedence, and the rules are stored in the nftables ruleset.
Kernel API: Both iptables-nft and nftables use the same kernel API for packet filtering. This ensures that the packet matching and filtering behavior is consistent, regardless of which tool you use to create the rules.
Coexistence: If you use both iptables-legacy and nftables, they can coexist, but it’s generally recommended to stick with one framework to avoid conflicts and ensure consistency.

Best Practices

Transition to nftables: If you’re starting fresh or looking to modernize your firewall management, transitioning to nftables is recommended. It offers better performance, more features, and a simpler syntax.
Use iptables-nft: If you prefer using iptables commands, use the iptables-nft variant to take advantage of nftables’ capabilities while maintaining familiarity with iptables syntax.
By understanding how iptables and nftables interact, you can make informed decisions about managing your firewall rules and ensure a smooth transition to nftables.

Check out the official nftables wiki: http://wiki.nftables.org/

Ubuntu: remove ipv4-protocol from ethernet interface

On my Ubuntu-host I have my ethernet-interface connected to an mirror-port.
I want to remove the ipv4-protocol from this interface to avoid unnecessary traffic on this interface.

With root-rights execute “nmcli connection show –active”:

ugu5ma nmcli connection show --active
NAME             UUID                                  TYPE      DEVICE          
Fleischele2      8877f4c8-b38d-4028-a71d-b237d8ff649e  wifi      wlp3s0          
br-5bece4d6fbd8  3a34eddc-2c98-4140-9b40-74bcd355cde4  bridge    br-5bece4d6fbd8 
docker0          8de484ba-00e4-4130-b629-0037e3b00015  bridge    docker0         
enp6s0           57bc44f6-5190-42b2-b17f-e928868a42c0  ethernet  enp6s0 

my ethernet-interface (enp6s0) has UUID 57bc44f6-5190-42b2-b17f-e928868a42c0.

Let’s remove ipv4 :

ugu5ma nmcli connection modify 57bc44f6-5190-42b2-b17f-e928868a42c0 ipv4.method disabled

Check again:

➜  ugu5ma nmcli connection show --active                                                   
NAME         UUID                                  TYPE  DEVICE 
Fleischele2  8877f4c8-b38d-4028-a71d-b237d8ff649e  wifi  wlp3s0 

done!

Pi-hole: send pihole.log and pihole-FTL.log to external Syslog-server

The option to send Pihole-logs to a remote syslogserver is not implemented.
Good thing is that Pi-hole creates log-files.
How about adding these logfiles to the local (R-)Syslog-daemon and send it over to the external Syslog-Server via port 514 TCP/UDP ?

I use Dietpi as the OS on my Raspi3+ and added Pi-hole as one of the supported apps .

Dietpi has per default noSyslog-daemon activated.
The first step is to install a Syslog-daemon, in my case Rsyslog.
Install with root-privileges (sudo su):

apt install rsyslog

cd to /etc/rsyslog.d and create two files:

nano pihole.conf

$InputFileName /var/log/pihole.log
$InputFileTag pihole
$InputRunFileMonitor
$InputFilePersistStateInterval 1000
nano piholeftl.conf

$InputFileName /var/log/pihole-FTL.log
$InputFileTag pihole-ftl
$InputRunFileMonitor
$InputFilePersistStateInterval 1000

as next alter rsyslog.conf and add the following lines

nano /etc/rsyslog.conf

$ModLoad imfile
$InputFileName /var/log/pihole.log
$InputFileName /var/log/pihole-FTL.log
*.* @10.50.100.5:514

10.50.100.5 is the external Syslog-Server. Dietpi sends now the syslog-information to the Syslog-Server 10.50.100.5 via TCP port 514.
Change the IP 10.50.100.5 to the Syslog-Server IP you want to use.

restart Rsyslog-daemon:

systemctl restart rsyslog

The Syslog-daemon receives now the Pi-hole logs:

Addition: If you want to see also the DNS-queries go to Settings and Enable query logging:

This brings also the DNS content to the external Syslog-Server:

May 14 09:58:27 DietPi local0 pihole May 14 09:58:26 dnsmasq[15529]: query[A] bier.de from 10.50.100.13
May 14 09:58:27 DietPi local0 pihole May 14 09:58:26 dnsmasq[15529]: forwarded bier.de to 1.0.0.1
May 14 09:58:27 DietPi local0 pihole May 14 09:58:26 dnsmasq[15529]: dnssec-query[DS] bier.de to 1.0.0.1
May 14 09:58:27 DietPi local0 pihole May 14 09:58:26 dnsmasq[15529]: reply bier.de is no DS
May 14 09:58:27 DietPi local0 pihole May 14 09:58:26 dnsmasq[15529]: reply bier.de is 212.53.128.75
May 14 09:58:27 DietPi local0 pihole May 14 09:58:26 dnsmasq[15529]: query[AAAA] bier.de from 10.50.100.13
May 14 09:58:27 DietPi local0 pihole May 14 09:58:26 dnsmasq[15529]: forwarded bier.de to 1.0.0.1
May 14 09:58:27 DietPi local0 pihole May 14 09:58:26 dnsmasq[15529]: reply bier.de is NODATA-IPv6

Done!

Keep a remote X11 app running after disconnecting the Session

Xpra is the tool of choice 🙂
Install xpra on server and client like:

[code language=”bash”]

root@h2545526:~# apt install xpra
.
.
xpra (2.1.3+dfsg-1ubuntu1) wird eingerichtet …

[/code]

start e.g. firefox on the server:
[code language=”bash”]
xpra start :100 –start-child=firefox
[/code]

now connect from remote through Ssh:
[code language=”bash”]
xpra attach ssh/user@serverFQDN/100
[/code]

With xpra firefox remains active on the server even when the client disconnects 🙂

Big advantage for e.g. large downloads.