"Recent posts
#1
General Discussion / Re: Management port on transpa...
Last post by Patrick M. Hausen - Today at 04:27:07 PM@Monviech for OPNsense to get out to the Internet in a transparent bridge setup it needs an IP address matching the other router and a properly configured default gateway.
#2
General Discussion / Re: Management port on transpa...
Last post by Monviech (Cedrik) - Today at 04:18:07 PMThe bridge tutorial linked above is more about transparent filtering bridges with vlans that should stay unnumbered. A normal LAN bridge should work as @viragomann mentions.
#3
General Discussion / Re: Management port on transpa...
Last post by viragomann - Today at 03:53:03 PMQuote from: mantissa on Today at 02:36:05 AMI cannot get a connection outbound from the bridge0 device to the outside world.This requires, that the OPNsense has an IP the same subnet as the other devices, which are able to get out to WAN across the bridge and that the gateway is configured correctly.
#4
26.1, 26,4 Series / Re: UI/UX: The "moving" Apply ...
Last post by iorx - Today at 03:36:25 PMAwesome!
And such responsiveness here, KUDOS!
I had a go at the source to check what I could find, but with limited knowledge I gave in... Had a small idea to contribute with more than just "the Apply button is moving, please fix" 😁
Keep up the amazing work!
And such responsiveness here, KUDOS!
I had a go at the source to check what I could find, but with limited knowledge I gave in... Had a small idea to contribute with more than just "the Apply button is moving, please fix" 😁
Keep up the amazing work!
#5
High availability / Re: Kea DHCP duplicating respo...
Last post by Monviech (Cedrik) - Today at 03:26:23 PMHello,
I would try in the KEA mailing list first, to see what the recommended configuration is.
If they say its a bug then I would try the KEA gitlab.
Here an example of an issue that went this way: https://github.com/opnsense/ports/issues/267
I would try in the KEA mailing list first, to see what the recommended configuration is.
If they say its a bug then I would try the KEA gitlab.
Here an example of an issue that went this way: https://github.com/opnsense/ports/issues/267
#6
26.1, 26,4 Series / Re: Why does this static ULA g...
Last post by Maurice - Today at 03:20:18 PMQuote from: OPNenthu on Today at 05:12:29 AMSo I'm not sure I gain any separation by using a dedicated loopback interface for redirects over just assigning a ULA VIP to the normal loopback.
Additional loopback interfaces are useful for running multiple services on the same port, but on different IP addresses. Some services only allow you to specify the interface they bind to, but not a specific IP address. So you need one interface per service / IP address.
If you just need additional IP addresses (e. g. as NAT redirect targets), I see no benefit in additional loopbacks and would indeed use VIPs.
Cheers
Maurice
#7
General Discussion / Re: Management port on transpa...
Last post by nero355 - Today at 03:08:01 PMHave you done this : https://docs.opnsense.org/manual/how-tos/transparent_bridge.html#change-system-tuneables ??
And are you aware of the fact that the Management Interface is used for Internet Connectivity : https://docs.opnsense.org/manual/how-tos/transparent_bridge.html#connect-interfaces-to-existing-infrastructure !!
And are you aware of the fact that the Management Interface is used for Internet Connectivity : https://docs.opnsense.org/manual/how-tos/transparent_bridge.html#connect-interfaces-to-existing-infrastructure !!
#8
High availability / Kea DHCP duplicating responses...
Last post by badyusuke - Today at 02:53:56 PMHello community,
I am experiencing a persistent issue with the Kea DHCP implementation on an OPNsense HA Cluster. When using the default configuration (Raw Sockets + Multi-threading), the Kea service seems to "hear double" on interfaces where CARP is active, leading to duplicated logs and, more critically, conflicting IP offers to the same client.
Environment Setup:
Version: OPNsense 25.7.11_9-amd64.
Setup: Two nodes in HA (Master: Physical / Backup: Virtual).
Networking: High Availability with CARP acting as gateways across multiple VLANs.
DHCP: Kea DHCP configured in HA (Hot-Standby).
The Problem:
When Kea is configured with the default Socket Type: Raw, the service seems to "double-process" incoming broadcast packets on interfaces that have both a physical IP and a CARP VIP.
Because Kea uses multi-threading by default (4 threads), two (or more) different threads capture the same DHCPDISCOVER or DHCPREQUEST at the exact same millisecond. This creates a race condition: each thread checks the lease database, sees an available IP, and sends a separate DHCPOFFER or DHCPACK. In some instances, they even offer different IPs to the same client for the same transaction.
Evidence (Logs):
Notice the different thread IDs (e.g., ...9808 and ...a008) processing the same Transaction ID (tid=0xcb0e85d2) at the exact same millisecond:
Troubleshooting already performed:
Network Mask Check: Validated that there are no subnet overlaps on CARP VIPs.
Socket Type Change: * When switching to Socket Type: UDP, the duplication stops and logs become clean. However, many clients (especially those initiating discovery from 0.0.0.0) fail to receive IPs in UDP mode.
Analysis:
Binding: sockstat -4 -l shows Kea binding to both the Physical IP (e.g., 10.x.x.2:67) and the CARP VIP (e.g., 10.x.x.1:67).
It appears that with Raw Sockets, the BPF (Berkeley Packet Filter) delivers the packet to all listening threads. Since both the Physical IP and the CARP VIP are on the same interface, Kea seems to be binding in a way that triggers this double processing.
Questions:
Persistent Thread Limit: Is there a way to limit Kea threads to 1 through the GUI or a tunable?
Deny Service Binding: I noticed the "Deny service binding" option in the CARP settings.
If I enable this for the CARP, would it prevent Kea from listening on the Virtual IP, thus solving the duplication while keeping Raw Sockets?
What are the side effects for other services like ntpd or unbound if they rely on the CARP to serve clients?
Best Practice: Is this a known limitation of Kea on FreeBSD when CARP is involved, and what is the recommended way to use Kea in an HA setup without duplicate processing?
Any insights would be greatly appreciated!
I am experiencing a persistent issue with the Kea DHCP implementation on an OPNsense HA Cluster. When using the default configuration (Raw Sockets + Multi-threading), the Kea service seems to "hear double" on interfaces where CARP is active, leading to duplicated logs and, more critically, conflicting IP offers to the same client.
Environment Setup:
Version: OPNsense 25.7.11_9-amd64.
Setup: Two nodes in HA (Master: Physical / Backup: Virtual).
Networking: High Availability with CARP acting as gateways across multiple VLANs.
DHCP: Kea DHCP configured in HA (Hot-Standby).
The Problem:
When Kea is configured with the default Socket Type: Raw, the service seems to "double-process" incoming broadcast packets on interfaces that have both a physical IP and a CARP VIP.
Because Kea uses multi-threading by default (4 threads), two (or more) different threads capture the same DHCPDISCOVER or DHCPREQUEST at the exact same millisecond. This creates a race condition: each thread checks the lease database, sees an available IP, and sends a separate DHCPOFFER or DHCPACK. In some instances, they even offer different IPs to the same client for the same transaction.
Evidence (Logs):
Notice the different thread IDs (e.g., ...9808 and ...a008) processing the same Transaction ID (tid=0xcb0e85d2) at the exact same millisecond:
Code Select
2026-04-29T08:46:41-03:00 kea-dhcp4 INFO [kea-dhcp4.packets.0x3fb7b6ac9808] DHCP4_PACKET_RECEIVED [hwtype=1 74:86:e2:xx:xx:43], cid=[01:74:86:e2:xx:xx:43], tid=0xcb0e85d2: DHCPREQUEST received from 0.0.0.0 to 255.255.255.255 on interface vlan031
2026-04-29T08:46:41-03:00 kea-dhcp4 INFO [kea-dhcp4.packets.0x3fb7b6aca008] DHCP4_PACKET_RECEIVED [hwtype=1 74:86:e2:xx:xx:43], cid=[01:74:86:e2:xx:xx:43], tid=0xcb0e85d2: DHCPREQUEST received from 0.0.0.0 to 255.255.255.255 on interface vlan031
2026-04-29T08:46:41-03:00 kea-dhcp4 INFO [kea-dhcp4.leases.0x3fb7b6ac9808] DHCP4_LEASE_OFFER [hwtype=1 74:86:e2:xx:xx:43], tid=0xcb0e85d2: lease 10.x.x.11 will be offered
2026-04-29T08:46:41-03:00 kea-dhcp4 INFO [kea-dhcp4.leases.0x3fb7b6aca008] DHCP4_LEASE_OFFER [hwtype=1 74:86:e2:xx:xx:43], tid=0xcb0e85d2: lease 10.x.x.10 will be offeredTroubleshooting already performed:
Network Mask Check: Validated that there are no subnet overlaps on CARP VIPs.
Socket Type Change: * When switching to Socket Type: UDP, the duplication stops and logs become clean. However, many clients (especially those initiating discovery from 0.0.0.0) fail to receive IPs in UDP mode.
Analysis:
Binding: sockstat -4 -l shows Kea binding to both the Physical IP (e.g., 10.x.x.2:67) and the CARP VIP (e.g., 10.x.x.1:67).
Code Select
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
0 kea-dhcp4 47445 18 udp4 10.x.x.2:67 *:*
0 kea-dhcp4 47445 20 udp4 10.x.x.1:67 *:*It appears that with Raw Sockets, the BPF (Berkeley Packet Filter) delivers the packet to all listening threads. Since both the Physical IP and the CARP VIP are on the same interface, Kea seems to be binding in a way that triggers this double processing.
Questions:
Persistent Thread Limit: Is there a way to limit Kea threads to 1 through the GUI or a tunable?
Deny Service Binding: I noticed the "Deny service binding" option in the CARP settings.
If I enable this for the CARP, would it prevent Kea from listening on the Virtual IP, thus solving the duplication while keeping Raw Sockets?
What are the side effects for other services like ntpd or unbound if they rely on the CARP to serve clients?
Best Practice: Is this a known limitation of Kea on FreeBSD when CARP is involved, and what is the recommended way to use Kea in an HA setup without duplicate processing?
Any insights would be greatly appreciated!
#9
26.1, 26,4 Series / Re: UI/UX: The "moving" Apply ...
Last post by franco - Today at 02:32:53 PM> A lingering banner is not on the list though, since that would need to keep track of a dirty or clean system state.
The apply message and colour will now linger actually, but not across page loads. But it is being considered for a future improvement.
Cheers,
Franco
The apply message and colour will now linger actually, but not across page loads. But it is being considered for a future improvement.
Cheers,
Franco
#10
26.1, 26,4 Series / Re: UI/UX: The "moving" Apply ...
Last post by Monviech (Cedrik) - Today at 01:13:38 PMFunnily its being worked on right now:
https://github.com/opnsense/core/pull/10103
https://github.com/opnsense/core/issues/10230
A lingering banner is not on the list though, since that would need to keep track of a dirty or clean system state.
I removed some of that assumed system state cruft e.g. in monit:
https://github.com/opnsense/core/pull/8894
https://github.com/opnsense/core/pull/8883
https://github.com/opnsense/core/pull/10103
https://github.com/opnsense/core/issues/10230
A lingering banner is not on the list though, since that would need to keep track of a dirty or clean system state.
I removed some of that assumed system state cruft e.g. in monit:
https://github.com/opnsense/core/pull/8894
https://github.com/opnsense/core/pull/8883
