Current state of nftables (end of 2020)

Hi all. Last January I tried to do some advanced QoS tutorials using nftables but we ran into issues with nftables not loading the script properly, having some incompatibilities etc.

Now it's almost the end of 2020 and everyone's been doing COVID stuff so I understand if not much progress occurred, but has anyone got nftables working smoothly on recent OpenWrt?

Not related to your QoS, but looks like jow is thinking of getting rid of iptables in firewall and replacing it with nftables:

https://git.openwrt.org/?p=openwrt/staging/jow.git;a=summary

firewall4: This package provides a nftables-compatible implementation of the UCI firewall.

https://git.openwrt.org/?p=openwrt/staging/jow.git;a=commit;h=a3c530ac13b4d7733fa4fd270f836defe1b1ae1b

4 Likes

I love it! nftables is just so so so much better. This is a big step forward for OpenWrt.

hello dlakelan you can see the thread of nftables

https://forum.openwrt.org/t/nftables-running-in-openwrt-perfectly/85254

apparently he work perfectly on openwrt but i don't work on my mikrotik hap ac2 because not full compatible with openwrt for the moment ...

what do you think ? :slight_smile:

No documentation or advice yet, but jow merged the firewall4 package to OpenWrt master today.

At the first glance it looks like a drop-in replacement to fiirewall3.

Package:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=f807db006fe5e86b43eb15d2e570556e8ba0071f

Underlying sources:
https://git.openwrt.org/?p=project/firewall4.git;a=summary

It is not yet the default, but could be installed to replace firewall3, I think.

3 Likes

yay, that's exciting. Is there a mechanism where you can ignore the UCI and just use an /etc/nftables.conf or something? Because the nftables script is really a great special purpose language.

@jow

$ git clone git://git.openwrt.org/project/firewall4.git
Cloning into 'firewall4'...
fatal: remote error: access denied or repository not exported: /project/firewall4.git

Cloning via https works, though.

Sure, put the nft command into /etc/rc.local - you donβ€˜t need a uci firewall package for that.

1 Like

Can you share the roadmap for moving from fw3/iptables to fw4/nftables?

The vpn-policy-routing is extensively using iptables at the moment, what would you recommend I do to prepare for migration?

3 Likes

Interested around this point too, similarly because of mwan3 being largely iptables based as well for PBR.

Well stuff that uses uci firewall rules should just work as before. Also iptables and nftables can coexist on the same system, so that might be a possible migration path as well - afair modern iptables is just an alternative frontend for netfilter.

I don't have any particular migration path in mind just yet though, first milestone was having a more or less feature-compatible nftables implementation of /etc/config/firewall - now that this is largely done, the focus shifts towards potential migration possibilities.

6 Likes

modern iptables command line stuff yes. But my understanding was fw3 was directly diddling with the firewall through a library not going through the command line iptables?

sure, I guess I'm imagining a world where fw4 is standard, and you want to use /etc/nftables.conf how would you disable the fw4? or could there be a switch saying "use /etc/nftables.conf instead". but I guess this is part of the whole "migration path" concept.

By invoking /etc/init.d/firewall disable

1 Like

I assume that also covers the PROCD firewall objects?

Is there fw4+UCI support or some plans for the following:

  • nat+OUTPUT+REDIRECT
  • ipv6+nat

This is useful for Tor, proxy, DNSv6 hijacking, IPv6 VPN, etc.

The relevant issue:

1 Like

Yes, procd firewall objects are recognized and should function exactly like fw3.

Yes, this is supported by fw4. To not introduce behavior changes for the existing configuration, it is configured slightly differently:

  • to enable IPv6 MASQUERADE on a zone, option masq6 must be set
  • to enable IPv6 for DNAT/SNAT etc. rules, an explicit option family ipv6 or option family any is required. The implicit default is option family ipv4 to retain backwards compatibility.
2 Likes

@jow

I installed fw4 to replace fw3 but it fails to start:

~# fw4 start
Reference error: left-hand side expression is null
In main(), file /usr/share/firewall4/templates/ruleset.uc, line 150, byte 48:
  called from function include ([C])
  called from function render_ruleset (/usr/share/firewall4/main.uc:98:72)
  called from anonymous function (/usr/share/firewall4/main.uc:161:28)

 `{%  for (local rule in fw4.rules("input_"+zone.name)): %}`
  Near here -------------------------------------^


