I have the below iptable rule in /etc/iptables/rule.V6 and /etc/iptables/rule.V4

-4 -A INPUT -p icmp -j ACCEPT
-6 -A INPUT -p ipv6-icmp -j ACCEPT

when I tried to restart the netfilter-persistent, it internally calls the iptables-restore and ip6tables-restore.

ip6tables-restore failed because it couldn't understand the below rule

-4 -A INPUT -p icmp -j ACCEPT

Below is the error

root@rs-dal:/etc/iptables# ip6tables-restore rules.q
Error occurred at line: 15
Try `ip6tables-restore -h' or 'ip6tables-restore --help' for more information.

Ideally the rule that starts with -4 will be ignored by the ip6tables-restore, but that doesn't seems to be working in Debian Buster.

But, iptables-restore worked fine, it is only the issue with ip6tables-restore. How to fix this issue?


You are most certainly running iptables over nftables, as this is the default on Debian buster. To confirm this is the case, check for (nf_tables):

# ip6tables-restore --version
ip6tables-restore v1.8.2 (nf_tables)

Now in the ip6tables manual, there always has been:

-4, --ipv4
This option has no effect in iptables and iptables-restore. If a rule using the -4 option is inserted with (and only with) ip6tables-restore, it will be silently ignored. Any other uses will throw an error. This option allows IPv4 and IPv6 rules in a single rule file for use with both iptables-restore and ip6tables-restore.

The trouble is that you're now running ip6tables-nft-restore rather than ip6tables-legacy-restore.

There is no mention of -4 in differences to legacy iptables, meaning there shouldn't be a difference about it, but here it is. This really looks like a bug: either the new version ip6tables-nft-restore should cope with it, or the documentation should reflect it as an additional difference to be acceptable.

By the way the other way around (-6 with iptables-nft-restore) doesn't look better: it's accepted instead of ignored, leading to -A INPUT -p ipv6-icmp -j ACCEPT in addition to -A INPUT -p icmp -j ACCEPT in IPv4 protocol (this will never happen, except maybe with a custom test, and the IP stack will ignore it anyway).

Possible workarounds:

  1. file a bug report, insisting on a regression which would break existing rules and documentation. This would help other people too.

  2. split rules

    split your file into two files but apply a different filter to each, something like:

    grep -v -- '^ *-4 ' < before > after.v6
    grep -v -- '^ *-6 ' < before > after.v4
  3. create a wrapper for ip6tables-restore in /usr/local/sbin/ip6tables-restore doing about the same (and also do the same for iptables-restore), allowing to keep a single rule

  4. Give up (for now) iptables over nftables and revert to legacy iptables:

    # readlink -f $(which ip6tables-restore)
    # update-alternatives --config ip6tables        
    There are 2 choices for the alternative ip6tables (providing /usr/sbin/ip6tables).
      Selection    Path                        Priority   Status
    * 0            /usr/sbin/ip6tables-nft      20        auto mode
      1            /usr/sbin/ip6tables-legacy   10        manual mode
      2            /usr/sbin/ip6tables-nft      20        manual mode
    Press <enter> to keep the current choice[*], or type selection number: 1
    update-alternatives: using /usr/sbin/ip6tables-legacy to provide /usr/sbin/ip6tables (ip6tables) in manual mode
    # readlink -f $(which ip6tables-restore)

    The link of the related command also changed, fine.

    Do the same with iptables.

    Current rules are still running over nftables. You can dump them with iptables-nft-save + ip6tables-nft-save and restore them with iptables-save + ip6tables-save. This will result in rules running twice: once with kernel's iptables backend, once with kernel's nftables backend, and NAT might not always work correctly with this on kernel 4.19 (usually the first loaded module wins: here nft_nat). Better reboot, or know how to flush rules and remove relevant (nat) nftables modules.

  5. embrace the new features and use directly nft.

    There are commands available to help here (but they have the same problem as above): iptables-translate / ip6tables-translate and iptables-restore-translate / ip6tables-restore-translate, but the result usually needs reworking anyway (especially with fancy matches like u32). Nftables has a family type inet which can actually mix IPv4 and IPv6 rules (might require a newer kernel for this in nat), so it would simplify things.

  • Thanks a lot the detailed explanation, will analyse all the workaround and update the thread about my next step. – Karthik Mar 23 at 9:23
  • I have raised a bug below is the link bugs.debian.org/cgi-bin/bugreport.cgi?bug=925343 – Karthik Mar 23 at 13:12
  • Good. The only possible missing thing is that you should show the documentation related to the -4 option (from man iptables or man ip6tables), to insist this is a documented expected behaviour. Also understand that this report will probably be brought upstream at netfilter's team so this will take some delay anyway. Also the actual package is iptables, not iptables-persistent – A.B Mar 23 at 13:23
  • The whole issue is started when I restarted netfilter-persistent. netfilter-persistent is in iptables-persistent package. the problem is actually on ip6table-restore, I should have specified the package as iptables. my bad it is my mistake. I will change it if possible – Karthik Mar 23 at 13:27
  • debian.org/Bugs/server-control probably something like reassign 925343 iptables + perhaps anaffects too – A.B Mar 23 at 13:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.