Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FS#2815 - nftables in 19.07 #7613

Open
openwrt-bot opened this issue Feb 5, 2020 · 4 comments
Open

FS#2815 - nftables in 19.07 #7613

openwrt-bot opened this issue Feb 5, 2020 · 4 comments
Labels

Comments

@openwrt-bot
Copy link

summers:

Hi,

starting in 19.07 nftables don't work properly.

This is on a MIPS xrx200 device, TPlink td w8970.

To install nftables:

  • opkg update
  • opkg install nftables
  • opkg install kmod-nft-nat
  • rm /etc/modules.d/ipt*
  • rm /etc/modules.d/42-ip6tables
  • reboot

Create the file /etc/nftables.conf

flush ruleset

table ip nat {
chain prerouting {
type nat hook prerouting priority filter; policy accept;
}

chain postrouting {
	type nat hook postrouting priority srcnat; policy accept;
	meta oiftype ppp masquerade
}

}
table inet filter {
chain input {
type filter hook input priority filter; policy drop;
ct state { established, related } accept
ct state invalid drop
meta iiftype != ppp accept
ip protocol icmp accept
ip6 nexthdr ipv6-icmp accept
meta iiftype ppp drop
}

chain forward {
	type filter hook forward priority filter; policy drop;
	ct state { established, related } accept
	ct state invalid drop
	meta iiftype != ppp accept
	ip protocol icmp accept
	ip6 nexthdr ipv6-icmp accept
	meta iiftype ppp drop
}

chain output {
	type filter hook output priority filter; policy accept;
}

}

Then attempt to install via
nft -f /etc/nftables.conf
Gives the error that

