No IPV4 using Raspberry pi as router

This is Debian based so it's using nftables by calling iptables command line which in modern version just translates the command to an nft command... Sorry :wink:

As far as I know all desktop distros use nftables these days most of them through the translation method

1 Like

In some cases, they use iptables and nftables simultaneously.
E.g. services like libvirt have not migrated to nftables yet.
So it may require to set up both iptables and nftables configs.

I'm pretty sure that this is not possible, at least with NAT. The way they use "both" is that the latest iptables commands are really not iptables commands, they're new nftables translator commands...

On Debian there is the default package: "iptables-nftables-compat" which provides a bunch of commands that translate. So when you run iptables .... it really converts that and runs "nft" on the conversion.

if you want to use real iptables you must install the iptables package which conflicts with iptables-nftables-compat... but then you also must disable all the nftables modules that conflict... it's a bunch of work to rip out nftables from modern desktops.

EDIT some of that wasn't right, I guess now iptables contains both the new style and the old style, and you have to fiddle around with Debian's alternatives system or something... in any case on a default Debian/Ubuntu install when you run "iptables" it is NOT running the traditional iptables commands, it's the nftables compatibility ones.

1 Like

Yep, you can see the rules added by iptables in the nftables runtime ruleset.
But in case of libvirt, those rules are in a separate table created dynamically.
It's problematic to manage with external tools like firewalld using nftables syntax.

Just to back up a minute - I also expected Ubuntu to use nftables since it is so close to Debian but I don't think it does - at least the 20.04 version I installed. For example: I don't have my pi handy at the moment. I'll try to double-check. Assuming it is iptables based - is there any simple command in openwrt that would trigger a sequence of configuration commands similar to what is generated by iptables-save? Should restarting the firewall service do this? I haven't been able to reboot inside the container - that tends to terminate nspawn.

1 Like

Nice! Your specific information definitely trumps my more general debian info. Looks like Ubuntu delayed their switch.

I'm hoping OpenWrt will switch to nftables soonish and we can have another long thread on tuning nftables to do good stuff.

should flush all the iptables and create them anew.

Hmmm - in that case I suspect something else is broken. I tried restarting the firewall in an ssh session ("service firewall restart") with no change - iptables-save was still blank. I'll play around a bit more later. Would still be nice to get it running.

It's always nice to have something to look forward to! :grimacing:

Thanks again.

+1 on that. Please let us know if you make it work.

Had a bit of time today and returned to this - and some progress! I still need to play around with various permutations to see which steps are required but the following worked for me:

  • On the host, run the systemctl commands to switch to systemd-networkd (as described in post 20 above).
  • open an ssh session on the lan side & enter fw3 print - this returns nothing
  • in a separate terminal on my laptop, ping also fails.
  • In luci, go to status->firewall (not network->firewall) - the screen will show all empty chains although the counters are counting
  • now re-enter fw3 print - at this point a bunch of firewall settings are displayed, however, they don't appear to be active (the ping command is still failing)
  • at this point any firewall restart will activate the firewall: like fw3 restart
    or service firewall restart or clicking the restart firewall button on the luci interface. Ping comes to life! Also the firewall status screen shows the chains although now counters on each heading remain at 0 packets/bytes.

Note that running in Ubuntu MATE, I can also restart the container from luci (this wasn't working in Raspberry OS) - at which point the firewall breaks again and I have to repeat the process. Also note before the firewall is up my laptop can connect to luci and ssh on the lan or wan side but after getting the firewall working I can only connect on the lan side - which I also take as a good indication of its operation.

Does anyone know what process is being triggered by clicking on the firewall status screen in luci and can I mimic it in a script? I tried uci commit firewall without any luck, nor do any of the simple restart commands work. fw3 print remains blank until I select that screen in luci.

Still, this is pretty amazing - it appears to be working! Just need to figure out how to automate these steps so it starts up correctly.

Thanks for any suggestions.

1 Like

i believe it *might* walk 'fw3 print network / zone" etc. etc.

fair chance the 'init' logic needs reworking to handle 'hostX' naming... ??? or similar... you might try renaming the internal psuedo interfaces and see if that helps...

I think I found a reasonable work-around - once I had the firewall up just use iptables-save > /usr/local/firewall-snapshot.txt. So now after starting the container I run cat /usr/local/firewall-snapshot.txt | iptables-restore and the firewall comes up - as best as I can tell. A couple extra steps when I alter the rules in luci, but not too big a deal. Still have some work to do but perhaps the most challenging part is over - fingers crossed. Thanks to everyone for your help so far!