Recent posts

#1
26.7, 26.10 Series / Re: [Solved] UPNP fatal error ...
Last post by axsdenied - Today at 06:07:48 PM
Actually removing the STUN host address fixed this issue.
#2
26.7, 26.10 Series / Re: FreeRADIUS MAC-Based Auth ...
Last post by franco - Today at 05:55:12 PM
For anyone looking for a workaround while maintainer picks this up:

# opnsense-revert -r 26.7.8 os-freeradius

and re-apply the settings for the service.


Cheers,
Franco
#3
Hello everyone,

I'm running into an issue with the FreeRADIUS plugin (os-freeradius) on OPNsense when setting up MAC-Based Authentication (MAB) with Ubiquiti UniFi Access Points.

The Scenario & Goal
In a MAB environment, unknown clients (whose MAC addresses are not explicitly registered in a local database) need to be caught by a global DEFAULT fallback rule in /usr/local/etc/raddb/users and assigned to a specific fallback VLAN (e.g., VLAN 20).

A working configuration in the users file requires explicit Auth-Type := Accept along with the appropriate RADIUS tunnel attributes:


DEFAULT Auth-Type := Accept
        Tunnel-Type = VLAN,
        Tunnel-Medium-Type = IEEE-802,
        Tunnel-Private-Group-Id = "20"

The Problem
While the fallback options can be configured via the OPNsense FreeRADIUS GUI, saving any changes or restarting the service through the web interface causes the backend template engine to overwrite or alter the users file.

Specifically, the GUI-generated configuration strips the required Auth-Type := Accept handling. As a result, FreeRADIUS logs show that while the DEFAULT rule is matched, the PAP module fails because no Auth-Type is set:


(0) files: users: Matched entry DEFAULT at line 62
(0)      [files] = ok
(0) pap: WARNING: No "known good" password found for the user.  Not setting Auth-Type
(0)      [pap] = noop
(0) ERROR: No Auth-Type found: rejecting the user via Post-Auth-Type = Reject
(0) Failed to authenticate the user


Consequently, unknown devices instantly fail authentication (Access-Reject) instead of being routed to the fallback VLAN. Every time a setting is saved in the GUI, the manual fix gets wiped out.

Current Workaround
As a temporary fix, manually editing the users file via SSH / CLI and applying an immutable flag (chflags schg /usr/local/etc/raddb/users) successfully prevents the OPNsense GUI from overwriting the working configuration during service reloads or updates.

Bug Report & Tracking
I have opened a detailed bug report on GitHub to track this and hopefully get the plugin templates adjusted so they natively preserve or generate proper DEFAULT fallback rules for MAB:

GitHub Issue: https://github.com/opnsense/plugins/issues/5914

If anyone else is experiencing this behavior or has insights on how to handle MAB defaults cleanly within the current GUI framework, I'd appreciate any feedback!
#4
Quote from: vicking on <strong>Today</strong> at 02:05:29 PMI am also using igmp proxy between my iptv wan and vlan.

Do you think I could also configure this with Netflector?
Have a look at this : https://forum.opnsense.org/index.php?topic=51192.msg262139#msg262139

It keeps IPTV issues nicely away from your OPNsense :)
#5
High availability / Re: CARP - Preventing individu...
Last post by siennaplane - Today at 04:00:37 PM
Quote from: browne on November 06, 2026, 12:28:53 PMHey everyone,

I'm currently trying to set up my first CARP HA scenario.
I've installed and licensed the latest OPNsense Business Edition on both nodes.

Both OPNsense instances have two 10G ports configured as a LAG, with all networks configured as VLANs on that interface.
Additionally, each instance has two 1G ports. One is dedicated to pfsync, while the other is used for management access.
All VIPs on the master node have their skew set to 0, while those on the backup node are set to 100. The base is set to 1.
Preemption is enabled on both nodes (the checkbox to disable it is unchecked). I haven't configured anything regarding the demotion level so far.

