Messages

It's been a while and I didn't receive any PM on how to set up qfeeds. Is the beta testing over or having enough accounts already ?

........
There is an use case to consider:

If an user with the free Community license starts to see a block for a particular Destination, there is no possibility to check why is that the case as the IoC lookup is not available to them. This can cause either a significant amount of tickets on your end or on the OPNsense forum end.
Would you maybe consider to allow IoC lookup as well for Community license but maybe limit it to 5 lookups per day?

With the IoC you're walking a very thin line. If tracking a new emerging threat you don't want to tip your hand. Otherwise if the information is public there's no reason to withhold that information.

Checking the IP history would probably most helpful here, and inspecting the traffic seeing if dealing with a formerly bad IP that may have been reused for legitimate purposes.

Hi Stefan,

Here are my initial thoughts from last week when the thread was new - I just didn't get to post it:

Hi Stefan,

The FW rule guidance in your manual is incorrect on a few counts and needs to be corrected:

1) The WAN interface will default deny any incoming connection. Unless providing external services and wanting to make sure the malicious IPs will not connect to your service - there's no real need to deny traffic source Q-Feeds.

2) The (v)LAN interface can never be the Source IP for the malware traffic blocked by q-feeds - unless you're actually hosting those networks behind OPNsense.

For the (v)LAN traffic the goal is to Reject (not drop) all traffic Destination q-feeds malware IPs. Another thing to note is that when applying the same rule to multiple interfaces you'll want to create a Floating Rule instead.


I'm interested to see how/if there's gonna be an overlap between packages needed to install q-feeds and packages provided by other repos, such as mimugmail. And since CE has a cadence of 2-3 weeks for a dot release the speed of fixing/adjusting q-feeds to the changes in core will be something to watch.

On a second read, there's a disconnect between the text and visual representation of the rule. The text is slightly better but for a I'm afraid many will default to reproducing the rule as visually depicted in the manual.


After reading the thread a few more ideas come to mind:

For the payed tiers - the 4h and 20 minutes update intervals may sound great on paper. In practice however with the added complexity a few things are bound to happen:

a) Low powered systems will be busy downloading parsing the new ip lists far too often and for a long time each time.

b) Especially on initial deployments where an alias dealing with false positives doesn't exist yet it may be disruptive for the enterprise and painful for the network admins having the playing field suddenly changing every so many hours or minutes.

I think it would be far better if the payed tiers would allow an arbitrary interval to be set, where the lower limit is what the plan allows. "Once a day" may prove to be a very popular choice regardless of the chosen plan.


These are just a few initial thoughts, I may be able to comment more once I get to test the plugin.


For anyone trying the plugin - don't forget to take a snapshot first. Murphy's always watching ;-)

New BIOS versions published for the following FWs:


DEC700 and DEC2700 series -- 08-2025 Version 34

Code Select Expand

BIOS Information
        Vendor: INSYDE Corp.
        Version: 05.39.21.0028-A10.34
        Release Date: 03/21/2025


DEC800 and DEC3800 & DEC4000 series -- 08-2025 Version 17

DEC4200 series -- 08-2025 Version 26 -- Already announced by AdSchellevis in Announcements



BIOS download page

The appropriate way would have been to change the Type from Development to Community in System -Firmware -Settings


What you did was destructive and risky - and uncalled for. But it was golden guidance from AI.

No should be all good this time. In case of an issue booting the older kernel will get you back to 25.4.

Snapshots are also an option but may be overkill for this particular issue.

A test kernel has been provided on Github by Stephan

Code Select Expand

opnsense-update -zkr 25.1.6-axgbe

With FreeBSD 14.3beta2 out, if this gets an actual fix I'd be surprised if it makes it prior to 14.4 upstream.

( With OPNsense that would most likely be included in the next dot release that has a kernel update and at least one test kernel before that )

Firewall - Diagnostics - Aliases

Click on Update Bogons, wait ~10-15 minutes then reboot

Actually there's an easier way to do it where two FWs are present. Requires a USB cable connected from one to the console of the other.

First you'd ssh into the controlling FW, drop to a shell, and use this command to open the serial line to the other:

Code Select Expand

cu -s 115200 -l /dev/cuaU0

Here are three links you should know about.


https://docs.opnsense.org/hardware/serial_connectivity.html#serial

https://docs.opnsense.org/hardware/serial_connectivity.html#legacy-uart

https://docs.opnsense.org/hardware/bios.html

@franco will certainly be interested in this issue. Your workaround should help narrow down the issue.

Does it matter from a performance or security perspective if I just never use the "wan" interface and continue to use the interface I created for Windstream?

No. (AFAIK)

Now my question is, how to proceed from here? Should I open an issue with FreeBSD?

Opening an issue with your findings on github opnsense/src would be a good first step.

[simplest]

- I don't want YADS (yet another DNS server)

Where the simplest DHCP server would work and there are no other fancy requirements - but AGH is a must - one could simply use the DHCP provided by AGH.

I know dnsmasq is used in some big projects like pi-hole and OpenWRT, however because in so many years there's been no interest in adding support for encrypted DNS protocols makes it a very hard sell for internet traffic next to unbound/knot/stubby/powerdns/AdguardHome.


For relatively basic dhcp services you really cannot go wrong with either ISC DHCP, ISC Kea or dnsmasq, and it's not like either will be going away anytime soon. The biggest headache is finding out which must haves are needed and where do they exist or have a chance of being implemented in the next few years.