/etc/nftables.conf:4:8-17: Error: Could not process rule: File exists
chain prerouting {
^^^^^^^^^^
/etc/nftables.conf:8:8-18: Error: Could not process rule: File exists
chain postrouting {
^^^^^^^^^^^
/etc/nftables.conf:10:3-29: Error: Could not process rule: No such file or directory
meta oiftype ppp masquerade
^^^^^^^^^^^^^^^^^^^^^^^^^^^

This is the error you would usually get if iptables nat was in the kernel, but lsmod confirms not installed. Running "nft flush ruleset" in isolatation works; and then the "nft -f /etc/nftables.conf" works as expected.

This provides WAN access for the lan, as expected; so NAT is working, and also router not scanned, so firewall is correct.

However on the router can't do nslookups without error, eg.
opkg update
Downloading http://downloads.openwrt.org/releases/19.07.1/targets/lantiq/xrx200/packages/Packages.gz
*** Failed to download the package list from http://downloads.openwrt.org/releases/19.07.1/targets/lantiq/xrx200/packages/Packages.gz

Downloading http://downloads.openwrt.org/releases/19.07.1/targets/lantiq/xrx200/kmods/4.14.167-1-0f59e90218b95a909e229a713d3da157/Packages.gz
*** Failed to download the package list from http://downloads.openwrt.org/releases/19.07.1/targets/lantiq/xrx200/kmods/4.14.167-1-0f59e90218b95a909e229a713d3da157/Packages.gz

Downloading http://downloads.openwrt.org/releases/19.07.1/packages/mips_24kc/base/Packages.gz
*** Failed to download the package list from http://downloads.openwrt.org/releases/19.07.1/packages/mips_24kc/base/Packages.gz

Downloading http://downloads.openwrt.org/releases/19.07.1/packages/mips_24kc/luci/Packages.gz
*** Failed to download the package list from http://downloads.openwrt.org/releases/19.07.1/packages/mips_24kc/luci/Packages.gz

Downloading http://downloads.openwrt.org/releases/19.07.1/packages/mips_24kc/packages/Packages.gz
*** Failed to download the package list from http://downloads.openwrt.org/releases/19.07.1/packages/mips_24kc/packages/Packages.gz

Downloading http://downloads.openwrt.org/releases/19.07.1/packages/mips_24kc/routing/Packages.gz
*** Failed to download the package list from http://downloads.openwrt.org/releases/19.07.1/packages/mips_24kc/routing/Packages.gz

Downloading http://downloads.openwrt.org/releases/19.07.1/packages/mips_24kc/telephony/Packages.gz
*** Failed to download the package list from http://downloads.openwrt.org/releases/19.07.1/packages/mips_24kc/telephony/Packages.gz

Collected errors:

But "ping 8.8.8.8" works.

But flushing the ruleset first (so no NAT or firewall) and the router access to the WAN works.

So this as a whole says nftables badly broken on this machine in 19.07, as can't do an atomic replacement of the rules, and can't get WAN access from the router.

In 18.06 this worked perfectly.

So it looks like in 19.07, there is some IPtable baggage left in the kernel, stopping nftables working correctly.

I checked the kernel configuation, and built my own openwrt 19.07, with hand crafted 4.14.167 kernel config. This boots with the same messages as 19.07.1 and has the same nftable faults.

I'll keep digging, but time to report it here.

As long term, openwrt will probably need to move away from iptables, to nftables (as the iptables backend goes to nftables). So ideally we would get this working, so those openwrt users that use nftables, can debug their usage on openwrt, before everyone has to move.

Any ideas?

David.

@openwrt-bot
Copy link
Author

fseek:

I have this problem too with a netgear r7800 (arm) in the latest trunk, kernel 5.4.31.

I'm trying to figure out what is the actual issue, apparently every module seems to be compiled in...

Still the kernel cannot recognize the prerouting and postrouting chains in the nat table.

@openwrt-bot
Copy link
Author

fseek:

I debugged my problems and hopefully also the problems of the original poster.

In my case the issue is due to a refactoring occurred in linux 5.1 with this commit:

commit db8ab38880e06dedbfc879e75f5b0ddc495f4eb6 Author: Florian Westphal Date: Thu Feb 28 12:02:52 2019 +0100
netfilter: nf_tables: merge ipv4 and ipv6 nat chain types

Basically now we need to load another module, nft_chain_nat.ko

This isn't the first time I encountered a similar refactoring issue so I searched for "nf_tables: merge" in the commit messages:

c1deb065cf3b netfilter: nf_tables: merge route type into core db8ab38880e0 netfilter: nf_tables: merge ipv4 and ipv6 nat chain types d0103158cf7c netfilter: nf_tables: merge exthdr expression into nft core ae1bc6a9f398 netfilter: nf_tables: merge rt expression into nft core

So now I'm carrying the following patch in my tree, that fixes the NAT setup for nftables in trunk by loading the correct modules for each kernel (for each commit I looked at the tags with git tags --contains ):

Author: fseek Date: Thu Apr 9 16:18:16 2020 +0200
nftables fixes

diff --git a/include/netfilter.mk b/include/netfilter.mk
index 306975c31b..c851c15454 100644
--- a/include/netfilter.mk
+++ b/include/netfilter.mk
@@ -340,11 +340,11 @@ $(eval $(if $(NF_KMOD),$(call nf_add,NFT_CORE,CONFIG_NF_TABLES_INET, $(P_XT)nf_t
$(eval $(if $(NF_KMOD),$(call nf_add,NFT_CORE,CONFIG_NF_TABLES_IPV4, $(P_V4)nf_tables_ipv4, lt 4.17),))
$(eval $(if $(NF_KMOD),$(call nf_add,NFT_CORE,CONFIG_NF_TABLES_IPV6, $(P_V6)nf_tables_ipv6, lt 4.17),))
$(eval $(if $(NF_KMOD),$(call nf_add,NFT_CORE,CONFIG_NF_TABLES_SET, $(P_XT)nf_tables_set, ge 4.18),))
-$(eval $(if $(NF_KMOD),$(call nf_add,NFT_CORE,CONFIG_NFT_CHAIN_ROUTE_IPV4, $(P_V4)nft_chain_route_ipv4),))
-$(eval $(if $(NF_KMOD),$(call nf_add,NFT_CORE,CONFIG_NFT_CHAIN_ROUTE_IPV6, $(P_V6)nft_chain_route_ipv6),))
+$(eval $(if $(NF_KMOD),$(call nf_add,NFT_CORE,CONFIG_NFT_CHAIN_ROUTE_IPV4, $(P_V4)nft_chain_route_ipv4, lt 5.2),))
+$(eval $(if $(NF_KMOD),$(call nf_add,NFT_CORE,CONFIG_NFT_CHAIN_ROUTE_IPV6, $(P_V6)nft_chain_route_ipv6, lt 5.2),))
$(eval $(if $(NF_KMOD),$(call nf_add,NFT_CORE,CONFIG_NFT_COUNTER, $(P_XT)nft_counter),))
$(eval $(if $(NF_KMOD),$(call nf_add,NFT_CORE,CONFIG_NFT_CT, $(P_XT)nft_ct),))
-$(eval $(if $(NF_KMOD),$(call nf_add,NFT_CORE,CONFIG_NFT_EXTHDR, $(P_XT)nft_exthdr),))
+$(eval $(if $(NF_KMOD),$(call nf_add,NFT_CORE,CONFIG_NFT_EXTHDR, $(P_XT)nft_exthdr, lt 4.18),))
$(eval $(if $(NF_KMOD),$(call nf_add,NFT_CORE,CONFIG_NFT_HASH, $(P_XT)nft_hash),))
$(eval $(if $(NF_KMOD),$(call nf_add,NFT_CORE,CONFIG_NFT_LIMIT, $(P_XT)nft_limit),))
$(eval $(if $(NF_KMOD),$(call nf_add,NFT_CORE,CONFIG_NFT_LOG, $(P_XT)nft_log),))
@@ -365,7 +365,8 @@ $(eval $(if $(NF_KMOD),$(call nf_add,NFT_BRIDGE,CONFIG_NFT_BRIDGE_META, $(P_EBT)
$(eval $(if $(NF_KMOD),$(call nf_add,NFT_BRIDGE,CONFIG_NFT_BRIDGE_REJECT, $(P_EBT)nft_reject_bridge),))

$(eval $(if $(NF_KMOD),$(call nf_add,NFT_NAT,CONFIG_NFT_NAT, $(P_XT)nft_nat),))
-$(eval $(if $(NF_KMOD),$(call nf_add,NFT_NAT,CONFIG_NFT_CHAIN_NAT_IPV4, $(P_V4)nft_chain_nat_ipv4),))
+$(eval $(if $(NF_KMOD),$(call nf_add,NFT_NAT,CONFIG_NFT_NAT, $(P_XT)nft_chain_nat, ge 5.1),))
+$(eval $(if $(NF_KMOD),$(call nf_add,NFT_NAT,CONFIG_NFT_CHAIN_NAT_IPV4, $(P_V4)nft_chain_nat_ipv4, lt 5.1),))
$(eval $(if $(NF_KMOD),$(call nf_add,NFT_NAT,CONFIG_NFT_REDIR_IPV4, $(P_V4)nft_redir_ipv4),))
$(eval $(if $(NF_KMOD),$(call nf_add,NFT_NAT,CONFIG_NFT_MASQ, $(P_XT)nft_masq),))
$(eval $(if $(NF_KMOD),$(call nf_add,NFT_NAT,CONFIG_NFT_MASQ_IPV4, $(P_V4)nft_masq_ipv4),))

It would be nice if you could merge this patch (or a better one) to fix the issue in trunk.

Thanks.

@openwrt-bot
Copy link
Author

n8v8R:

  • nftables is generally not very usable in the 19.07 branch, starting with various unset kernel conf flags [1]
  • package maintenance is suffering from lack of resources (source stable release 0.9.4 vs. 0.9.3 in OpenWrt Master vs. 0.9.2 in OpenWrt 19.7.x)
  • seems that transition from IPT to NFT is not high on the developers agenda though been mentioned (fw4) [2]

Anyway, for that particular NAT issue did you try? (works for me with OpenWrt Master with PPPoE on dual-stack WAN - //do not use with ds-lite// however)

table ip nat {
chain postrouting {
type nat hook postrouting priority srcnat; policy accept;
oifname "pppoe-*" masquerade fully-random
}
}


[1] [[https://bugs.openwrt.org/index.php?do=details&task_id=2360]]
[2] [[https://openwrt.org/meetings/hamburg2019/start]]

@openwrt-bot
Copy link
Author

fseek:

Sorry for the delay in the response.

The issue is nft_chain_nat.ko is not compiled in. So maybe masquerading works, but SNAT/DNAT definitely don't.

This happened because part of the code was refactored in linux 5.1 and the nat chains require now a new Kconfig symbol (see the git commands in my previous post). When the openwrt maintainers upgraded the kernel they missed this new dependency.

It seems this area of the code is under heavy refactoring since a similar issue appeared in the past and was patched in January (see commit 0e05093).

Now, reading again your bug report, I see that the issue you had is not the same as mine. It seemed so initially because I got an error message similar to yours.

So for now I'm carrying on my local repo (tracking master) the above patch and the issue is resolved for me.

Even if this isn't the right place to ask, maybe someone could bring this problem to the attention of the maintainer (Jo-Philipp Wich?).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant