# Warning: iptables-legacy tables present, use iptables-legacy-save to see them

I’m getting these messages hourly on buster for the last 3 or 4 days …

Cron root@xxx [ -x /usr/sbin/sympl-firewall ] && /usr/sbin/sympl-firewall

Warning: iptables-legacy tables present, use iptables-legacy-save to see them

Generated by iptables-save v1.8.2 on Mon Aug 12 19:07:09 2019

*filter
:INPUT ACCEPT [364123:48122619]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [716596:95613731]
COMMIT

Completed on Mon Aug 12 19:07:09 2019

I didn’t see @smsm1 earlier post, which looks like is related …

1 Like

Yep, it’s related. I’ll have a fix for this ASAP with an updated package for Sympl on Buster.

1 Like

Now fixed in buster-testing, and will be pushed though to stable. At the start of next week.

1 Like

Great and thank you.

I see that I am on stretch-testing right now.

What’s the sanest way to switch back to sympl-stable btw without breaking things? Or would it be an idea just to move everything over to buster?

No problem!

It sounds like you may have done a dist-upgrade from Debian Stretch to Debian Buster, but not updated Sympl at the same time?

Either way, if you run the Sympl installer without the --testing switch, it will swap you to the stable branch for the Debian version you’re running, which will then only take the relevant updates.

1 Like

Running the installer again seems to work fine, although I did wonder that I had read that right and gave it a try on another machine just to see.

It does ask for the sympl user passwd to be set/reset.

Good point, I’ve updated the installer so it runs without prompting for a new password if you already have a sympl user.

I’ve since deleted the machine that gave this problem. Now on a freshly created instance over the weekend, the sympl firewall is nagging hourly …

Warning: iptables-legacy tables present, use iptables-legacy-save to see them

It is running Buster on a DO vm, if that helps …

I’m wondering if the fix has moved from buster-testing to production?

It hadn’t until earlier today as I wanted to be as sure as possible it didn’t break anything, but is in the stable branch now.

@aye_philip If you run sympl update, it should fix it.

2 Likes

@Kelduum Great, it worked - eventually. When I ran the update yesterday it bombed then hung, broke the terminal sess. Unfortunately my notes, recall and the history got mangled so I can’t reproduce exactly, but here is where it failed at first in the event it says anything useful, Paul. Suffice to say it looks like it is all working, despite my efforts to break it. Thanks again.


Recommended packages:
sympl-phpmyadmin
The following packages will be upgraded:
sympl-backup sympl-core sympl-firewall sympl-mail sympl-mysql
5 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.


Unpacking sympl-firewall (10.0.190816.0) over (10.0.190718.0) …
Preparing to unpack …/sympl-mysql_10.0.190731.0_all.deb …
I: Skipping removal.
W: /etc/mysql/my.cnf is not linked to either my.cnf.dpkg-sympl or my.cnf.dpkg-sympl-orig
Not removing diversion of /etc/mysql/my.cnf by sympl-mysql
Unpacking sympl-mysql (10.0.190731.0) over (10.0.190621.0) …
Setting up sympl-core (10.0.190908.0) …
I: Enabling dynamic MOTD
/usr/bin/sympl: line 175: 11555 Killed sudo apt-get -q -y install --only-upgrade ‘sympl-*’

A long time later…

from the logs:
Warning: iptables-legacy tables present, use iptables-legacy to see them

$ sudo iptables-legacy -L
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

$ sympl update
Reading package lists…
Building dependency tree…
Reading state information…
sympl-backup is already the newest version (11.20210818.1).
sympl-core is already the newest version (11.20220426.0).
sympl-cron is already the newest version (11.20220322.1).
sympl-dns is already the newest version (11.20210818.1).
sympl-firewall is already the newest version (11.20220719.0).
sympl-ftp is already the newest version (11.20210818.1).
sympl-mail is already the newest version (11.20220929.0).
sympl-monit is already the newest version (11.20210818.1).
sympl-mysql is already the newest version (11.20210818.1).
sympl-phpmyadmin is already the newest version (11.20210818.1).
sympl-updater is already the newest version (11.20210818.1).
sympl-web is already the newest version (11.20220406.0).
sympl-webmail is already the newest version (11.20220322.0).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Is there a fix?

Have you been using nftables, or had fail2ban, ufw or similar installed alongside sympl-firewall? Those are all ways to make things unhappy, and not supported configurations.

Yes, I am running fail2ban on this one. It’s banning hundreds of miscreants, so overall it seems to work

You’ll likely have inconsistent firewall results at best, and its likely that either sympl-firewall or fail2ban isn’t actually doing anything.

You’ll need to choose one or the other, and a future version of sympl-firewall will explicitly mark fail2ban as incompatible.

Can you clarify, please? Where is the incompatibility?

Does this mean I should switch to pcollison’s nftfw instead? That seems to be running happily alongside fail2ban on my other servers

iptables (nftables drop-in replacement for iptables, default in Debian), iptables-legacy (the older iptables version, which Sympl uses) and nftables are effectively two different firewalls.

The best case is that they will both work normally, the worst case however is that neither will work.

You need to either use the sympl-firewall package only, or remove itr and mix-and-match as needed, but that’s not something that can be supported here.