Recent posts

#81
26.1 Series / Re: kea dhcpv6 hw-address in 2...
Last post by awlynn - Today at 06:42:52 AM
THe upgrade to 26.1_4 fixed the missing field.
#82
26.1 Series / Re: WiFi interface broken afte...
Last post by lss4 - Today at 06:07:56 AM
Quote from: apraile on January 31, 2026, 04:03:43 PMSame here on PC Engines APU2C4 and wle200nx card (Atheros AR9280).
The upgrade log is available at the following link, in case it is helpful:
https://paste.debian.net/hidden/22cde1ad

Thanks.



I just checked your upgrade log. It appears you have the same issue I encountered. On line 2285, "ath0: only 1 sta vap supported".

However, looks like you have two Atheros adapter installed. The other one (ath1) is not reporting that message, but neither is working.

Can you check if you have a "wlan0" (and "wlan1" in your case for your second adapter) interface with OPNsense 26.1? You can use "ifconfig" from console but Interfaces -> Overview will also work. From my experience, those interfaces would be in a red "no carrier" state.

Quote from: franco on January 31, 2026, 02:34:48 PMWould somebody check the logs for command errors? I have the feeling most reports around the last weeks omit obvious log entries in their installations.


Cheers,
Franco

I'm not seeing anything out of ordinary from that upgrade log, other than the line regarding "only 1 sta vap supported" which happened after finishing update from 25.7 to 26.1.

From my experience, that error message seems to be what was preventing OPNsense Web UI from adding new devices in Interface -> Wireless -> Devices. As soon as I tried adding a new device there and failed with error, I get that message printed on the console.

Still, I wonder what might be responsible for the creation of interfaces "wlan0" (without the ath0 prefix) that I saw with "ifconfig" or Interfaces -> Overview.
#83
26.1 Series / Re: Suricata - Divert (IPS)
Last post by xpendable - Today at 06:03:31 AM
I was initially on the same assumption as @RamSense, however that is not how it works.