/proc/self/fd/0:76:1-1: Error: syntax error, unexpected end of file
Firewall rules
~# uci show firewall
firewall.@defaults[0]=defaults
firewall.@defaults[0].input='ACCEPT'
firewall.@defaults[0].output='ACCEPT'
firewall.@defaults[0].forward='REJECT'
firewall.@zone[0]=zone
firewall.@zone[0].name='lan'
firewall.@zone[0].input='ACCEPT'
firewall.@zone[0].output='ACCEPT'
firewall.@zone[0].forward='ACCEPT'
firewall.@zone[0].network='lan'
firewall.@zone[1]=zone
firewall.@zone[1].name='wan'
firewall.@zone[1].input='REJECT'
firewall.@zone[1].output='ACCEPT'
firewall.@zone[1].forward='REJECT'
firewall.@zone[1].masq='1'
firewall.@zone[1].mtu_fix='1'
firewall.@zone[1].network='wan wan6'
firewall.@forwarding[0]=forwarding
firewall.@forwarding[0].src='lan'
firewall.@forwarding[0].dest='wan'
firewall.@rule[0]=rule
firewall.@rule[0].name='Allow-DHCP-Renew'
firewall.@rule[0].src='wan'
firewall.@rule[0].proto='udp'
firewall.@rule[0].dest_port='68'
firewall.@rule[0].target='ACCEPT'
firewall.@rule[0].family='ipv4'
firewall.@rule[1]=rule
firewall.@rule[1].name='Allow-Ping'
firewall.@rule[1].src='wan'
firewall.@rule[1].proto='icmp'
firewall.@rule[1].icmp_type='echo-request'
firewall.@rule[1].family='ipv4'
firewall.@rule[1].target='ACCEPT'
firewall.@rule[2]=rule
firewall.@rule[2].name='Allow-IGMP'
firewall.@rule[2].src='wan'
firewall.@rule[2].proto='igmp'
firewall.@rule[2].family='ipv4'
firewall.@rule[2].target='ACCEPT'
firewall.@rule[3]=rule
firewall.@rule[3].name='Allow-DHCPv6'
firewall.@rule[3].src='wan'
firewall.@rule[3].proto='udp'
firewall.@rule[3].src_ip='fc00::/6'
firewall.@rule[3].dest_ip='fc00::/6'
firewall.@rule[3].dest_port='546'
firewall.@rule[3].family='ipv6'
firewall.@rule[3].target='ACCEPT'
firewall.@rule[4]=rule
firewall.@rule[4].name='Allow-MLD'
firewall.@rule[4].src='wan'
firewall.@rule[4].proto='icmp'
firewall.@rule[4].src_ip='fe80::/10'
firewall.@rule[4].icmp_type='130/0' '131/0' '132/0' '143/0'
firewall.@rule[4].family='ipv6'
firewall.@rule[4].target='ACCEPT'
firewall.@rule[5]=rule
firewall.@rule[5].name='Allow-ICMPv6-Input'
firewall.@rule[5].src='wan'
firewall.@rule[5].proto='icmp'
firewall.@rule[5].icmp_type='echo-request' 'echo-reply' 'destination-unreachable' 'packet-too-big' 'time-exceeded' 'bad-header' 'unknown-header-type' 'router-solicitation' 'neighbour-solicitation' 'router-advertisement' 'neighbour-advertisement'
firewall.@rule[5].limit='1000/sec'
firewall.@rule[5].family='ipv6'
firewall.@rule[5].target='ACCEPT'
firewall.@rule[6]=rule
firewall.@rule[6].name='Allow-ICMPv6-Forward'
firewall.@rule[6].src='wan'
firewall.@rule[6].dest='*'
firewall.@rule[6].proto='icmp'
firewall.@rule[6].icmp_type='echo-request' 'echo-reply' 'destination-unreachable' 'packet-too-big' 'time-exceeded' 'bad-header' 'unknown-header-type'
firewall.@rule[6].limit='1000/sec'
firewall.@rule[6].family='ipv6'
firewall.@rule[6].target='ACCEPT'
firewall.@rule[7]=rule
firewall.@rule[7].name='Allow-IPSec-ESP'
firewall.@rule[7].src='wan'
firewall.@rule[7].dest='lan'
firewall.@rule[7].proto='esp'
firewall.@rule[7].target='ACCEPT'
firewall.@rule[8]=rule
firewall.@rule[8].name='Allow-ISAKMP'
firewall.@rule[8].src='wan'
firewall.@rule[8].dest='lan'
firewall.@rule[8].dest_port='500'
firewall.@rule[8].proto='udp'
firewall.@rule[8].target='ACCEPT'
firewall.@include[0]=include
firewall.@include[0].path='/etc/firewall.user'

Is there any merit (or thoughts with OpenWRT) in waiting for BPFILTER and not using nftables? My understanding (though pretty limited) is Kernel developers were looking to replace nftables by BPFILTER. I haven't researched it thoroughly (just an article I'd read) , but this seemed to be the goal, not sure on the time frame.

I just ask out of interest as a way of avoiding two transitions iptables -> nftables -> BPFILTER.

No. nftables is clearly the future. It's actually the present in Debian and other related distros. The only thing that might happen is on the backend. nftables script might compile to eBPF at some point in the future. This will be transparent to you.

2 Likes

@LGA1150 - I tried to reproduce it but couldn't unfortunately. Could you mention the target/device you were trying it on?

Edit: I was able to track down the culprit, will push fixes shortly.

1 Like