Topics

I just started playing with Gateway Groups and in the course of doing this I was experimenting with firewall rules for a particular subnet. I soon noticed the rules showing as enabled and disabled were not reflective of what the firewall was actually letting through. My frustration, self-doubt, and confusion ultimately led to this:

http://nothingunreal.com/dump/opnsense.2024-12-07.fwRuleDesync.PNG

I don't have a certificate for https, sorry.

The pings are coming from a VM on my so-called "DMZ" subnet to the OPNsense DMZ interface address. I would expect there to be no reply given the active rules.

• First I checked the automatic rules to see if somehow there was something in there that would let pings through. No, of course not.
• I tried restarting the firewall service via the services widget on the dashboard with no effect.
• I tried option 11 from the console to reload all service with no fix.
• I rebooted the system and then it works as expected and there is no ping reply from the firewall on that subnet.

I did a bunch of enabling, disabling, and applying of FW rules and rebooting. By no means exhaustive.

Ultimately it seems a rule controlling IPv4 ICMP traffic to an interface address may only get one successful toggle-and-apply but more often none, requiring a reboot for a change to take effect. I confirmed the same behavior on my VM incarnation of OPNsense. Both running 24.7.10_2

I don't mean exclusively "ICMP rules" but creating/enabling a blanket block or reject all protocols to the interface also fails to stop ping replies (as in the screenshot).

Simplest way to reproduce I can suggest is making a rule to pass or block pings to an interface, start a repeating ping from some host, and toggle the rule several times and see if the replies start and stop as you would expect.

I have not noticed unusual behavior from any other rules. They continue to pass or block, enable or disable as expected, on command.

p.s. Just as I'm wrapping up, it occurred to me to try a rule blocking ICMP to an external address. I started a ping to 8.8.4.4 then created a new rule to block the ping. No interruption. Reboot and the pings aren't going through.

This issue has followed me from 21.1 on hardware to 22.7 on ESXi 7. After approximately 2 minutes of up time, one CPU core will be maxed out. System►Diagnostics►Activity shows netisr is the culprit. Googling suggests this is usually due to high traffic yet this exists regardless of traffic level and it doesn't seem to limit throughput in any practical way; though my downlink is only ~275mbps. I have tried stopping all the services I could and that didn't cause any change. Restarting Packet Filter, System routing, System turntables had no noticeable impact (though its possible they restarted so quickly I wouldn't have seen an impact). It's almost a cosmetic problem aside from extra power consumption. Any thoughts or suggestions on where the problem might be? I'm thinking bad configuration on my part, somewhere, has lead to something going in circles but not sure where.

Nothing listens on link-local addresses which means I have to manually update configurations in the event of a new Delegated Prefix. It's not frequent but in the event of an ISP outage or extended power outage I have to update addresses used for NTP, DNS, DHCP, and Router Advertisements. God help me once I have to start putting IPv6 addresses into firewall rules.

Examples:
Unbound and Pi-Hole both don't listen on link local addresses
Windows can w32tm /stripchart the link local address on my NTP appliance but it won't actually use it as a time source.
I can't use OPNsense's NTPd link local as a time source and it can't use link local IPs as a server.

Does everyone do this manually or am I a sucker?

Would someone please confirm Win's w32tm can /stripchart an IPv6 link-local address but can't sync time with the same link-local address?

It would be handy since the 'real' IPv6 address might change after an ISP outage or whatever.



Thank you

I'm running OPNsense 20.1.7


01:04:00:00:00:02 tells Windows clients to disable NetBIOS
01:04:31:41:50:43 tells APC devices to take what they're given

Only the bottom line configured here applies to clients. So either I can have the APC line last and use DHCP to configure APC devices or I can put the NetBIOS line last and windows clients will automatically disable NetBIOS. I do not know if the issue is with the router sending out only the last one or if the APC and windows DHCP clients are both flawed coincidentally only recognizing the last option.

I'm running OPNsense 20.1.7 under ESXi 6.7.0 Update 2 and I'm using a Ubiquity UniFi AP AC LR wireless access point. When the access point comes online, something like 90 seconds after either after being plugged in or rebooting it, the router crashes and reboots. It works fine for weeks at a time otherwise. I suspect it's the influx of clients (10-15 wireless), possibly the DHCP requests (only a guess) that causes the problem.

I captured the initial error that displays on the console only once out of half a dozen tries ;)

Here is a capture of the console during the crash/reboot
https://youtu.be/rFsSlnSVIDc
Though I doubt it would be of much use since VNC is updating at only 30FPS; probably at least a page of missing info between frames.

Nothing under System > Log Files looks even vaguely pertinent. The Web GUI does not prompt to submit a report after these reboots occur.

