Firewall reject UDP not working or is it?

Axel · January 10, 2024, 11:48am

I'm trying to restrict some UDP-traffic in my Raspberry Pi 4B hardware with
OpenWrt version 23.05.0.

Scenario 1

An attempt to stop traffic from the 'lan' zone to 'wan' zone succeeded,
where a PC was blocked as follows.
Edit the file /etc/config/firewall so that

option log '1' is added to the zone 'wan'.
Add the following rule last in the file:

config rule
	option name 'block-all-else'
	list proto 'all'
	option src 'lan'
	list src_ip '192.168.2.161'
	option dest 'wan'
	option target 'REJECT'

Run the command "fw4 reload".
Let a web browser in the PC at 192.168.2.161 try to connect any web site.
Run the command "logread".
You can now watch logs as this example:
Wed Jan 10 10:37:35 2024 kern.warn kernel: [ 4032.055866] reject wan out: IN=br-lan OUT=eth1 MAC=d8:3a:dd:6e:b0:eb:54:04:a6:c4:63:54:08:00 SRC=192.168.2.161 DST=x.x.x.x LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=27587 DF PROTO=TCP SPT=54370 DPT=443 WINDOW=64240 RES=0x00 SYN URGP=0

The web browser fails when trying to connect.

Scenario 2.

Edit the file /etc/config/firewall so that src_ip in the last rule (block-all-else) is changed to 192.168.2.12:

	option src 'lan'
	list src_ip '192.168.2.12'

The only difference from scenario 1 is the IP-address, which is an IP-address
of an IoT-device.
Run the command "fw4 reload".
With tcpdump, I can observe that the device sends an UDP-packet every
10:th second. Example:
11:16:47.407457 IP 192.168.2.12.8888 > x.x.com.9999: UDP, length ...

But now nothing is logged in the syslog.
I guess that the UDP-packets are not blocked, since:
a) the device works
b) the server x.x.com sends a UDP-packet to the device a few milliseconds after some of the packets the device sends. That seems to be acknowledgments.

Both the PC and the device are connected with wires via an Ethernet bridge to the same port in Raspberry Pi.
So the difference between the two scenarios is that the first uses TCP,
and the second uses UDP.

Reboot the router.

Now the filter works as intended.
I would really like to understand what can cause a reboot to work.
It seems that rebooting does some additional things that "fw4 reload" doesn't.

Some IP-addresses, domain names, port numbers and packet lengths above have been made anonymous.

egc · January 10, 2024, 12:00pm

Have you enabled flow offload?

I have heard that that circumvent the firewall for existing connections, so either rebooting the router or rebooting the client is necessary (or resetting the connection tracking?)

Axel · January 10, 2024, 12:37pm

Thanks.

I haven't enabled software flow offloading.

flygarn12 · January 10, 2024, 1:08pm

Does this old Linux commands even work anymore i Linux?

The only commands that I use in Linux and that actually work is the etc/init.d/firewall reload

If you run network reload does it start reloading the network then?

Anyway, the service isn’t named fw4. That is the name of the package. It is still firewall that is the service name.

Axel · January 10, 2024, 3:10pm

Thanks.

fw4 reload seems to work, since it make changes which can be seen via
nft list ruleset.

Maybe I should use etc/init.d/firewall instead.

network reload seems to restart WiFi. It doesn't commit changes in
/etc/config/firewall, as seen via nft list ruleset. Perhaps it shouldn't.

flygarn12 · January 10, 2024, 3:13pm

The thing with that is more to test if it works since it produces a lot of text in the terminal.
The firewall is quiet if you don’t have any rules or something disabled.

Axel · January 10, 2024, 3:27pm

Thanks.

The network works after network reload.

I can setup the case I had, and try it tomorrow.

flygarn12 · January 10, 2024, 4:00pm

I have never really found what variant is the right one to use. The Linux internet and OpenWrt wiki is pretty much drenched in both but init.d variant seems to be the newer variant since some change in the Linux kernel some years ago.

You can try restart instead of reload also but my experience with this is that it doesn’t really matter if you use reload or restart, the new rules will be applied afterward without a complete router reboot.

But nowadays I always use etc/init.d/ variant everywhere.

egc · January 10, 2024, 4:16pm

For me this is a handy tool: a simple service will give you the services available:

root@R7800-2:~# service
Usage: service <service> [command]
/etc/init.d/adblock                enabled         stopped
/etc/init.d/banip                 disabled         stopped
/etc/init.d/bcp38                  enabled         stopped
/etc/init.d/boot                   enabled         stopped
/etc/init.d/bootcount              enabled         stopped
/etc/init.d/collectd               enabled         running
/etc/init.d/cpufreq                enabled         stopped
/etc/init.d/cron                   enabled         stopped
/etc/init.d/ddns                   enabled         stopped
/etc/init.d/dnsmasq                enabled         running
/etc/init.d/done                   enabled         stopped
/etc/init.d/dropbear               enabled         running
/etc/init.d/etherwake              enabled         stopped
/etc/init.d/firewall               enabled         stopped
/etc/init.d/fstab                  enabled         stopped
/etc/init.d/gpio_switch            enabled         stopped
/etc/init.d/irqbalance             enabled         running
/etc/init.d/ksmbd                  enabled         running
/etc/init.d/led                    enabled         stopped
/etc/init.d/log                    enabled         running
/etc/init.d/luci_statistics        enabled         stopped
/etc/init.d/miniupnpd              enabled         stopped
/etc/init.d/network                enabled         running
/etc/init.d/nlbwmon               disabled         stopped
/etc/init.d/odhcpd                 enabled         running
/etc/init.d/openssl                enabled         stopped
/etc/init.d/openvpn                enabled         stopped
/etc/init.d/packet_steering        enabled         stopped
/etc/init.d/pbr                   disabled         stopped
/etc/init.d/radius                 enabled         stopped
/etc/init.d/rpcd                   enabled         running
/etc/init.d/smartdns               enabled         stopped
/etc/init.d/sqm                    enabled         stopped
/etc/init.d/sysctl                 enabled         stopped
/etc/init.d/sysfixtime             enabled         stopped
/etc/init.d/sysntpd                enabled         running
/etc/init.d/system                 enabled         stopped
/etc/init.d/ucitrack               enabled         stopped
/etc/init.d/uhttpd                 enabled         running
/etc/init.d/umount                 enabled         stopped
/etc/init.d/unetd                  enabled         running
/etc/init.d/urandom_seed           enabled         stopped
/etc/init.d/urngd                  enabled         running
/etc/init.d/wpad                   enabled         running
/etc/init.d/wsdd2                  enabled         running
root@R7800-2:~#

Note the Usage: service <service> [command]

Axel · January 11, 2024, 7:53am

Thanks for info.

Axel · January 11, 2024, 7:57am

Thanks.
I did setup scenario 2 again.
/etc/config/firewall was edited so that the device should be blocked.
Then:

/etc/init.d/firewall reload
/etc/init.d/network reload

However, the traffic could slip through.
Finally, rebooting made the filter work.

Axel · January 11, 2024, 8:32am

Thanks for info.

/etc/init.d/network restart made the filter work.