As far as I understand it, the demotion level can trigger a complete failover if one of the interfaces goes down (assuming it's configured correctly).
However, since all CARP interfaces are VLANs, I assume the demotion mechanism would never be triggered because the VLAN interfaces can't go down individually.
This would mean that CARP failovers could still occur independently for each interface if a particular VLAN experiences connectivity issues or the switch gets misconfigured.

What I'm looking for is a way to prevent the backup node from taking over any CARP VIPs unless the primary node goes offline entirely.
I've found some solutions involving custom scripts that need to be installed via SSH directly in the filesystem. However, I'm a bit concerned that these scripts might break after updates or interfere with the update process itself.

That's why I'd prefer a solution that can be configured entirely through the GUI.
I also came across Monit, but I haven't looked into it in detail yet.

It might sound a bit strange that I'm looking for a solution to this particular scenario, considering that all networks are connected through a single 10G LAG and should theoretically fail together.
However, there are two main reasons for this.

1. Switch firmware bugs
Occasionally, the switches encounter a firmware bug that causes them to stop forwarding traffic for a single VLAN on one switch unit or overload just one particular VLAN. Sometimes even other Devices overload a VLAN which causes an interruption that the switch then can keep isolated in that VLAN.

2. Switch configuration errors
Sometimes, someone makes changes to the switch configuration and somehow manages to remove a VLAN from one of the OPNsense ports.

In both cases, I'd rather have an outage affecting a single network than have the backup node silently take over all CARP IPs, potentially hiding the underlying issue, or taking over only that particular VLAN, sending me in the wrong direction during troubleshooting.

Essentially, I want to avoid individual CARP VIP failovers and ensure that the backup node only takes over when the primary node fails completely.
Does anyone have an idea how to achieve this, preferably using only the OPNsense GUI?

CARP per-VIP behavior is kind of the awkward bit here, especially with VLANs riding one parent. A partial takeover can make a switch-side mistake look like a firewall failure, which is a pretty nasty rabbit hole.
#6
Quote from: vicking on <strong>Today</strong> at 02:05:29 PMAnother question. I am also using igmp proxy between my iptv wan and vlan. Do you think I could also configure this with Netflector?

No, this will not work. IGMP proxy relays multicast subscription requests and then forwards the traffic. Netflector does discovery-related things.
#7
26.7, 26.10 Series / Re: [Solved] UPNP fatal error ...
Last post by axsdenied - Today at 03:29:43 PM
I'm actually getting a different set of errors.  Not sure if the patch addressed this:

2026-11-12T07:21:12-07:00ErrorminiupnpdFailed to broadcast good-bye notifications
2026-11-12T07:21:12-07:00ErrorminiupnpdLast message 'sendto(udp_shutdown=' repeated 10 times, suppressed by syslog-ng on xxx.xxxx.lan
2026-11-12T07:21:12-07:00Errorminiupnpdsendto(udp_shutdown=0) to [FF0E::C]: Socket operation on non-socket
2026-11-12T07:21:12-07:00ErrorminiupnpdLast message 'sendto(udp_shutdown=' repeated 10 times, suppressed by syslog-ng on xxx.xxxx.lan
2026-11-12T07:21:12-07:00Errorminiupnpdsendto(udp_shutdown=0) to [FF05::C]: Socket operation on non-socket
2026-11-12T07:21:12-07:00ErrorminiupnpdLast message 'sendto(udp_shutdown=' repeated 10 times, suppressed by syslog-ng on xxx.xxxx.lan
2026-11-12T07:21:12-07:00Errorminiupnpdsendto(udp_shutdown=0) to [FF02::C]: Socket operation on non-socket
2026-11-12T07:21:12-07:00ErrorminiupnpdLast message 'sendto(udp_shutdown=' repeated 10 times, suppressed by syslog-ng on xxx.xxxx.lan
2026-11-12T07:21:12-07:00Errorminiupnpdsendto(udp_shutdown=0) to 239.255.255.250: Socket operation on non-socket
2026-11-12T07:21:12-07:00ErrorminiupnpdPerforming STUN failed. EXITING
2026-11-12T07:21:12-07:00ErrorminiupnpdSTUN: Performing STUN failed: Device not configured
2026-11-12T07:21:12-07:00ErrorminiupnpdLast message 'STUN server not supp' repeated 3 times, suppressed by syslog-ng on xxx.xxxx.lan
2026-11-12T07:21:12-07:00ErrorminiupnpdSTUN server not supported, not returning OTHER-ADDRESS / support CHANGE-REQUEST's required for endpoint-independent (1:1) CGNAT filtering tests per RFC 5780.
2026-11-12T07:21:12-07:00Errorminiupnpdcould not open lease file: /var/run/miniupnpd.leases-ipv6
2026-11-12T07:21:12-07:00Errorminiupnpdcould not open lease file: /var/run/miniupnpd.leases

#8
Dutch - Nederlands / Re: DEC740 te koop
Last post by vicking - Today at 02:15:29 PM
Quote from: cloudz on January 16, 2026, 02:47:06 PMZoals de topic aangeeft heb ik een DEC740 te koop. Top machine maar in onbruik geraakt.

- Aangekocht op 13/11/2023.
- In perfecte staat.
- Minimum bod - 500€

Nog te koop?
#9
Another question. I am also using igmp proxy between my iptv wan and vlan. Do you think I could also configure this with Netflector?
#10
Quote from: swiftshearwater99 on <strong>Today</strong> at 11:53:40 AMWith one shared LAG, tying CARP state to a single real parent interface

But CARP does not do that. It does not know anything about interface states - or interfaces. Neither do the paritcipating nodes exchange any information.

A CARP node

- multicasts its own CARP address(es) and priority to each broadcast domain (network, VLAN) where CARP is active
- listens to similar multicasts in the same broadcast domain
- if it doesn't receive one it activates its own CARP address and assumes the master role
- if it does and if the hash of CARP addresses matches its own, and if the priority of the received message is higher than its own, it does not activate its own address and assumes the standby role

That's it. Essentially stateless. Each node works completely independent of all others.