"Recent posts
#1
Virtual private networks / Re: wireguard freebsd wg(4) CV...
Last post by paepcke - Today at 08:10:04 AMhttps://www.tenable.com/cve/CVE-2026-58085
CVSS v3 : Base Score: 7.5 (HIGH)
Its a big one!
(Failure to check inbound data authentication!)
Quick hotfix & backports would be very welcome. Very small patch, very big impact. Expect AI assisted exploit flood in 3...2...1 ...
#2
26.7 Series / Re: Multiple VLANs - sometimes...
Last post by danman - Today at 06:54:25 AMQuoteWhat are you trying to achieve ?!
- Setting the correct Management IP Address for the webGUI of the Switch ?
- Getting the right subnet to specific Clients connected to the Switch ?
Exactly that -> `Setting the correct Management IP Address for the webGUI of the Switch?`
Quote- Router <---> Switch = Always Tagged.The AP should be like that but I've to check it properly, the entire openwrt AP device. Like I mentioned, the connection works good on the current openwrt main router but I dont have a IP listed under "Active DHCPv4 Leases" either on the main openwrt device. I'm not focusing on the AP at the moment because it has some firewall still running on that device and such. I just wanted to mentioned that the tagged from opnsense (port 1 - igc1 VLANs) -> switch (port 5 only TAGGED) -> openwrt (wan port TAGGED and untagged) works so far.
- Switch <---> Switch = Always Tagged.
- Switch <---> Accesspoint = Always Tagged.
- Switch <---> Wired Clients = Untagged.
- Accesspoint <---> Wireless Clients = Tagged VLAN in the SSID Settings and once the Wireless Clients connect they get an Untagged connection.
QuoteHowever... in some cases... you need to also add one Untagged VLAN in order to have a Management IP Address for Switches and Accesspoints and this subnet comes from a seperate Untagged NIC in the case of OPNsense as I was trying to explain to your earlier on !!I dont understand. So do you mean other ports on the opnsense device should be used only for different switches/APs?
Quote- Pick any of the available NICs for a new Interface and just leave it Enabled but without any IP Address configuration.Are you talking particular about that?
QuoteCan we assume that each VLAN Interface has it's own Subnet and active DHCP Server + the right Firewall Rules ?Nah, thats all good. I checked it a few times now. Also all Interfaces are selected under general.
In other words : You are not trying to spread one Subnet and DHCP Server across multiple VLANs ?
QuoteIf you don't get any DHCP IP Address then there is an error in your configuration => See my previous questions !!Well, I thought PVID takes care to tell opnsense that this switch would like to go with VLAN 25 but this seems to be not the case so I think the only option is to use a static IP address.
I've also a few proxmox server and other switches etc I'll see how that will work. I think on proxmox for example I had to set up IPv4/CIDR which should take care of that.
Maybe, I was just lucky before that the switches took the right VLAN in the first place :D I'm not so familiar with VLAN, I'm not setting it up every day or even years. Once its done, its done ;)
QuoteLooks like another configuration error! Possibly between the Switch and the Accesspoint ?!I think I can try a bit more on the AP as I mentioned further up in this post.
QuoteThen you need to fix your OPNsense configuration :PI think it's more my way of thinking about all that especially the PVID is probably the key issue in my brain here :D
#3
26.7 Series / Re: VLAN devices are on LAN IP...
Last post by tonys - Today at 05:20:49 AMOK, so for better or for worse, I removed the LAN bridge completely. The new configuration is as follows (igc3 is now unconnected):
igc0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: LAN (lan)
igc1: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: WAN (wan)
igc2: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: DMZ (opt1)
igc3: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
vlan00: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
groups: vlan
vlan: 1 vlanproto: 802.1q vlanpcp: 0 parent interface: igc0
status: active
vlan01: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
groups: vlan
vlan: 20 vlanproto: 802.1q vlanpcp: 0 parent interface: igc0
status: active
vlan02: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
groups: vlan
vlan: 40 vlanproto: 802.1q vlanpcp: 0 parent interface: igc0
status: active
While this seems to be correct, I can't figure out how to add the VLAN address ranges back in (i.e., I want vlan01 to be 192.168.20.x and vlan02 to be 192.168.40.x). Note that I also added vlan00 for the LAN address block of 192.168.1.x. Unfortunately, nothing has changed at all. All devices remain stuck on the LAN IPs. I used to be able to add interfaces opt2 and opt3 for the VLANs but I can't do this now. What am I doing wrong?
Another interesting thing is that the Unifi AP is seeing the proper tag names from the Guest and IoT VLANs even though they're all LAN IPs. I find this very confusing - how does the Unifi AP see the proper VLAN names but OPNSense doesn't assign the proper IPs? See the attached screen shot.
igc0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: LAN (lan)
igc1: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: WAN (wan)
igc2: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: DMZ (opt1)
igc3: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
vlan00: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
groups: vlan
vlan: 1 vlanproto: 802.1q vlanpcp: 0 parent interface: igc0
status: active
vlan01: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
groups: vlan
vlan: 20 vlanproto: 802.1q vlanpcp: 0 parent interface: igc0
status: active
vlan02: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
groups: vlan
vlan: 40 vlanproto: 802.1q vlanpcp: 0 parent interface: igc0
status: active
While this seems to be correct, I can't figure out how to add the VLAN address ranges back in (i.e., I want vlan01 to be 192.168.20.x and vlan02 to be 192.168.40.x). Note that I also added vlan00 for the LAN address block of 192.168.1.x. Unfortunately, nothing has changed at all. All devices remain stuck on the LAN IPs. I used to be able to add interfaces opt2 and opt3 for the VLANs but I can't do this now. What am I doing wrong?
Another interesting thing is that the Unifi AP is seeing the proper tag names from the Guest and IoT VLANs even though they're all LAN IPs. I find this very confusing - how does the Unifi AP see the proper VLAN names but OPNSense doesn't assign the proper IPs? See the attached screen shot.
#4
26.7 Series / Re: Upgrade to 26.7 from 26.1....
Last post by HarveyEllis1 - Today at 01:41:16 AMI did fresh install of 26.7.1 & reloaded backup config file.
This was less hassle than spending more time on borked upgrade.
This was less hassle than spending more time on borked upgrade.
#5
26.1, 26,4 Series / SERVFAIL when domain has no A...
Last post by NonGough - Today at 01:19:38 AMISP is the AT&T Fiber service. The AT&T Fiber BGW320-500 modem offers WiFi and has four RJ45 ports which are assigned addresses in the 192.168.0.0/24 AT&T Fiber modem/firewall's local network. This Fiber box effectively is a configureable firewall appliance with a built-in fiber modem doing the translations between the external fiber port and the internal RJ45 WAN port. The AT&T WiFi option is unused and is secured with a password. The OPNsense Protectli firewall appliance has a Grandstream WiFi device on a Virtual LAN connected to the OPNsense device via a TP-Link switch. This OPNsense WiFi configuration works as expected.
Knowing that it would cause a double-NAT, I have chosen to not use the IP passthrough option through the AT&T Fiber modem/firewall for my OPNsense appliance, a Protectli device with adequate hardware resources. The AT&T Fiber firewall has effective silent blocking of attempts of external actors to solicit responses to unsolicted protocols, ports, and packets. As the OPNsense firewall appliance is a both an functional operational and a blood-sweat-and-tears learning tool, it helps a lot to have the OPNsense log not filled primarily with thousands of entries of unsolicted protocols and packets (roughly from 64 to 512 per hour).
My problem is that a website used by a Windows laptop (W10, updates current as of 2025.10 update) and a Windows desktop (W11, updates current as of 2026.07 update) references a domain name – dms.xxxxxx.com - generates a SERVFAIL because: 1) "all servers for this domain failed, at zone up.railway.app at [a valid IPv6 address] no server to query nameserver addresses not useable"; and per Services : Unbound DNS : Log File - 2) there is no public DNS records for the domain name – dms.xxxxxx.com – available per DNSchecker's "DNS Lookup" service (all worldwide authoritive servers including ICANN's agree on this).
Domains involved have been placed on the Services : Unbound DNS : Blocklists : Allowlist Domains to no effect.
When the Windows desktop bypasses OPNsense by directly by a dedicated use one of the AT&T Fiber's modem/firewall ports, the SERVFAIL does not occur!
OPNsense is at 26.1.11_10-amd64 and is current per the CLI Update from console and the OPNsense Web Gui's System : Firmware : Updates. No IP's involved are on any IP DNSchecker blacklist.
CrowdSec and Unbound DNS OPNsense services do not affect the SERVFail in any combination of being Enabled or Disabled. The complete current list of plugin services added to the base OPNsense configuration is (with "*" is installed/configured/running, "**" is installed/not-configured; "***" is installed/configured/stopped):
System : Firmware : Plugins - installed list (plugins not yet configured are labeled "misconfigured")
* os-chrony – Chrony time synchronization (chrony daemon)
*** os-crowdsec – Lightweight and collaborative security engine
*** os-debug – Debugging Tools
* os-demidecode – Display hardware information on the dashboard
** os-hw-probe (misconfigured) – Collect hardware diagnostics
** os-iperf (misconfigured) – Connection speed tester
* os-isc-dhcp – ISC DHCPv4/v6 server
** os-maltrail (misconfigured) – Malicious traffic detection system
** os-netdata (misconfigured) – Real-time performance monitoring
* os-smart – SMART tools
* os-telegraf (misconfigured) – Agent for collecting metrics and data
* os-vnstat (misconfigured) – Network traffic monitor
Lobby : Dashboard : Services
* chrony daemon
* System Configuration Daemon
* Cron
*** Crowdsec
* ISC DHCPv4
* ISC DHCPv6
* Gateway monitor watcher
* Gateway monitor (WAN_DHCP6)
* Gateway monitor (WAN_DHCP4)
* Insight Aggregator
* Host discovery service
*** iperf Performance Test
* Users and Groups
* Packet Filter
* Router Advertisements
* System routing
* NetFlow Distributor
* Intrusion Detection
* System tunables
* Syslog-ng Daemon
* Unbound DNS
* vnStat Daemon
* Web GUI
Any thoughts on why OPNsense may be causing a SERVFAIL?
Is there an alternative to using UNBOUND DNS on OPNsense?
Could this be a ISC DHCPv4 and ISC DHCPv6 related issue?
Thoughts are appreciated, thank you.
Knowing that it would cause a double-NAT, I have chosen to not use the IP passthrough option through the AT&T Fiber modem/firewall for my OPNsense appliance, a Protectli device with adequate hardware resources. The AT&T Fiber firewall has effective silent blocking of attempts of external actors to solicit responses to unsolicted protocols, ports, and packets. As the OPNsense firewall appliance is a both an functional operational and a blood-sweat-and-tears learning tool, it helps a lot to have the OPNsense log not filled primarily with thousands of entries of unsolicted protocols and packets (roughly from 64 to 512 per hour).
My problem is that a website used by a Windows laptop (W10, updates current as of 2025.10 update) and a Windows desktop (W11, updates current as of 2026.07 update) references a domain name – dms.xxxxxx.com - generates a SERVFAIL because: 1) "all servers for this domain failed, at zone up.railway.app at [a valid IPv6 address] no server to query nameserver addresses not useable"; and per Services : Unbound DNS : Log File - 2) there is no public DNS records for the domain name – dms.xxxxxx.com – available per DNSchecker's "DNS Lookup" service (all worldwide authoritive servers including ICANN's agree on this).
Domains involved have been placed on the Services : Unbound DNS : Blocklists : Allowlist Domains to no effect.
When the Windows desktop bypasses OPNsense by directly by a dedicated use one of the AT&T Fiber's modem/firewall ports, the SERVFAIL does not occur!
OPNsense is at 26.1.11_10-amd64 and is current per the CLI Update from console and the OPNsense Web Gui's System : Firmware : Updates. No IP's involved are on any IP DNSchecker blacklist.
CrowdSec and Unbound DNS OPNsense services do not affect the SERVFail in any combination of being Enabled or Disabled. The complete current list of plugin services added to the base OPNsense configuration is (with "*" is installed/configured/running, "**" is installed/not-configured; "***" is installed/configured/stopped):
System : Firmware : Plugins - installed list (plugins not yet configured are labeled "misconfigured")
* os-chrony – Chrony time synchronization (chrony daemon)
*** os-crowdsec – Lightweight and collaborative security engine
*** os-debug – Debugging Tools
* os-demidecode – Display hardware information on the dashboard
** os-hw-probe (misconfigured) – Collect hardware diagnostics
** os-iperf (misconfigured) – Connection speed tester
* os-isc-dhcp – ISC DHCPv4/v6 server
** os-maltrail (misconfigured) – Malicious traffic detection system
** os-netdata (misconfigured) – Real-time performance monitoring
* os-smart – SMART tools
* os-telegraf (misconfigured) – Agent for collecting metrics and data
* os-vnstat (misconfigured) – Network traffic monitor
Lobby : Dashboard : Services
* chrony daemon
* System Configuration Daemon
* Cron
*** Crowdsec
* ISC DHCPv4
* ISC DHCPv6
* Gateway monitor watcher
* Gateway monitor (WAN_DHCP6)
* Gateway monitor (WAN_DHCP4)
* Insight Aggregator
* Host discovery service
*** iperf Performance Test
* Users and Groups
* Packet Filter
* Router Advertisements
* System routing
* NetFlow Distributor
* Intrusion Detection
* System tunables
* Syslog-ng Daemon
* Unbound DNS
* vnStat Daemon
* Web GUI
Any thoughts on why OPNsense may be causing a SERVFAIL?
Is there an alternative to using UNBOUND DNS on OPNsense?
Could this be a ISC DHCPv4 and ISC DHCPv6 related issue?
Thoughts are appreciated, thank you.
#6
Virtual private networks / Tips on Reliable IPsec Configu...
Last post by jambandfan_1996 - August 02, 2026, 11:54:08 PMI'm new to the OPNsense community and recently tested a couple devices running 26.1 in GNS3, before I plan to deploy into our ecosystem later this month. I have the need for a reliable always on type route based IPsec tunnel.
I found the tutorial presented at https://docs.opnsense.org/manual/how-tos/ipsec-s2s-conn-route.html to be easy to follow, although what I was left with initially following the tutorial were tunnels that exhibited some unreliable behavior. Notably tunnels not reconnecting following device restarts, requiring manual intervention, and tunnels that needed traffic initiated from both sides of the tunnel before allowing traffic across.
I'm far from a networking expert, so it took me about a day to get the connections working to my liking. I figured I would share what I learned to save any other newcomers some time.
Tunnels not passing traffic until something is initiated from both sides
Issue: For whatever reason, my tunnels would not send traffic routed to a vti across the ipsec link until a host on both sides of the link initiated a connection. For example, a host at 1 site could sit and ping a host across the tunnel all day and not get a response, until a host on the other side also tried to reach out to a host on the first side.
Resolution: I have no idea why this behavior happens, however I resolved it by making sure gateway monitoring on my vti interfaces is enabled. With the gateway monitoring option enabled on these interfaces, they are constantly pinging each other to check link health. As a result, the tunnels are able to pass traffic as soon as the link is established. I also set "Start action" to "start" and "dpd action" to "start" on the child configuration of the tunnel, but I'm not sure if that had much of an effect.
Links not connecting automatically following device restarts
Issue:Following the restart of one or more firewalls, the phase 1 connection would sometimes fail, and I would have to manually start the connection from the "status overview" page after the firewalls were up for a minute.
Resolution: After some research I found the "keyingtries" option under vpn-ipsec-connections-[connection]-advanced apparently defines how many times the device will try to establish the connection before giving up. I'm not sure what this defaults to but if you set to 0, that basically has it try forever. I also set the "version" option from the default to "IKEv2", but I'm not sure if that had any effect.
Hope someone can find this info useful!
I found the tutorial presented at https://docs.opnsense.org/manual/how-tos/ipsec-s2s-conn-route.html to be easy to follow, although what I was left with initially following the tutorial were tunnels that exhibited some unreliable behavior. Notably tunnels not reconnecting following device restarts, requiring manual intervention, and tunnels that needed traffic initiated from both sides of the tunnel before allowing traffic across.
I'm far from a networking expert, so it took me about a day to get the connections working to my liking. I figured I would share what I learned to save any other newcomers some time.
Tunnels not passing traffic until something is initiated from both sides
Issue: For whatever reason, my tunnels would not send traffic routed to a vti across the ipsec link until a host on both sides of the link initiated a connection. For example, a host at 1 site could sit and ping a host across the tunnel all day and not get a response, until a host on the other side also tried to reach out to a host on the first side.
Resolution: I have no idea why this behavior happens, however I resolved it by making sure gateway monitoring on my vti interfaces is enabled. With the gateway monitoring option enabled on these interfaces, they are constantly pinging each other to check link health. As a result, the tunnels are able to pass traffic as soon as the link is established. I also set "Start action" to "start" and "dpd action" to "start" on the child configuration of the tunnel, but I'm not sure if that had much of an effect.
Links not connecting automatically following device restarts
Issue:Following the restart of one or more firewalls, the phase 1 connection would sometimes fail, and I would have to manually start the connection from the "status overview" page after the firewalls were up for a minute.
Resolution: After some research I found the "keyingtries" option under vpn-ipsec-connections-[connection]-advanced apparently defines how many times the device will try to establish the connection before giving up. I'm not sure what this defaults to but if you set to 0, that basically has it try forever. I also set the "version" option from the default to "IKEv2", but I'm not sure if that had any effect.
Hope someone can find this info useful!
#7
German - Deutsch / Re: BIOS Einstellungen - Harde...
Last post by nero355 - August 02, 2026, 11:26:05 PMQuote from: johnydo on August 02, 2026, 10:09:09 AMAdvanced – Trusted ComputingAUS !!! mit die TCPA/Palladium scheiBe bitte !!!
TPM Support > Aktivieren
/The best German that I could do... LOL! ;)
#8
26.7 Series / Re: Upgrade to 26.7 from 26.1....
Last post by nero355 - August 02, 2026, 11:20:13 PMYou seem to have multiple issues :
- Some RealTek NICs no longer work in FreeBSD 15.x a.k.a. OPNsense 26.7 !!
- You might have the Intel/AMD microcode plug-in issue too : You need to uninstall it before upgrading to 26.7 !!
- And then you need to upgrade the FreeBSD Bootloader from the old version to the most recent FreeBSD 15.x version !!
- Then Enable the Intel/AMD microcode plug-in again if you want to keep using it.
But if your NICs are no longer supported then it's time to consider a hardware upgrade first and simply do a fresh install and configuration... :(
Good luck! :)
- Some RealTek NICs no longer work in FreeBSD 15.x a.k.a. OPNsense 26.7 !!
- You might have the Intel/AMD microcode plug-in issue too : You need to uninstall it before upgrading to 26.7 !!
- And then you need to upgrade the FreeBSD Bootloader from the old version to the most recent FreeBSD 15.x version !!
- Then Enable the Intel/AMD microcode plug-in again if you want to keep using it.
But if your NICs are no longer supported then it's time to consider a hardware upgrade first and simply do a fresh install and configuration... :(
Good luck! :)
#9
26.7 Series / Re: VLAN devices are on LAN IP...
Last post by nero355 - August 02, 2026, 11:13:51 PMQuote from: tonys on August 02, 2026, 09:45:45 PMThe untagged LAN + both tagged VLANs are on igc0 (port 1 of the Protecli) and go ONLY to the Unifi AP.If you need the VLAN 1 stuff for Ubiquiti UniFi equipment then this would be the right setup :
OPNsense :
- NIC #1 = LAN Untagged
- NIC #2 = Additional Tagged VLANs
Add a Switch between OPNsense and the UniFi UAP :
- Switch Port #1 = Untagged and connected to OPNsense NIC #1
- Switch Port #2 = Tagged and connected to OPNsense NIC #2
- Switch Port #3 that has PoE or PoE+ Output and carries :
Untagged LAN network from OPNsense NIC #1 coming from Switch Port #1
Tagged Additional VLANs from OPNsense NIC #2 coming from Switch Port #2
UniFi UAP :
- Connected to Switch Port #3 that has PoE or PoE+ Output and is then reachable via VLAN 1 which will be the OPNsense LAN network from NIC #1.
- The WiFi SSIDs will then use all the Tagged Additional VLANs from OPNsense NIC #2.
I hope the above is clear enough and if you have questions then let me know :)
#10
26.7 Series / Re: 26.7 NAT port map trouble
Last post by meyergru - August 02, 2026, 10:54:58 PMCorrect, the source address is NOT your WAN address. And if you want to rule out further errors in the firewall rules, use "pass" before you try something more difficult.