There's an issue with the DHCPv4 gateway assignment that has been around since I started using OPNsense, around 16.X.

Gateway assignment behavior is not always consistent with the described operation.


Tonight I was futzing with DHCP settings and eventually figured out how to reproduce it consistently (as much as that word can be applied).

I have four internal interfaces that all operate on em0. OOB is untagged; LAN, MGMT, and PIA are tagged vlans. If I leave the gateway assignment blank in the DHCPv4 settings for all interfaces then each is assigned the corresponding interface address as the gateway via DHCP. If I manually specify a gateway for one of the interfaces, the rest still work correctly; a blank entry results in the interface address being assigned as the gateway. The problem comes up if I specify "none" (without quotes) as the gateway for one of the DHCP configurations.

This 'table' should only be read horizontally. "none" indicates I have specified "none" as the gateway on that interface and left the gateway assignment blank for the other three. "yes" means a gateway was assigned. "no" means a gateway was not assigned.
LAN=none      LAN=no        MGMT=yes       OOB=yes       PIA=no
MGMT=none     LAN=no        MGMT=no        OOB=no        PIA=no
OOB=none      LAN=no        MGMT=yes       OOB=no        PIA=no
PIA=none      LAN=yes       MGMT=yes       OOB=yes       PIA=no


As you can see, using "none" on any one of the interfaces results in some or all of the other interfaces no longer assigning gateways. The exception being PIA which never gets a gateway assignment if "none" is used on any of the others but if I use "none" on PIA then the other three continue to work as expected. I did not try using "none" on more than one interface at a time as it would take much longer to try all the combinations and I doubt it would clarify the underlying issue. On the up side, specifying "none" does consistently result in no gateway being assigned on the intended interface.

The workaround is simply to manually specify the gateway IP for interfaces that don't get the interface IP when the gateway field is left blank.

I should note that when I started using OPNsense it was as a VMware virtual machine and in that instance each interface was configured as an individual NIC, not as VLANs. I migrated to bare metal shortly after 17.1.

What further info can I provide to help out?

It is my understanding that when using Dnsmasq as a forwarder, queries to each DNS server would go out through a prescribed gateway (if one is specified) in System: Settings: General:


However, in Services: Unbound DNS: General: a gateway interface(s) must be specified over which queries will be sent:


I would like to understand which takes precedence when using Unbound as a forwarder. If it is the Unbound configuration, am I correct in assuming the gateway granularity is lost (can't dictate which gateway to use for which DNS server)?

[__awful__]

I've been using opnsense for something like a year. No problems at home, just installed and I've been updating every time an update comes out. Now I'm just trying to setup a totally new opnsense system and it seems like I have no choice but to sit through this 30+ minute boot-up to the live environment and then what? I've been googling trying to find out how to "fix" this incredible boot time and in doing so I read that after this BS I have to then clone the live-cd system to the disk via command line ( https://forum.opnsense.org/index.php?topic=4649.0 ) ? That's not covered in the documentation ( https://docs.opnsense.org/manual/install.html ), in fact, the installation doesn't seem to be covered in the installation documentation at all. The end result may be great but this is now an __awful__ installation experience.

I'm sure it's all in my head, but I could swear my router is more responsive. Everything feels faster.

Crammed it all into the title. Don't know how it was before 17.1.8 (probably because I didn't have room to try) but if more than two IPv6 DNS servers are specified in System: Settings: General then radvd won't start. Works fine with two IPv6 DNS servers and as many as four IPv4 DNS servers. Haven't tried with more than that but with three or four IPv6 DNS servers, regardless of how many IPv4 servers specified down to zero, it would not work. Didn't try with any more than four IPv6 DNS servers.

Maybe this is a know design limitation of the component, not sure, but I didn't come across anything related when I searched the forum.

Hello.
Thanks to everyone here for helping build this community and opnsense.

I'm trying to upgrade from 16.7.14_2 to 17.1. My router is virtualized running on a VMware ESXi 6.5 host. The update process looks very smooth, it reboots and everything loads quickly/normally to a point. After that point, the display updates line, by bloody line. Like I'm watching some text load up in a console over a 2400 baud connection.

This begins with logging in and starting the installation
https://youtu.be/8UM0aBXRSkA

This skips to where the installation has completed and the system reboots. The problem starts 10 seconds after:
https://youtu.be/8UM0aBXRSkA?t=1m10s

This is a video capture I made of the installation process. The problem starts 1:19 into the video. I've let it sit for  a couple hours but it didn't finish loading. During this time the CPU usage goes to 100% and memory stays flat at 2.15GB/4GB. I've tried tweaking the VM settings like changing the Guest OS setting, increasing and decreasing video memory, disabling vmware tools checks, but it always has the same problem during the initial boot following the console initiated update.

Thanks for any input.