Having a nftables ruleset like the one following, results in corrupted or changed ipv6 addresses (not all) when they are being saved by the nftables init script. table inet filter { set test_ipv6 { type ipv6_addr elements = { 2aff:2010::6787:f534, 2aff:2010::bc54:d10e, 2aff:2010::fe6b:dffc} } ... } results in (/var/lib/nftables/rules-save): table inet filter { set test_ipv6 { type ipv6_addr elements = { 2aff:2010::6787/128:f534, 2aff:2010::bc54/128:d10e, 2aff:2010::fe6b/128:dffc} } ... } Which itself gives an error when nftables starts up: * Loading nftables state and starting firewall ... /var/lib/nftables/rules-save:51:28-53: Error: mapping outside of map context elements = { 2aff:2010::6787/128:f534, 2aff:2010::bc54/128:d10e, 2aff:2010::fe6b/128:dffc} ^^^^^^^^^^^^^^^^^^^^^^^^^^ [ !! ] When saving the nftables ruleset by hand via nft list ruleset f.e. and then load it again (after a nft flush ruleset) with nft -f everything is working fine. The nftables init script performs a substitution in /etc/init.d/nftables in lines 130-144 which seems to be the problem: nft list tables ${l3f} | while read line; do line=$(echo ${line} | sed "s/table/table ${l3f}/") # The below substitution fixes an issue where nft -n output may not # always be parsable by nft -f. For example, nft -n might print # # ip6 saddr ::1 ip6 daddr ::1 counter packets 0 bytes 0 accept # # but nft -f refuses to parse that string with error: # # In file included from internal:0:0-0: # /var/lib/nftables/rules-save:1:1-2: Error: Could not process rule: # Invalid argument # table ip6 filter { # ^^ echo "$(nft ${SAVE_OPTIONS} list ${line} |\ sed 's/\(::[0-9a-fA-F]\+\)\([^/]\)/\1\/128\2/g')" >> "${tmp_save}" Reproducible: Always Steps to Reproduce: 1. load the described rule 2. run rc-service nftables save 3. restart nftables Actual Results: nftables fails to load the ruleset, all tables are blank Expected Results: nftables should load the rules, the firewall should work as expected
net-filter/nftables-0.5: the init scripts hasn't changed.
I've added an updated ebuild and new init scripts to bug 560920. I think they will solve this problem as well.
Should be fixed in >=0.5-r1
