Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
//posted problem description publicly with customer sensitive data removed//
Description of problem:
================
When translating iptables rules to nftables, customer hits issue where unexpected rule is created
Version-Release number of selected component (if applicable):
===============
Reported on following version:
kernel-4.18.0-193.el8.x86_64
iptables-1.8.4-10.el8.x86_64 Tue May 12 05:05:09 2020
iptables-libs-1.8.4-10.el8.x86_64 Tue May 12 05:03:00 2020
nftables-0.9.3-12.el8.x86_64 Tue May 12 05:05:09 2020
Also replicated on updated versions
kernel-4.18.0-193.13.2.el8_2.x86_64
rpm -qa | egrep "iptables|nftables"
nftables-0.9.3-12.el8.x86_64 << nftables version was alraedy most up to date
iptables-1.8.4-10.el8_2.1.x86_64 << iptables version slightly increased.
iptables-libs-1.8.4-10.el8_2.1.x86_64
iptables-ebtables-1.8.4-10.el8_2.1.x86_64
How reproducible:
Very
Steps to Reproduce:
1. create text file with iptables as follows
cat test_ruleset.txt
*filter
:INPUT ACCEPT
:FORWARD ACCEPT
:OUTPUT ACCEPT
-A INPUT
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type any -j ACCEPT <<< happens due to this rule
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -m tcp -p tcp --dport 22 -j ACCEPT
-A INPUT -j DROP
2. then run:
# iptables-restore-translate -f test_ruleset.txt
Actual results:
# Translated by iptables-restore-translate v1.8.4 on Mon Jul 20 17:38:17 2020
add table ip filter
add chain ip filter INPUT { type filter hook input priority 0; policy accept; }
add chain ip filter FORWARD { type filter hook forward priority 0; policy accept; }
add chain ip filter OUTPUT { type filter hook output priority 0; policy accept; }
add rule ip filter INPUT counter
add rule ip filter INPUT iifname "lo" counter accept
add rule ip filter INPUT counter accept
add rule ip filter INPUT ct state related,established counter accept
add rule ip filter INPUT tcp dport 22 counter accept
add rule ip filter INPUT counter drop
# Completed on Mon Jul 20 17:38:17 2020
[looking at line under iifname line]
The output is not expected on "counter accept" line for 2 reasons
- the created rule is not ICMP specific so this could be security risk as it allows any packets (unsure but it generally looks wrong)
- there are 2 spaces between INPUT and counter
Expected results:
Issue does not happen if test_ruleset has icmp-type 5 (or any valid number), it only happens with type "any"
----------
If I change the test_ruleset to be icmp-type 5 (or any valid icmp number), it correctly translates:
root@hostname ~ $ cat test_ruleset.txt
*filter
:INPUT ACCEPT
:FORWARD ACCEPT
:OUTPUT ACCEPT
-A INPUT
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 5 -j ACCEPT
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -m tcp -p tcp --dport 22 -j ACCEPT
-A INPUT -j DROP
root@hostname ~ $ iptables-restore-translate -f test_ruleset.txt
# Translated by iptables-restore-translate v1.8.4 on Mon Jul 20 17:42:07 2020
add table ip filter
add chain ip filter INPUT { type filter hook input priority 0; policy accept; }
add chain ip filter FORWARD { type filter hook forward priority 0; policy accept; }
add chain ip filter OUTPUT { type filter hook output priority 0; policy accept; }
add rule ip filter INPUT counter
add rule ip filter INPUT iifname "lo" counter accept
add rule ip filter INPUT icmp type redirect counter accept
add rule ip filter INPUT ct state related,established counter accept
add rule ip filter INPUT tcp dport 22 counter accept
add rule ip filter INPUT counter drop
# Completed on Mon Jul 20 17:42:07 2020
-------------
See line shows icmp specific output
Upstream commit to backport:
commit ad4b17b98bbedf93d2182a4dc9a37e9cf3adfe1b
Author: Phil Sutter <phil>
Date: Tue Oct 6 19:07:19 2020 +0200
extensions: libipt_icmp: Fix translation of type 'any'
By itself, '-m icmp --icmp-type any' is a noop, it matches any icmp
types. Yet nft_ipv4_xlate() does not emit an 'ip protocol' match if
there's an extension with same name present in the rule. Luckily, legacy
iptables demands icmp match to be prepended by '-p icmp', so we can
assume this is present and just emit the 'ip protocol' match from icmp
xlate callback.
Fixes: aa158ca0fda65 ("extensions: libipt_icmp: Add translation to nft")
Signed-off-by: Phil Sutter <phil>
Reviewed-by: Florian Westphal <fw>
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (iptables bug fix and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2021:1642
//posted problem description publicly with customer sensitive data removed// Description of problem: ================ When translating iptables rules to nftables, customer hits issue where unexpected rule is created Version-Release number of selected component (if applicable): =============== Reported on following version: kernel-4.18.0-193.el8.x86_64 iptables-1.8.4-10.el8.x86_64 Tue May 12 05:05:09 2020 iptables-libs-1.8.4-10.el8.x86_64 Tue May 12 05:03:00 2020 nftables-0.9.3-12.el8.x86_64 Tue May 12 05:05:09 2020 Also replicated on updated versions kernel-4.18.0-193.13.2.el8_2.x86_64 rpm -qa | egrep "iptables|nftables" nftables-0.9.3-12.el8.x86_64 << nftables version was alraedy most up to date iptables-1.8.4-10.el8_2.1.x86_64 << iptables version slightly increased. iptables-libs-1.8.4-10.el8_2.1.x86_64 iptables-ebtables-1.8.4-10.el8_2.1.x86_64 How reproducible: Very Steps to Reproduce: 1. create text file with iptables as follows cat test_ruleset.txt *filter :INPUT ACCEPT :FORWARD ACCEPT :OUTPUT ACCEPT -A INPUT -A INPUT -i lo -j ACCEPT -A INPUT -p icmp -m icmp --icmp-type any -j ACCEPT <<< happens due to this rule -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A INPUT -m tcp -p tcp --dport 22 -j ACCEPT -A INPUT -j DROP 2. then run: # iptables-restore-translate -f test_ruleset.txt Actual results: # Translated by iptables-restore-translate v1.8.4 on Mon Jul 20 17:38:17 2020 add table ip filter add chain ip filter INPUT { type filter hook input priority 0; policy accept; } add chain ip filter FORWARD { type filter hook forward priority 0; policy accept; } add chain ip filter OUTPUT { type filter hook output priority 0; policy accept; } add rule ip filter INPUT counter add rule ip filter INPUT iifname "lo" counter accept add rule ip filter INPUT counter accept add rule ip filter INPUT ct state related,established counter accept add rule ip filter INPUT tcp dport 22 counter accept add rule ip filter INPUT counter drop # Completed on Mon Jul 20 17:38:17 2020 [looking at line under iifname line] The output is not expected on "counter accept" line for 2 reasons - the created rule is not ICMP specific so this could be security risk as it allows any packets (unsure but it generally looks wrong) - there are 2 spaces between INPUT and counter Expected results: Issue does not happen if test_ruleset has icmp-type 5 (or any valid number), it only happens with type "any" ---------- If I change the test_ruleset to be icmp-type 5 (or any valid icmp number), it correctly translates: root@hostname ~ $ cat test_ruleset.txt *filter :INPUT ACCEPT :FORWARD ACCEPT :OUTPUT ACCEPT -A INPUT -A INPUT -i lo -j ACCEPT -A INPUT -p icmp -m icmp --icmp-type 5 -j ACCEPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A INPUT -m tcp -p tcp --dport 22 -j ACCEPT -A INPUT -j DROP root@hostname ~ $ iptables-restore-translate -f test_ruleset.txt # Translated by iptables-restore-translate v1.8.4 on Mon Jul 20 17:42:07 2020 add table ip filter add chain ip filter INPUT { type filter hook input priority 0; policy accept; } add chain ip filter FORWARD { type filter hook forward priority 0; policy accept; } add chain ip filter OUTPUT { type filter hook output priority 0; policy accept; } add rule ip filter INPUT counter add rule ip filter INPUT iifname "lo" counter accept add rule ip filter INPUT icmp type redirect counter accept add rule ip filter INPUT ct state related,established counter accept add rule ip filter INPUT tcp dport 22 counter accept add rule ip filter INPUT counter drop # Completed on Mon Jul 20 17:42:07 2020 ------------- See line shows icmp specific output