So I just upgraded to 26.1 and migrated the firewall rules over as well (don't have many) and everything went over smoothly with no issues.
However I was wondering about the new Divert (IPS) capture mode as the documents state that a firewall rule is needed in the new rules section. If you select this capture mode, will a new firewall rule by auto generated for it?
Also as a side question, if you diverted all WAN traffic for inspection anyway... would there be any benefit from Netmap (IPS) mode?
EDIT:
Well I just went ahead and enabled it, and basically answered my own questions :)
No rule is created automatically, so after setting suricata to Divert (IPS) mode with 8 listeners (8 CPUs) I created a new rule on the WAN interface just below the Q-Feeds rule to pass all incoming traffic to Intrusion Protection. Works as expected, and I suppose it's probably more efficient since it's using PF and coming after the Q-Feeds rule. No sense in inspecting blocked traffic.
However I noticed that after doing so the "Interface" in the Intrusion Protection Alerts page is blank, makes sense... but is there a way in the future to pull this information from the firewall rule?
EDIT 2:
Please read the whole thread for more context, however after further understanding in how divert-to works...
ONLY enable the divert-to setting in PF on existing rules on the WAN interface that exposes ports to the internet if you want to have them inspected by IPS, no additional PF rule will be applied for matching traffic after that point.
Hello, please open an issue on github asking about the interface in suricata when divert is used. Its easier to track, thank you.
https://github.com/opnsense/core/issues
Issue has been created as requested.
Another upside to using Divert (IPS) mode, the memory consumption has been cut in half since Netmap is no longer being used :)
What might also be a benefit is compatibility and stability with VM network interfaces as you dont have to use the emulated netmap driver anymore (the high performance native netmap driver requires intel network cards to work correctly most of the time).
That's true, my OPNsense runs as a VM on XCP-ng, however I use SR-IOV with Intel X710 NICs. So never had an issue with using Netmap, but using the Divert method is way more efficient on memory usage. I have 16GB of memory allocated and before the memory would typically sit at 40-50% usage. I just checked and it's now down to about 10%. Will probably reduce the memory allocation in the near future as the system obviously doesn't need it anymore.
Thanks for taking the lead. I just followed you and set intrusion detection from netmap to the new divert rule.
So far so good.
Curious about your choice to have it on incoming WAN instead of LAN?
What does the new divert rule look like?
https://docs.opnsense.org/manual/firewall.html#divert-to
The divert to can be added to any firewall rule that already exists, also multiple ones, to redirect the traffic to suricata after it matched in the firewall.
so, I guess I divert from the wan? What I am looking for is an example rule to start with.
Should it be the default lan pass rule?
For 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
Thanks!
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?
I 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.
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.
Quote from: greY on January 31, 2026, 07:24:15 PMQuote 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.
Thank you very much for this information!
Oh? thanks for sharing. My assumption was that is was something like this: the divert rule -> suricata allows -> on to the next firewall rule in wan in line, but not allow all.
That makes this divert rather different than a "blocklist" block and on to the next rule concept...
Divert means that after the firewall match, the decision is totally "diverted" to what listens on the divert socket. No packet is passed back to the firewall to match another rule on the same interface afterwards.
I understand now. So you have to change every allow rule you want to have inspected with suricata to divert.
Maybe it is an option to add a feature of "divert and return", so after a suricata allow -> opnsense goes furter with the next firewall rule in line?
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?
Quote from: jeffrey0 on January 31, 2026, 06:26:32 PMQuote 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.
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.
Quote from: greY on January 31, 2026, 07:24:15 PMQuote 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 :(
Quote from: muchacha_grande on January 31, 2026, 09:38:57 PMQuote 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.
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.
So, if this mode may be associated with a specific PF rule, how can I inspect normal browsing traffic (HTTP/DNS/FTP)?
I mean, in IPS/IDS mode I can just test Suricata with "curl http://testmynids.org/uid/index.html" and I see the alert, but this won't happen in Divert mode.
Quote from: Arien on February 01, 2026, 10:32:57 AMSo, if this mode may be associated with a specific PF rule, how can I inspect normal browsing traffic (HTTP/DNS/FTP)?
I mean, in IPS/IDS mode I can just test Suricata with "curl http://testmynids.org/uid/index.html" and I see the alert, but this won't happen in Divert mode.
So what I've done now is a more targeted approach I would say and have only added the Divert-to Intrusion Detection on my existing rules. I added it to my VPN rule for the WAN interface that exposes that port and I enabled it on the LAN default allow to any rule. Putting it on the default LAN out rule doesn't hurt, but the benefit may vary I suppose depending on your use case.
I would imagine if you added/enabled Divert-to Intrusion Detection on the "Default allow LAN to any rule", that would probably catch those tests. If you want to catch that traffic coming in on the WAN (as in initiated from the internet) and you have existing rules for those open ports, then you would add/enable Divert-to Intrusion Detection on those rules. However if you don't have existing rules for open ports, I would suggest to NOT create rules for that purpose.
I hope I didn't cause to much confusion from my earlier lack of understanding on how this new mode really worked.
if Suricata should fail. will the anti-lockout rules let me in?
My understanding is no. No application on divert socket = no traffic passing through.
Cheers,
Franco
Hi all,
great post. I have two small questions too.
1) What will happen for Nat Forwarding (now called "Destination NAT" in 26.1)? How you sent the traffic from these rules to suricata?
2) I only have 3 rules in my wan interface? One Block (For blocking traffic from Asia countries) and two rules for allowing openVPN and Wireguard. I understand I should configure at least the two allow rules to divert traffic to suricata but what happens with the block rule? I do nothing?
EDIT: PS. I have migrated my rules to the new Rules (New) section and delete all my previous rules.
Quote from: phanos on February 02, 2026, 12:22:53 PMI understand I should configure at least the two allow rules to divert traffic to suricata but what happens with the block rule? I do nothing?
If it is already blocked by the FW rule, it does not need to be diverted further.
Hi, regarding the Suricata crash issue with IPS Divert mode (https://github.com/opnsense/core/issues/9712), is anyone else affected by the same problem?
Quote from: QuisaZaderak on February 03, 2026, 08:45:42 AMQuote from: phanos on February 02, 2026, 12:22:53 PMI understand I should configure at least the two allow rules to divert traffic to suricata but what happens with the block rule? I do nothing?
If it is already blocked by the FW rule, it does not need to be diverted further.
Right but what about port forwarding? How you handle these? They do not seem to have direct to...
Hello,
sorry having a hard time understanding this DIVERT parameter.
So if i set FW rules to allow ports 443/80/5520 and then i create an additional FW rule with the same SRC/DST IP's then the 1ST rule would allow only the traffic on the ports defined and the second would send the traffic to the IPS?
or how is it possible to filter with DIVERT IPS?
as in the pic if i allow the 2 DIVERT rules?
Thank you all for the awesome work on this.
Quote from: szix96 on February 03, 2026, 03:07:59 PMHello,
sorry having a hard time understanding this DIVERT parameter.
So if i set FW rules to allow ports 443/80/5520 and then i create an additional FW rule with the same SRC/DST IP's then the 1ST rule would allow only the traffic on the ports defined and the second would send the traffic to the IPS?
or how is it possible to filter with DIVERT IPS?
as in the pic if i allow the 2 DIVERT rules?
Thank you all for the awesome work on this.
I think you confused protocol divert with Advanced Options -> divert to. Or I miss something..
Quote from: Ametite on February 03, 2026, 04:11:12 PMQuote from: szix96 on February 03, 2026, 03:07:59 PMHello,
sorry having a hard time understanding this DIVERT parameter.
So if i set FW rules to allow ports 443/80/5520 and then i create an additional FW rule with the same SRC/DST IP's then the 1ST rule would allow only the traffic on the ports defined and the second would send the traffic to the IPS?
or how is it possible to filter with DIVERT IPS?
as in the pic if i allow the 2 DIVERT rules?
Thank you all for the awesome work on this.
I think you confused protocol divert with Advanced Options -> divert to. Or I miss something..
Thank you, but i do not find it in the advanced settings in the FW rule just the protocol as divert.
edit: Found it in the new FW rules, so it is only available in the new rules, or is it also available in the legacy FW rules?
"To use the "Divert (IPS)" mode, you must use Firewall ‣ Rules [new] and create firewall rules that contain the "Divert-to" setting. Check the Rules manual for more information.
"
https://docs.opnsense.org/manual/ips.html (https://docs.opnsense.org/manual/ips.html)
https://docs.opnsense.org/manual/firewall.html#divert-to (https://docs.opnsense.org/manual/firewall.html#divert-to)
Hi!
I am not familiar with the details of the divert-to functionality in FreeBSD when it is implemented with pf, but when using ipfw there is an option to use reinject mode, where, if Suricata does not drop the packet, it reinjects it back into the network stack at the specified ipfw rule:
https://docs.suricata.io/en/latest/configuration/suricata-yaml.html#ipfw
Is there any plan to implement this somehow?
This would allow much finer-grained control, and the final decision would be made by the packet filter rather than by Suricata.
I am also not aware of whether a fail-open (bypass) mechanism exists for divert-to, similar to Linux NFQUEUE (queue-bypass), which switches to pass instead of drop if Suricata is not listening or crash...
Nope, I am quite sure these things are currently not implemented in FreeBSD at the moment. We're looking into improving support as divert becomes more popular on our end.
Cheers,
Franco