Firewall rule (fw4) is not working .. how to debug?

Installing and Using OpenWrt Network and Wireless Configuration
1

I built an image from master just now and created this firewall rule to deny WAN access to a particular client. The rule is active yet I can still get out to the WAN from that client. Under a pure fw3 image built from a few days ago, the rule worked as expected. How can I debug?

config rule
  option src 'lan'
  option target 'REJECT'
  option name 'Deny WAN access'
  option dest 'wan'
  list proto 'all'
  list src_ip '10.9.8.100'
  list src_ip '10.9.8.112'

EDIT: Is this to be expected?

# /etc/init.d/firewall status
inactive
2

opkg intsall iptables-nft

copy the fw3 working tables entries related to this rule, save to file, use iptables-restore-translate on the resulting file to create a nft tables rule and compare with that generated by fw4 (nft list | grep "Deny")?

just a thought - haven't done this yet, but i need to start thinking about it.

2 Likes
3

Run fw4 reload and look for errors. Then run nft list ruleset to see the actual rules.

1 Like
4

Thanks for the replies.

That gave no output. I would try the other suggestions, but I flashed an older image to the device which uses fw3 and that does work. I don't know what else isn't working and need to control access to devices here. Will have to get a spare RPi4 to use for development testing with this.

I did open FS#4258 since this behavior was confirmed by another user.

@dave14305 @anon98444528 - Either of you running with fw4? Care to make that rule and see what you can determine?

5

Fixed with

6

Thank you @jow. I will build an image later today to verify on my hardware.

7

@jow - Build from master just now did give the expected behavior, but the rule was not active when the device booted. I had to manually start it.

# /etc/init.d/firewall status
inactive

# /etc/init.d/firewall stop  
Command failed: Not found

# /etc/init.d/firewall start

# /etc/init.d/firewall status
active with no instances

Is this to be expected?

It is symlinked to start:

# ls -l /etc/rc.d|grep fire
lrwxrwxrwx    1 root     root            18 Feb  7 11:05 S19firewall -> ../init.d/firewall
8

Can you provide a complete logread output after boot?

9

I am happy to. I think the log will disclose my public IP which I will sanitize. Are there any other piece of data that might be a privacy breach you can think of in the log? I do not believe it will include my wireguard interface client keys.

10

Can't think of any, but depends on your system configuration, installed package etc. You could just PM it to me if you like.

11

Done, had to split it into 2 parts due to character limit.

12

Thank you, please run the following command, then reboot and see if it works then:

sed -i -e 's#\tstart_service#\tstart#' /etc/init.d/firewall

(That sed script will replace the start_service call in the final boot() procedure with just start).

13

Before I try that, I should clarify. I think the reboot is a distraction.

I have this existing rule:

config rule
  option src 'lan'
  option target 'REJECT'
  option name 'Deny WAN access'
  option dest 'wan'
  list proto 'all'
  list src_ip '10.9.8.100'

I want to test the fw4, so I did this:

  1. Luci>Network>Firewall>Traffic Rules
  2. Edit my blocking WAN rule to add the IP address 10.9.8.112 to the rule
  3. Hit save then hit save and apply

Upon doing that, I can still access the WAN from 10.9.8.112. I therefore concluded that fw4 (or the luci interface) was broken somehow.

In order to have the rule take effect I need to reload the firewall.

/etc/init.d/firewall reload

The same is true if I delete the 10.9.8.112 IP and hit save then save and apply. LuCi updated to show that IP was removed, but WAN access is still denied on that device. Again, I had to reload the firewall.

Thoughts?

14

This is because the firewall service is not properly registered on boot, so the reload actions do not work until you stopped/started the init script at least once. The sed fix above should solve that.

3 Likes
15

You are correct. Running that sed onliner, then rebooting causes fw4 to behave as expected. I further tested by editing the rule to remove 10.9.8.112, save, then save and apply behave as expected. Did you edit the affected upstream code? I assume the issue will affect other users as well.

16

Yes, I am preparing some other fixes as well and will push an update later.

6 Likes
17

Thanks for your help to troubleshoot this and for all your contributes to this project :+1:

18

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.