iptables fails to parse "-i +" correctly

[Thomas Sthlm]

I recently started to use Ubuntu 22.04 LTS on a server and created a simple ipables firewall for it.
(For Ubuntu 20.04 that I have used before, the below seems fine.)

lsb_release -rd
Description: Ubuntu 22.04.2 LTS
Release: 22.04

# apt-cache policy iptables-persistent
iptables-persistent:
  Installed: 1.0.16
  Candidate: 1.0.16
  Version table:
 *** 1.0.16 500
        500 http://se.archive.ubuntu.com/ubuntu jammy/universe amd64 Packages
        100 /var/lib/dpkg/status

# apt-cache policy iptables
iptables:
  Installed: 1.8.7-1ubuntu5.1
  Candidate: 1.8.7-1ubuntu5.1
  Version table:
 *** 1.8.7-1ubuntu5.1 500
        500 http://se.archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     1.8.7-1ubuntu5 500
        500 http://se.archive.ubuntu.com/ubuntu jammy/main amd64 Packages

--------------------------------------------------
ISSUE:
If I enter a simple iptables rule that uses the "-i +" input interface wildcard thing in it, but note that I don't give any interface namestring "prefix" before the "+" - for example:
iptables -A INPUT -i + -d 192.168.1.10 -j DROP
iptables -A INPUT -i + -d 192.168.1.11 -j DROP
iptables -A INPUT -i + -d 192.168.1.12 -j DROP

Then printouts of both iptables-save and iptables -L -n -v will show weird non-ascii/non-printable characters where the interfaces are supposed to be printed!
The result for my rule example above shows as:
-A INPUT -d 192.168.80.10/32 -i ˬP
+ -j DROP
-A INPUT -d 192.168.80.11/32 -i À¨P�+ -j DROP
-A INPUT -d 192.168.80.12/32 -i ˬP + -j DROP
(The garbage chars are in hex \c0\a8\50\0a, \c0\a8\50\0b, \c0\a8\50\0c respectively. Note the \0a newline char breaking up the printout into two lines for the first rule.)

The garbage characters makes
"iptables-save > /etc/iptables/rules.v4"
followed up with
"iptables-restore < /etc/iptables/rules.v4"
to fail!

I discovered that if the rule also includes some "protocol" constraints like "-p tcp -m tcp --dport 123" then iptables parses/prints the rule seemingly ok, but for "simpler" rules iptables gets confused.

[Oibaf (oibaf)]

Hi, I am not a maintainer, but maybe I can help you a bit.

Can you search in iptables bugzilla if your issue was already reported (either still open or already closed)? https://bugzilla.netfilter.org/query.cgi

Also, you may have a look at iptables source ( https://git.netfilter.org/iptables/log/ ) if you find a related fix after 1.8.7 commit release (happened in 2021-01-15).

If not, report it at: https://bugzilla.netfilter.org/enter_bug.cgi?product=iptables

Thanks.

[Thomas Sthlm (thomas-sthlm)]

@oibaf
Thanx,

Didn't search super-much but I did find a somewhat similar issue:
https://bugzilla.netfilter.org/show_bug.cgi?id=1085

That bug was about letting through -i interface strings with typos/not allowed characters when using the + wildcard, for example: iptables -A INPUT -i "et h+" ...

They have apparently been into that code before to bugfix, but not tested the case with + only / "null-string" interface name as prefix before the + wildcard.

Guess that I will report it to netfilter's bugzilla.

[Oibaf (oibaf)]

OK, great finding, when you file a bug on netfilter bugzilla report the link here, thanks.

[Thomas Sthlm (thomas-sthlm)]

@oibaf
Bug now filed with netfilter:
https://bugzilla.netfilter.org/show_bug.cgi?id=1702

[Oibaf (oibaf)]

Great, if you also want to test newer iptables and iptables-persistent, I backported the versions from Ubuntu mantic (latest development release) to 22.04, you can find them here (ignore the PPA description):
https://launchpad.net/~oibaf/+archive/ubuntu/gallium-nine

[Oibaf (oibaf)]

It looks it was a problem in iptables, not iptables-persistent.

[Oibaf (oibaf)]

Fixed upstream after 1.8.9.