"Recent posts
#1
Virtual private networks / Automatic WireGuard initalizat...
Last post by Monju0525 - Today at 06:00:45 PMHad problems connecting to wg0 interface that required re-starting wg0, so I am sharing my monit implementation.
It is equivalent to re-starting/toggling the dashboard's WG.
Monit needs to start first (3 to 4 minutes) before Monit re-starts WG.
Tested under OpnSense 26.1.10
Monit Implementation
Steps
#1 Set Opnsense Monit Service setings and Service tests settings
#2 Add wg0_monit_start.sh
#3 Service -> Monit -> Status
#1
Opnsense Services Monit
Service Settings
Name: wg0_monit_start
Type: custom
Path: /usr/local/bin/bash /usr/local/opnsense/scripts/wireguard/wg0_monit_start.sh
Start: /bin/sh -c '/usr/local/sbin/pluginctl -s wireguard restart'
Tests: ZeroStatus
Service Tests Settings
Name: ZeroStatus
Condition: status == 0
Action: Start
#2
nano /usr/local/opnsense/scripts/wireguard/wg0_monit_start.sh
======
#!/bin/bash
# RC is the connection state which defaults = 1
RC=1
# Test wg0 connection state and if no packets are received it needs to be restarted with RC=0
# RC=0 uses the ZeroStatus test to re-start wg0
[[ $(netstat -i | grep -F -- " 0 - " | \
grep "VPN Instance Tunnel IP address" | wc -l) -eq "1" ]] && RC=0 && echo !connected && exit $RC \
|| echo connected && exit 1
======
chmod + /usr/local/opnsense/scripts/wireguard/wg0_monit_start.sh
#3
Program 'wg0_monit_start'
status OK
monitoring status Monitored
monitoring mode active
on reboot start
last exit value 1
last output connected
data collected Fri, 19 Jun 2026 11:49:02
====
It is equivalent to re-starting/toggling the dashboard's WG.
Monit needs to start first (3 to 4 minutes) before Monit re-starts WG.
Tested under OpnSense 26.1.10
Monit Implementation
Steps
#1 Set Opnsense Monit Service setings and Service tests settings
#2 Add wg0_monit_start.sh
#3 Service -> Monit -> Status
#1
Opnsense Services Monit
Service Settings
Name: wg0_monit_start
Type: custom
Path: /usr/local/bin/bash /usr/local/opnsense/scripts/wireguard/wg0_monit_start.sh
Start: /bin/sh -c '/usr/local/sbin/pluginctl -s wireguard restart'
Tests: ZeroStatus
Service Tests Settings
Name: ZeroStatus
Condition: status == 0
Action: Start
#2
nano /usr/local/opnsense/scripts/wireguard/wg0_monit_start.sh
======
#!/bin/bash
# RC is the connection state which defaults = 1
RC=1
# Test wg0 connection state and if no packets are received it needs to be restarted with RC=0
# RC=0 uses the ZeroStatus test to re-start wg0
[[ $(netstat -i | grep -F -- " 0 - " | \
grep "VPN Instance Tunnel IP address" | wc -l) -eq "1" ]] && RC=0 && echo !connected && exit $RC \
|| echo connected && exit 1
======
chmod + /usr/local/opnsense/scripts/wireguard/wg0_monit_start.sh
#3
Program 'wg0_monit_start'
status OK
monitoring status Monitored
monitoring mode active
on reboot start
last exit value 1
last output connected
data collected Fri, 19 Jun 2026 11:49:02
====
#2
26.1, 26,4 Series / Re: VLAN - DHCP/Gateway Issue ...
Last post by pfry - Today at 05:33:26 PMQuote from: Mark_the_Red on Today at 04:45:01 PM[...]Is there a "MAKE THIS god dam @#$@!#%@# device / MAC address move to this VLAN!!!" hidden setting somewhere in the DHCP menu?[...]
Just to clarify, where are you looking to have the VLAN tag assigned, and by what mechanism? I'd generally expect that to be via a managed Ethernet switch, either by port or by MAC (or possibly other differentiators depending on your hardware, but I stick to "port").
#3
General Discussion / Re: 802.1x certificate for the...
Last post by lmoore - Today at 05:24:26 PMThere isn't enough information what the WAN port would be connected to.
It could be a port on an infrastructure switch requiring authentication, we don't know.
Perhaps wpa_supplicant could be used but I don't know if one of the EAP methods supports Certificate Authentication Greg is mentioning.
This package is already installed in my OPNsense. I don't use it and I don't know if it's included in a default install.
Looking at the sample configuration file (/usr/local/etc/wpa_supplicant.conf.sample) under the "AP scanning/selection" section, the value of 0 is described as;
I don't know how this would be configured in OPNsense, however, this site has a configuration for a wired device - https://skybert.net/linux/wired-network-with-8021x-authentication/
It could be a port on an infrastructure switch requiring authentication, we don't know.
Perhaps wpa_supplicant could be used but I don't know if one of the EAP methods supports Certificate Authentication Greg is mentioning.
This package is already installed in my OPNsense. I don't use it and I don't know if it's included in a default install.
Looking at the sample configuration file (/usr/local/etc/wpa_supplicant.conf.sample) under the "AP scanning/selection" section, the value of 0 is described as;
Quote# AP scanning/selection
.
.
.
# 0: This mode must only be used when using wired Ethernet drivers
# (including MACsec).
I don't know how this would be configured in OPNsense, however, this site has a configuration for a wired device - https://skybert.net/linux/wired-network-with-8021x-authentication/
#4
26.1, 26,4 Series / Re: VLAN - DHCP/Gateway Issue ...
Last post by Patrick M. Hausen - Today at 05:24:25 PMYou need to assign the switch port the device is connected to to the particular VLAN for this device. The end devices are oblivious of VLANs, this is all managed by the network infrastructure.
#5
General Discussion / Re: 802.1x certificate for the...
Last post by pfry - Today at 05:18:13 PMLooks like it's done via wpa_supplicant (wired and wireless) and/or hostapd (wireless only, apparently). Interface differentiation for wpa_supplicant seems to be via command-line parameter only - seems to hinder automatic setup of multiple supplicants.
#6
Intrusion Detection and Prevention / Suricata: no alerts ever fire ...
Last post by digital_mhc - Today at 05:09:20 PMSuricata: ET Open/abuse.ch ruleset produces zero alerts despite correct config — possible rule-files template issue (OPNsense 26.1.10)
Disclaimer: I'm new to OPNsense/Suricata and security topics in general, and worked through this with AI assistance (asking it to help interpret logs and summarize findings here). Apologies if I've made any beginner mistakes along the way — happy to be corrected on any of this.
Environment:
Symptom
After enabling these rulesets and creating a Policy (action: Alert) covering all of them, I got zero alerts, from nmap SYN scans against both the firewall and the server behind it, and from a plain-HTTP EICAR test-file download. Traffic capture itself seemed to be working fine — eve.json showed correct flow logging for all this traffic — so it looked like a rule-matching problem specifically, not a capture problem.
What I found
Checked Suricata's startup log and saw:
with a YAML warning on every start:
Looking at the generated suricata.yaml:
suricata.rules doesn't exist anywhere on disk. The actual rules are correctly staged as 16 separate per-category files and referenced via installed_rules.yaml's own rule-files: list (included via include:). It looks like these two rule-files: entries collide, and the dead reference wins, so nothing loads.
Tracing further, this dead reference seems to come from OPNsense's own template:
So it looks like the template may not have been updated to match how the rule-compilation backend (installRules.py) actually generates rules now (per-category files + manifest, not one combined file). I could be wrong about this being the root cause, but it's what the evidence pointed to.
What did work
To check whether Suricata itself was capable of alerting at all (vs. specifically the bulk ruleset), I manually staged a simple custom rule outside the normal Download/Policy flow based on the blog here (https://medium.com/@hariharanss/exploring-ids-ips-network-security-custom-rules-with-opnsense-suricata-5406947d2151):
(sed -i '' is FreeBSD syntax — the empty string is required there, not a typo.)
This rule fired correctly on the first test (nmap -sS), with a proper alert showing correct source/dest/port/interface. So the engine itself seems fine — the issue seems confined to the bulk Download/Policy ruleset specifically.
Questions
I apologise in advance if I'm slow to provide more logs/diagnostics. I'm on a deadline and need to move on to other security topics now.
Disclaimer: I'm new to OPNsense/Suricata and security topics in general, and worked through this with AI assistance (asking it to help interpret logs and summarize findings here). Apologies if I've made any beginner mistakes along the way — happy to be corrected on any of this.
Environment:
- OPNsense 26.1.10
- Suricata 8.0.5
- Capture mode: PCAP live mode (IDS)
- Pattern matcher: Aho-Corasick ("Ken Steele" variant)
- Interfaces: LAN + WAN, promiscuous mode enabled
- Rulesets enabled: abuse.ch/ThreatFox, abuse.ch/URLhaus, ET open/botcc, ET open/botcc.portgrouped, ET open/emerging-attack_response, ET open/emerging-exploit, ET open/emerging-exploit_kit, ET open/emerging-scan, ET open/emerging-malware, ET open/emerging-shellcode, ET open/emerging-web_server
Symptom
After enabling these rulesets and creating a Policy (action: Alert) covering all of them, I got zero alerts, from nmap SYN scans against both the firewall and the server behind it, and from a plain-HTTP EICAR test-file download. Traffic capture itself seemed to be working fine — eve.json showed correct flow logging for all this traffic — so it looked like a rule-matching problem specifically, not a capture problem.
What I found
Checked Suricata's startup log and saw:
Code Select
1 rule files specified, but no rules were loaded!with a YAML warning on every start:
Code Select
Info: conf-yaml-loader: Configuration node 'rule-files' redefined.Looking at the generated suricata.yaml:
Code Select
default-rule-path: /usr/local/etc/suricata/opnsense.rules
rule-files:
- suricata.rules
...
include:
- installed_rules.yamlsuricata.rules doesn't exist anywhere on disk. The actual rules are correctly staged as 16 separate per-category files and referenced via installed_rules.yaml's own rule-files: list (included via include:). It looks like these two rule-files: entries collide, and the dead reference wins, so nothing loads.
Tracing further, this dead reference seems to come from OPNsense's own template:
Code Select
grep -r "suricata.rules" /usr/local/opnsense/service/templates/
/usr/local/opnsense/service/templates/OPNsense/IDS/suricata.yaml: - suricata.rulesSo it looks like the template may not have been updated to match how the rule-compilation backend (installRules.py) actually generates rules now (per-category files + manifest, not one combined file). I could be wrong about this being the root cause, but it's what the evidence pointed to.
What did work
To check whether Suricata itself was capable of alerting at all (vs. specifically the bulk ruleset), I manually staged a simple custom rule outside the normal Download/Policy flow based on the blog here (https://medium.com/@hariharanss/exploring-ids-ips-network-security-custom-rules-with-opnsense-suricata-5406947d2151):
Code Select
echo 'alert tcp any any -> 192.168.10.10 any (msg:"Possible Nmap SYN scan detected"; flow:stateless; flags:S; threshold:type both, track by_src, count 5, seconds 1; classtype:attempted-recon; sid:9000001; rev:1;)' > /usr/local/etc/suricata/opnsense.rules/custom-nmap-test.rules
sed -i '' 's/rule-files:/rule-files:\n - custom-nmap-test.rules/' /usr/local/etc/suricata/installed_rules.yaml
pkill -f suricata
sleep 3
service suricata start(sed -i '' is FreeBSD syntax — the empty string is required there, not a typo.)
This rule fired correctly on the first test (nmap -sS), with a proper alert showing correct source/dest/port/interface. So the engine itself seems fine — the issue seems confined to the bulk Download/Policy ruleset specifically.
Questions
- Is this a known mismatch between the template and the current rule-compilation backend?
- Is there a supported way to fix rule-files so it survives the next rule update/regen?
- Has anyone else hit this on 26.1.10?
I apologise in advance if I'm slow to provide more logs/diagnostics. I'm on a deadline and need to move on to other security topics now.
#7
German - Deutsch / Re: Firmware Update Notificati...
Last post by Most - Today at 05:00:00 PMUPDATE_AVAILABLE: Current version: OPNsense 26.4.1, Available version: OPNsense 26.1.10. Irgendwie funktioniuert es nicht mehr..
#8
German - Deutsch / Re: "Lahmes" Internet seit Upd...
Last post by fastboot - Today at 04:50:10 PMIch glaube, hier reden wir gerade über zwei unterschiedliche Setups. 🙂
Das Vigor 167 läuft im Bridge-Modus und die OPNsense macht die PPPoE-Einwahl selbst. In dem Fall gibt es ja eigentlich kein geroutetes Transfernetz zwischen DrayTek und OPNsense und auch kein Gateway auf dem DrayTek, das auf dem WAN der OPNsense eingetragen werden müsste. Nebenher kann man dann tolles Doppel-NAT machen... Kann man machen, aber man kann es sich auch ersparen. Denn dafür hat er alles nötige da...
Die einzige IP die das Vigor Modem hat ist die Management IP. Und hier gibt man einfach dem physischen Interface an der OPNsense, wo das Modem dran hängt, eine /30 aus dem Mgmt Netz...
Die eigentliche Frage des OP war für mich eher, wie er möglichst einfach von seiner alten Installation auf die neue Protectli migrieren kann.
Ich würde ganz klar neu installieren und von Scratch konfigurieren. Bei dem ewig wiederkerhrenden mach doch mal "ANY ANY" auf, bekomme ich ehrlich gesagt Bauchschmerzen.
Eine Standardkonfiguration für eine Sense ist in wenigen Minuten eingerichtet. Fine Tuning kommt später...
Das Vigor 167 läuft im Bridge-Modus und die OPNsense macht die PPPoE-Einwahl selbst. In dem Fall gibt es ja eigentlich kein geroutetes Transfernetz zwischen DrayTek und OPNsense und auch kein Gateway auf dem DrayTek, das auf dem WAN der OPNsense eingetragen werden müsste. Nebenher kann man dann tolles Doppel-NAT machen... Kann man machen, aber man kann es sich auch ersparen. Denn dafür hat er alles nötige da...
Die einzige IP die das Vigor Modem hat ist die Management IP. Und hier gibt man einfach dem physischen Interface an der OPNsense, wo das Modem dran hängt, eine /30 aus dem Mgmt Netz...
Die eigentliche Frage des OP war für mich eher, wie er möglichst einfach von seiner alten Installation auf die neue Protectli migrieren kann.
Ich würde ganz klar neu installieren und von Scratch konfigurieren. Bei dem ewig wiederkerhrenden mach doch mal "ANY ANY" auf, bekomme ich ehrlich gesagt Bauchschmerzen.
Eine Standardkonfiguration für eine Sense ist in wenigen Minuten eingerichtet. Fine Tuning kommt später...
#9
26.1, 26,4 Series / VLAN - DHCP/Gateway Issue - As...
Last post by Mark_the_Red - Today at 04:45:01 PMNeed some help. I exhaustedly tried Claude and ChatGPT to solve this, but I can't seem to figure it out. I cannot assign a physically ethernet connected device to the VLAN under any circumstances. VLAN interface is working great.
Topography is as follows
OPNSENSE router -> Switch with POE+ -> Unifi U6E Access point -> no problem assigning devices to VLAN (IoT) via wifi (works chef's kiss perfectly)
|
-> LAN connnected devices -> will not under any circumstance assign to VLAN (IoT) PROBLEM
I followed this helpful guide to get the Unifi set up (NAT, VLAN Interface, etc.). I confirmed the Unifi device is 100% NOT doing anything with DHCP (even warns me in the controller software its doing nothing) and OPNsense is, and its working perfectly. The switch is passing VLAN tags along perfectly as it works for the AP so its not a switch issue:
https://www.youtube.com/watch?v=CmC_AuoAmvs
All the DHCP VLAN ranges are set up correctly, because the access point is assigning them in that range.
Is there a "MAKE THIS god dam @#$@!#%@# device / MAC address move to this VLAN!!!" hidden setting somewhere in the DHCP menu? DHCP lease time has no effect. I tried assigning static ip addresses (Host) to the devices on the VLAN DHCP range and it never works. It makes an entry but the device NEVER moves over. I even disabled the LAN network it is currently assigning these devices to incorrectly, and the devices would rather get NO connection then go to the VLAN one. I know its a DHCP issue but I looked at every menu setting and nothing seems to be applicable to this. Do I need to create a distinct Gateway for physically connected devices?
I am certain I am missing something obvious. Anyway, appreciate the help.
Topography is as follows
OPNSENSE router -> Switch with POE+ -> Unifi U6E Access point -> no problem assigning devices to VLAN (IoT) via wifi (works chef's kiss perfectly)
|
-> LAN connnected devices -> will not under any circumstance assign to VLAN (IoT) PROBLEM
I followed this helpful guide to get the Unifi set up (NAT, VLAN Interface, etc.). I confirmed the Unifi device is 100% NOT doing anything with DHCP (even warns me in the controller software its doing nothing) and OPNsense is, and its working perfectly. The switch is passing VLAN tags along perfectly as it works for the AP so its not a switch issue:
https://www.youtube.com/watch?v=CmC_AuoAmvs
All the DHCP VLAN ranges are set up correctly, because the access point is assigning them in that range.
Is there a "MAKE THIS god dam @#$@!#%@# device / MAC address move to this VLAN!!!" hidden setting somewhere in the DHCP menu? DHCP lease time has no effect. I tried assigning static ip addresses (Host) to the devices on the VLAN DHCP range and it never works. It makes an entry but the device NEVER moves over. I even disabled the LAN network it is currently assigning these devices to incorrectly, and the devices would rather get NO connection then go to the VLAN one. I know its a DHCP issue but I looked at every menu setting and nothing seems to be applicable to this. Do I need to create a distinct Gateway for physically connected devices?
I am certain I am missing something obvious. Anyway, appreciate the help.
#10
26.1, 26,4 Series / Re: DNSMasq - Am I missing som...
Last post by besalope - Today at 03:32:48 PMPosting this in case anyone else needs the reference in the future when trying to wrap their heads around how DNSMasq handles static assignments vs dynamic ranges within a subnet.
Hosts:
I found that while you can configure multiple static ranges on a subnet, the definition with the lowest Start Address will always override the others since we cannot define an End Address. This means you cannot have a split DNS assignment within a subnet that is only managed by setting the Tag on the DHCP Range, variance from lowest Start Address Range definition MUST be set on the actual Host configuration itself. The same thing applies to Blackhole Gateway/DNS, you can logically define a "range" but it must be applied on the Host configuration.
Works:
DHCP Range: LAN-Static-Pihole
DHCP Range: LAN-Dynamic
Does not work:
DHCP Range: LAN-Static-Pihole
DHCP Range: LAN-Static-CloudFlare - This is ignored
DHCP Range: LAN-Static-Infrastructure - This is ignored
DHCP Range: LAN-Dynamic
Hosts:
- .1-.89: Clients Static Reservation, use Pihole
- .90-.99: Clients Static Reservation, use Cloudflare. DNS-CloudFlare tag needs to be set on Host.
- .100-.150: Clients Dynamic, use Pihole
- .200-.253: Infrastructure/Proxmox Static Reservation, use Pihole
I found that while you can configure multiple static ranges on a subnet, the definition with the lowest Start Address will always override the others since we cannot define an End Address. This means you cannot have a split DNS assignment within a subnet that is only managed by setting the Tag on the DHCP Range, variance from lowest Start Address Range definition MUST be set on the actual Host configuration itself. The same thing applies to Blackhole Gateway/DNS, you can logically define a "range" but it must be applied on the Host configuration.
Works:
DHCP Range: LAN-Static-Pihole
- Range Start: 192.168.157.1
- Mode: Static
- Domain Type: Range
- Tag: DNS-Pihole
DHCP Range: LAN-Dynamic
- Range Start: 192.168.157.100
- Range End: 192.168.157.150
- Mode: Nothing
- Domain Type: Range
- Tag: DNS-Pihole
Does not work:
DHCP Range: LAN-Static-Pihole
- Range Start: 192.168.157.1
- Mode: Static
- Domain Type: Range
- Tag: DNS-Pihole
DHCP Range: LAN-Static-CloudFlare - This is ignored
- Range Start: 192.168.157.90
- Mode: Static
- Domain Type: Range
- Tag: DNS-CloudFlare
DHCP Range: LAN-Static-Infrastructure - This is ignored
- Range Start: 192.168.157.200
- Mode: Static
- Domain Type: Range
- Tag: DNS-Pihole
DHCP Range: LAN-Dynamic
- Range Start: 192.168.157.100
- Range End: 192.168.157.150
- Mode: Nothing
- Domain Type: Range
- Tag: DNS-Pihole