So on hindsight and after more testing, I would suggest to only use Divert-to on WAN rules for existing services that are exposed to the internet. Like a VPN for example. Otherwise you end up with just suricata to block on an IPS match, which could probably lead to issues depending on what ports you have open. I only have 1 for my VPN, so I think I was lucky in this case.
#84
26.1 Series / Re: kea dhcpv6 hw-address in 2...
Last post by awlynn - Today at 05:28:59 AM
Unless I am missing something that does not appear in the WebGUI under Services - Kea DHCP - Kea DHCPv6 - Reservations
#85
Virtual private networks / Temporary Site-to-Site
Last post by dolomike - Today at 05:20:14 AM
Due to some renovation work being done on our building, we need to move everything out for a couple months until the construction is complete. The temporary building has internet but no static IP or inbound open ports (it's just a basic business service) so instead of ordering new service and updating all of our domains, we plan to keep an OPNsense system in place and and setup a site-to-site VPN (we have a small protected space we can keep during construction).   

It's my understanding that a site-to-site VPN requires different subnets on either end, so what would be the easiest way to setup this up with minimal network reconfiguration? Create the site-to-site and duplicate the WAN rules? We've never done a site-to-site, I'm sure it's easier when you're creating it from scratch, but not sure exactly how to do this for a fully active network with minimal changes.

Any suggestions would be appreciated!

 
#86
Hi everybody,

First time poster here. I have been running pfSense for about 10 years and OPNsense for 4 or 5. I am currently on version 25.7.

Last night, I started getting unrecoverable disk errors on my production server. The firewall is still up, but probably not for long, so this is urgent. I have another DL360 G7 lying around, so I am trying to build a replacement.

I spent the whole day troubleshooting with Gemini 3.0 Pro, but we are stumped. The AI suggested that because the G7 is strictly Legacy BIOS (MBR), we needed to manually partition the drive using gpart before installing. We did that, yet my RAID 1+0 (HP's RAID 1) volume refuses to boot.

I am using the 26.1 amd64 vga image on a USB stick. The installation seemed to complete successfully over the manually created MBR partition table, but the server won't boot from the hard drive afterwards. We have tried just about everything, and I feel like we are going in circles.

Is there a known issue with G7s and the newer installers, or am I missing a specific step for MBR booting?

Thanks, Alexander Dreyzen

PS. Resolved. As a Google investor, I hate to say this, but Gemini has really screwed the pooch (and me) on this one. GPT 5.2 figured it out in 2 minutes, seriously: logical volume boot order
#87
26.1 Series / Re: Suricata - Divert (IPS)
Last post by xpendable - Today at 04:34:50 AM
Quote from: muchacha_grande on January 31, 2026, 09:38:57 PM
Quote from: Monviech (Cedrik) on January 31, 2026, 08:59:17 PMNo packet is passed back to the firewall to match another rule on the same interface afterwards.

Does it mean that it doesn't matter the selection of pass, reject or block on the "divert-to" rule?

The firewall rule has to be a pass action, if you have divert-to selected and try to set it to anything else you will see an error in red text saying it must be a pass rule.
#88
26.1 Series / Re: Suricata - Divert (IPS)
Last post by xpendable - Today at 04:32:51 AM
Quote from: greY on January 31, 2026, 07:24:15 PM
Quote from: xpendable on January 31, 2026, 05:01:28 PMFor me my rule is simple, a new rule in Rules [New] on the WAN interface coming in to pass all traffic and Divert-to set to Intrusion Detection. This basically replicates my previous setup by capturing all packets for inspection, I don't want it to be more granular, maybe in an enterprise environment but not my homelab. The order is up to you, place the rule accordingly based on your other rules for the WAN interface.

NOTE: Divert-to is hidden and is only available in the "Advanced Mode", so be sure to enable that in the top left corner of the new rule dialog.

I use the WAN interface and add my ISP routers IP address to Home Networks in the suricata config, as far as I am aware this is the best method when using an IPS. As when on the LAN interface you may get more false positives and a lack of detection's since that interface is on your internal network. Intrusion attempts come from the external network in most cases, especially for homelab environments.

https://docs.opnsense.org/manual/ips.html#general-setup
https://docs.opnsense.org/manual/ips.html#advanced-options

Be careful: a broad WAN "pass any + divert-to" rule will effectively allow all inbound traffic on WAN. That can expose services running on OPNsense itself (e.g. SSH, DNS, GUI) to the internet.

It likely makes more sense to apply divert-to only on the specific WAN allow rules / opened ports you actually intend to expose.



Does not appear so, as @Monviech mentioned, the packet is diverted to suricata for the decision and nothing else. Just for peace of mind since I have a Q-Feeds subscription, I used their vulnerability scanner and found nothing. No open ports, no vulnerabilities, nothing.

EDIT: Actually I think you're right on this, my bad. When you pass any with divert-to, basically all "default deny / state violation" blocks no longer trigger. So probably is best to only set divert-to only on exposed ports. Feels like a noob mistake :(
#89
26.1 Series / Re: Suricata - Divert (IPS)
Last post by xpendable - Today at 04:28:00 AM
Quote from: muchacha_grande on January 31, 2026, 06:39:26 PMI have a (maybe dumb) question:

When using "divert-to" the matched packet is sent to Suricata to be inspected. After that, Suricata is responsible for the evaluation of the packet and not pf anymore.

Who is in charged of rejecting, blocking or passing the packet?

I can imagine that Suricata responds to pf with a verdict and is pf who blocks or pass the packet.


Suricata is in charge of rejecting the packet, so you need to configure your suricata policies accordingly to drop the packet.
#90
26.1 Series / Re: Suricata - Divert (IPS)
Last post by xpendable - Today at 04:26:25 AM
Quote from: jeffrey0 on January 31, 2026, 06:26:32 PM
Quote from: xpendable on January 31, 2026, 05:01:28 PMFor me my rule is simple, a new rule in Rules [New] on the WAN interface coming in to pass all traffic and Divert-to set to Intrusion Detection.

Will you need to set the rule direction to both? To capture outgoing traffic like malware calling home?

Quote from: xpendable on January 31, 2026, 05:01:28 PMAs when on the LAN interface you may get more false positives and a lack of detection's since that interface is on your internal network. Intrusion attempts come from the external network in most cases, especially for homelab environments.

And wouldn't you still detect external attacks if you only monitored within the LAN? At least all the traffic leaving the OPNsense router towards the LAN (traffic that gets through the firewall), which is presumably the majority of the data traffic?

You wouldn't detect an external incoming attack on the LAN, unless that traffic was somehow passed through the WAN interface to the LAN interface. You would probably need ports open on the WAN, or maybe using UPNP.