Messages

Sequential server queries continue to work normally for me under 24.7.12

Learning has always been slow and painful for me.
Thanks.

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.

If you check "System - Configuration - Backups" you can check the restore areas, there Dashboard exists. So I think you could import it from a backup.

This dashboard option seems to be gone. I thought the Dashboard info might be in WebUI portion of the backup but that doesn't do it. Any idea what 'restore area' it's backed up in now?

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.

1. Ever since the OpenVPN custom options privilege escalation debacle in 2019 that affected *sense and prior widespread use of "just let us have custom configuration fields for all services" we decided to remove these ticking time bombs proactively and block their inclusion... slowly but steadily.

https://github.com/opnsense/changelog/blob/17ab9aee2c11fcaf811245b0b9a5e23a7c48a34f/community/19.1/19.1.8#L36

2. From a product perspective advanced users will add their custom glue and deprive meaningful use cases from the not so advanced users. It's better to work together and find GUI-driven solutions to problems everybody has.

3. For anyone saying "The GUI can't do this but when I edit the config file it gets overwritten" we usually advise to avoid using the GUI (core or plugin) and just use the service like anyone would on FreeBSD. Most decline, hence (2) is better in the long run anyway.

Cheers,
Franco

Franco,

Fuck you. I'm advanced enough to use the unbound config because I fucking learned how to do it because I needed to for the functionality. You just pushed that further out of reach. Now I have to jump through more fucking hoops in the name of protecting who? The less advanced don't know enough to break it.  fkja;lkadsf.,lk I can't fucking express how fucking mad I am. Not because you did it, but because your reasoning is so fucking broken. I wish I had paid for opnsense so I could dispute the charge, so I could demand my money back. I wish you had a patreon I supported so I could pull it.

This is worth nothing so don't waste time reading it.

I'm not interesting in protecting the incompetent from themselves by concealing functionality. I have screwed my self in the router department many times over the years; it's how I learned. What I am interested in is a highly configurable router, which is why my WRT54G was my last off-the-shelf router.

1) It's not as if someone can type gibberish into the custom options field and hit save and their internet stops working. They're going to have to research actual options and enter something correctly formatted to have any effect. That's a far greater barrier to damage than having check boxes and drop down menus that can be scrambled like a Rubik's Cube.
2) They had to elect to use Unbound in the first place. If they break it, they can fix it or switch back on the default resolver.
3) There's already an marvelous undo button in the form of the System > Configuration > History page which lets one very effectively roll back the clock.

A GUI enhances the accessibility and usability of the underlying services; where does the mandate to curtail and conceal functionality come from?

Given these points, I find the given reason of trying to protect the incapable from themselves to be irrational.

edit: I forgot about reading this shit two weeks ago and hit the upgrade button. 2 seconds later I remembered. Now I wish I could set something on fire. You just culled functionality in the name of user friendliness. FUCK. THAT. fuckyoufuckyourmom.

Can the element in question be rolled back to what was used in 20.1? Add a watchdog to restart it or make restarting radvd an option in the cron task menu?

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

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.

I had a similar problem after importing my 19.1 config into a fresh 19.7 install. Under Interfaces > WAN port, I changed "IPv6 Configuration Type" from DHCPv6 to SLAAC, applied, the changed it back to DHCPv6, and applied again. If you need to customize the DHCPv6 settings for your ISP, don't forget.

<internal frustration after having composed a post and now having to recompose after clicking the wrong button in my browser>

I would suggest setting a gateway in the LAN firewall rule(s) intended to permit traffic through the WAN connection.

I would also suggest careful review of the automatic outbound NAT rules. I remember making a pained and confused expression when I first looked at the automatically generated outbound NAT rules, right before I wiped them out and manually created my own outbound NAT rules.

Here is an example from my primary LAN subnet on my home router. Sorry for the small print, I had to zoom out to screenshot it all at once.





I have separate rules for IPv6 traffic and other stuff but this should give you a good starting reference for something that works.