Automatically Generated Firewall Rules Interfere with WiFi Connectivity

[korgano]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• [x] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• [x] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug

Installing OPNsense to bare metal Intel N100 miniPC with Intel wireless, then creating a WiFi interface with the automatically generated firewall rules in the WebGUI prevents the WiFi interface from properly configuring via DHCP.

Disabling the firewall entirely allows proper DHCP address assignment/renewal and webGUI interactivity up until the firewall is re-enabled.

NOTE: I believe the automatically generated rules may also be a major cause of issues with transparent filtering bridges for users.

To Reproduce

Steps to reproduce the behavior:

1. Install OPNsense on a platform with an built-in WiFi adapter
2. Do first time log-on into webGUI
3. Go through process to add WiFi interface
4. Set interface to use DHCP for IPv4 and/or 6
5. Set log-in credentials for the WiFi interface
6. Allow creation of automatically generated firewall rules on that connection
7. Save and apply configuration, reboot if necessary
8. Log into console, see that WiFi interface will not obtain IP address
9. Disable the firewall through webGUI or console shell
10. Restart WiFi service/reboot device
11. The console should show the WiFi interface has an IP addressed assigned to it

Expected behavior

The WiFi adapter getting an IP address from the router with no issues, being accessible through the WiFi interface's IP address., and being able to properly connect to the appropriate NTP/update servers.

Describe alternatives you considered

7127 and #7783 are highly relevant, as this problem cannot be further troubleshot without the ability to selectively enable and disable the automatically generated rules to determine which rule or rules are responsible for the issues.

Screenshots

Firewall enabled, connected on WiFi OPT1 interface before IP address lease expires

Firewall rules on WiFi OPT1 interface:

Environment

OPNsense 24.7.5 (amd64).

[AdSchellevis]

You can easily debug the effect of these rules by editing /tmp/rules.debug and after modifying the ruleset, apply changes using pfctl -f /tmp/rules.debug.

Looking the logs, it's just highly unlikely any of the default rules have an effect here (most of them don't precede custom rules). Policy based routing might have an effect, when debugging "simple" setups, always try with "Disable force gateway" set in "Firewall: Settings: Advanced" as well.

Often these drops are a result of asymmetric routing causing state violations, believe me, the packet capture in OPNsense is your biggest friend debugging all kinds of issues....

[fichtner]

I don't understand your problem to be frank. Inspect the dropped packets.. all TCP, probably RST flags with no data or similar.. This is normal in busy wifi networks and the state tracking just drops it because it is garbage after all?

Cheers, Franco

[korgano]

You can easily debug the effect of these rules by editing /tmp/rules.debug and after modifying the ruleset, apply changes using pfctl -f /tmp/rules.debug.

After experimenting with this, I've found that that disabling the IPv4 Default deny/state violation rule pretty consistently allows the WiFi adapter to receive DHCP and allow me to access the webGUI with little to no issues (at least until the connection resets).

(Seriously, the IP address field for the WiFi interface was blank, then I edited the rules.debug file to disable that rule, saved and executed the firewall command, and as soon as I exited the shell, it had the IP address.)

Couldn't really get anything from packet capture, but I'm not sure it's because I didn't set it up right, or I just wasn't blasting it with enough packets.

Also, there may be some relationship with a FreeBSD Intel WiFi driver bug, but I can't make any definitive statements on that unless I'm able to disable the rule in a way that persists across service restarts/reboots.

[AdSchellevis]

If you want to turn your firewall into a brick (allowing all), you might as well add a stateless rule allowing all in both directions or disable the firewall, the default deny rule is more or less the standard in all firewalls to set drop as last resort when nothing else was specified matching your traffic (https://docs.freebsd.org/en/books/handbook/firewalls/#pf-tutorial).

You really want to figure out why you can't capture traffic as in the traffic will be the answer to your questions...

[korgano]

Been doing some tests with packet capture to see if it can provide any useful information, and it seems like there's some rate limiting or something else going on with the capture, because I keep cranking the number down from 100, and it never auto-completes the capture if I pick a number above 15 or so. This occurs even in promiscuous mode.

I crosschecked with Wireshark on a different system with a capture filter for the wifi interface's IP address, and I had over 100 packets captured inside of 11 seconds.

(I have to run the device with firewall disabled to do this, because even with an allow all out rule and rules allowing IPv4 HTTP and HTTPS in, I cannot log into the webGUI if the auto gen rules are in effect.)

[korgano]

Looking the logs, it's just highly unlikely any of the default rules have an effect here (most of them don't precede custom rules). Policy based routing might have an effect, when debugging "simple" setups, always try with "Disable force gateway" set in "Firewall: Settings: Advanced" as well.

From some quick looking around, I think I'm running into this error that has been noted on the OPNsense forums: Regular LAN Traffic hits Default deny / state violation rule since 24.7

It seems that OPNsense cannot detect/will block TCP packets with certain states, causing some/most of the connectivity issues.

[AdSchellevis]

usually just broken traffic, but if you care less about traffic correctness, you can always use sloppy states (https://man.freebsd.org/cgi/man.cgi?pf.conf(5))