OPNsense 26.7.4 - VLAN traffic failing over X550/LAGG/bridge after upgrade

Started by merrins63, September 28, 2026, 01:38:52 PM

Previous topic - Next topic
Print
Go Down Pages1
User actions
September 28, 2026, 01:38:52 PM
Hi all,

I'm troubleshooting a VLAN issue that appeared after upgrading to OPNsense 26.7.4 / FreeBSD 15.1.

My setup is roughly:
Cisco 2960X
    |
Po3 LACP / 802.1Q
    |
Intel X550 ix0 + ix1
    |
  lagg0
    |
 VLAN interfaces
    |
 OPNsense bridges
    |
Kea DHCP

I also have an Intel i226 2.5 GbE trunk, with corresponding VLAN interfaces bridged to the X550/LAGG VLAN interfaces.

This affects all VLANs traversing the Cisco 2960X /   Intel X550 LAGG path. VLAN 15 is simply the VLAN I am using for troubleshooting.

Clients on the Cisco side fail DHCP and remain on 169.254.x.x.

Cisco switch looks healthy: Po3 is UP, both LACP members are bundled, VLAN 15 is forwarding, and the test client MAC is correctly learned on its VLAN 15 access port.

The interesting part is simultaneous packet captures of the same DHCP transaction:

bridge1:      DHCP REQUEST ✓   ACK ✓
vlan0.1.15:   DHCP REQUEST ✓   ACK ✓
lagg0:        DHCP not visible
ix0 / ix1:    DHCP not visible

Kea therefore appears to receive the request and generate an ACK, but the client never receives/configures the lease.

I found FreeBSD bug 276936, describing packet-forwarding problems involving ixgbe, VLAN interfaces and bridges. The topology isn't identical, but it looks potentially relevant.

Has anyone experienced similar issues with OPNsense 26.7, Intel X550, LAGG/LACP, VLANs and bridges, or have suggestions for further diagnostics?

Any help or feedback would be greatly appreciated, as I am stuck until I can fix this, as my network relies on the VLAN Bridges to connect my home network

Thanks in advance
Today at 08:03:39 AM #1
Hi Team

I have found that there is a bug, meaning I have found the root cause of the issue

The issue is that when you use Bridged VLANs, you cannot use Kea DHCP, it simply doesnt allow you to connect

When you use Bridged VLANS, you must use ISC Legacy DHCP, I have confirmed my connection issue is resolved

If anyone in the OPNsense forum knows how to report a bug, as I believe this is a bug in the system

Regards
Today at 08:13:33 AM #2
Can you post the full output of "ifconfig", please? You can remove public IP addresses.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)
Today at 10:09:21 AM #3
Hi Patrick

Thanks for replying to my post!

Please see the ifconfig output below. I've redacted a few personal details from the VLAN/interface descriptions, but the underlying configuration and topology remain unchanged, so hopefully it provides everything needed to understand the setup.

My ultimate goal is to move away from Legacy ISC DHCP and transition fully to Kea DHCP. That was actually one of the objectives when I rebuilt the router from scratch on OPNsense 26.7.4.

At the moment, the bridged VLAN configuration is working correctly with Legacy ISC DHCP, whereas I have been unable to achieve the same result with Kea.

Thanks again for taking the time to look at this.
----------------------------------------------------
root@OPNsense:~ # ifconfig

ix0: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
options=4803828<VLAN_MTU,JUMBO_MTU,WOL_UCAST,WOL_MCAST,WOL_MAGIC,HWSTATS,MEXTPG>
ether (redacted MAC)
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

ix1: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
options=4803828<VLAN_MTU,JUMBO_MTU,WOL_UCAST,WOL_MCAST,WOL_MAGIC,HWSTATS,MEXTPG>
ether (redacted MAC)
hwaddr (redacted MAC)
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

igc0: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: TRUNK (lan)
options=4902028<VLAN_MTU,JUMBO_MTU,WOL_MAGIC,NETMAP,HWSTATS,MEXTPG>
ether (redacted MAC)
inet 10.100.14.1 netmask 0xfffffff8 broadcast 10.100.14.7
groups: Interface_GROUP
media: Ethernet autoselect (2500Base-T <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

igc1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
description: WAN (wan)
options=4802028<VLAN_MTU,JUMBO_MTU,WOL_MAGIC,HWSTATS,MEXTPG>
ether (redacted MAC)
inet6 (redacted IPv6)
groups: Interface_GROUP
media: Ethernet autoselect
status: no carrier
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>

lo0: flags=1008049<UP,LOOPBACK,RUNNING,MULTICAST,LOWER_UP> metric 0 mtu 16384
options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
inet 127.0.0.1 netmask 0xff000000
inet 10.100.100.1 netmask 0xffffffff
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
groups: lo
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

enc0: flags=0 metric 0 mtu 1536
options=0
groups: enc
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

pflog0: flags=0 metric 0 mtu 33152
options=0
groups: pflog

pfsync0: flags=0 metric 0 mtu 1500
options=0
maxupd: 128 defer: off version: 1500
syncok: 1
groups: pfsync

lagg0: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: LAGG_INTERFACE (opt1)
options=4903828<VLAN_MTU,JUMBO_MTU,WOL_UCAST,WOL_MCAST,WOL_MAGIC,NETMAP,HWSTATS,MEXTPG>
ether (redacted MAC)
hwaddr 00:00:00:00:00:00
inet 10.100.23.1 netmask 0xfffffff8 broadcast 10.100.23.7
laggproto lacp lagghash l2,l3,l4
laggport: ix0 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
laggport: ix1 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
groups: lagg
media: Ethernet autoselect
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

vlan0.1.10: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: (redacted VLAN 10 interface)
options=4000000<MEXTPG>
ether (redacted MAC)
groups: vlan (redacted VLAN groups)
vlan: 10 vlanproto: 802.1q vlanpcp: 0 parent interface: lagg0
media: Ethernet autoselect
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

vlan0.2.10: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: (redacted VLAN 10 interface)
options=4000000<MEXTPG>
ether (redacted MAC)
groups: vlan (redacted VLAN groups)
vlan: 10 vlanproto: 802.1q vlanpcp: 0 parent interface: igc0
media: Ethernet autoselect (2500Base-T <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

vlan0.1.15: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: (redacted VLAN 15 interface)
options=4000000<MEXTPG>
ether (redacted MAC)
groups: vlan (redacted VLAN groups)
vlan: 15 vlanproto: 802.1q vlanpcp: 0 parent interface: lagg0
media: Ethernet autoselect
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

vlan0.2.15: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: (redacted VLAN 15 interface)
options=4000000<MEXTPG>
ether (redacted MAC)
groups: vlan (redacted VLAN groups)
vlan: 15 vlanproto: 802.1q vlanpcp: 0 parent interface: igc0
media: Ethernet autoselect (2500Base-T <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

vlan0.1.20:
description: (redacted VLAN 20 interface)
ether (redacted MAC)
groups: vlan (redacted VLAN groups)
vlan: 20 vlanproto: 802.1q vlanpcp: 0 parent interface: lagg0
status: active

vlan0.2.20:
description: (redacted VLAN 20 interface)
ether (redacted MAC)
groups: vlan (redacted VLAN groups)
vlan: 20 vlanproto: 802.1q vlanpcp: 0 parent interface: igc0
media: Ethernet autoselect (2500Base-T <full-duplex>)
status: active

vlan0.1.30:
description: (redacted VLAN 30 interface)
ether (redacted MAC)
groups: vlan (redacted VLAN groups)
vlan: 30 vlanproto: 802.1q vlanpcp: 0 parent interface: lagg0
status: active

vlan0.2.30:
description: (redacted VLAN 30 interface)
ether (redacted MAC)
groups: vlan (redacted VLAN groups)
vlan: 30 vlanproto: 802.1q vlanpcp: 0 parent interface: igc0
media: Ethernet autoselect (2500Base-T <full-duplex>)
status: active

vlan0.1.35:
description: (redacted VLAN 35 interface)
ether (redacted MAC)
groups: vlan (redacted VLAN groups)
vlan: 35 vlanproto: 802.1q vlanpcp: 0 parent interface: lagg0
status: active

vlan0.2.35:
description: (redacted VLAN 35 interface)
ether (redacted MAC)
groups: vlan (redacted VLAN groups)
vlan: 35 vlanproto: 802.1q vlanpcp: 0 parent interface: igc0
media: Ethernet autoselect (2500Base-T <full-duplex>)
status: active

vlan0.1.40:
description: (redacted VLAN 40 interface)
ether (redacted MAC)
groups: vlan (redacted VLAN groups)
vlan: 40 vlanproto: 802.1q vlanpcp: 0 parent interface: lagg0
status: active

vlan0.2.40:
description: (redacted VLAN 40 interface)
ether (redacted MAC)
groups: vlan (redacted VLAN groups)
vlan: 40 vlanproto: 802.1q vlanpcp: 0 parent interface: igc0
media: Ethernet autoselect (2500Base-T <full-duplex>)
status: active

vlan0.1.45:
description: (redacted VLAN 45 interface)
ether (redacted MAC)
groups: vlan (redacted VLAN groups)
vlan: 45 vlanproto: 802.1q vlanpcp: 0 parent interface: lagg0
status: active

vlan0.2.45:
description: (redacted VLAN 45 interface)
ether (redacted MAC)
groups: vlan (redacted VLAN groups)
vlan: 45 vlanproto: 802.1q vlanpcp: 0 parent interface: igc0
media: Ethernet autoselect (2500Base-T <full-duplex>)
status: active

bridge0:
description: BRIDGE_VLAN10_INTERFACE
ether (redacted MAC)
inet 10.100.10.1 netmask 0xffffff00 broadcast 10.100.10.255
proto rstp maxaddr 2000 timeout 1200
member: vlan0.2.10 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
        port 11 priority 128 path cost 20000 vlan protocol 802.1q
member: vlan0.1.10 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
        port 10 priority 128 path cost 55 vlan protocol 802.1q
groups: bridge (redacted bridge groups)

bridge1:
description: BRIDGE_VLAN15_INTERFACE
ether (redacted MAC)
inet 10.100.15.1 netmask 0xffffff00 broadcast 10.100.15.255
proto rstp maxaddr 2000 timeout 1200
member: vlan0.2.15 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
        port 13 priority 128 path cost 20000 vlan protocol 802.1q
member: vlan0.1.15 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
        port 12 priority 128 path cost 55 vlan protocol 802.1q
groups: bridge (redacted bridge groups)

bridge2:
description: BRIDGE_VLAN20_INTERFACE
ether (redacted MAC)
inet 192.168.50.1 netmask 0xffffff00 broadcast 192.168.50.255
proto rstp maxaddr 2000 timeout 1200
member: vlan0.2.20 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
member: vlan0.1.20 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
groups: bridge (redacted bridge groups)

bridge3:
description: BRIDGE_VLAN30_INTERFACE
ether (redacted MAC)
inet 10.100.30.1 netmask 0xffffff00 broadcast 10.100.30.255
member: vlan0.2.30 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
member: vlan0.1.30 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
groups: bridge (redacted bridge groups)

bridge4:
description: BRIDGE_VLAN35_INTERFACE
ether (redacted MAC)
inet 10.100.35.1 netmask 0xffffff00 broadcast 10.100.35.255
member: vlan0.2.35 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
member: vlan0.1.35 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
groups: bridge (redacted personal bridge groups)

bridge5:
description: BRIDGE_VLAN40_INTERFACE
ether (redacted MAC)
inet 10.100.40.1 netmask 0xffffff00 broadcast 10.100.40.255
member: vlan0.2.40 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
member: vlan0.1.40 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
groups: bridge (redacted personal bridge groups)

bridge6:
description: BRIDGE_VLAN45_INTERFACE
ether (redacted MAC)
inet 10.100.45.1 netmask 0xffffff00 broadcast 10.100.45.255
member: vlan0.2.45 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
member: vlan0.1.45 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
groups: bridge (redacted personal bridge groups)

zen0:
flags=8010<POINTOPOINT,MULTICAST> metric 0 mtu 1500
groups: tun (redacted VPN group)
---------------------------------------------------------------------
Today at 10:33:41 AM #4
Alright. You VLAN and bridge configuration is correct. You assigned the OPNsense interfaces to the bridges and there are no IP addresses on any bridge members.

I assume you enabled Kea on the bridge interfaces, too? Can't do anything but use the assigned symbolic names in the UI if I am not mistaken. Are you trying with raw or UDP sockets? Should be raw, IMHO.

Kind regards,
Patrick
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)
Today at 11:13:52 AM #5
Hi Patrick,

Thanks for confirming that the VLAN/bridge configuration itself looks correct.

Yes, when I was originally testing Kea, I configured the DHCPv4 subnets against the assigned OPNsense bridge interfaces, not against the individual VLAN bridge members.

For example, VLAN 15 is effectively:

lagg0 -> vlan0.1.15 ---\
                        bridge1 -> 10.100.15.1/24
igc0  -> vlan0.2.15 ---/

The IP address/gateway resides only on bridge1. Neither vlan0.1.15 nor vlan0.2.15 has an IP address.

With Kea enabled, the client would send DHCP requests but would ultimately fail to obtain/configure an address.

To eliminate Kea from the equation, I then performed the following test:

Disabled the relevant Kea DHCP interfaces/subnets.
Stopped/disabled Kea so that it was no longer servicing DHCP.
Enabled Legacy ISC DHCPv4 on the assigned bridge interface.
Configured the same subnet, gateway and DHCP pool on the bridge.
Renewed DHCP from the same client, through the same Cisco switch, LAGG, VLAN and OPNsense bridge topology.

With ISC DHCP, the client successfully received a lease:

Client:  10.100.15.10/24
Gateway: 10.100.15.1
DNS:     10.100.100.1

I also tested the client with a static address (10.100.15.150/24) beforehand and confirmed bidirectional connectivity to the bridge gateway at 10.100.15.1.

So at this point the same underlying bridge/VLAN topology works for normal IP traffic and successfully provides DHCP when using Legacy ISC DHCP. The failure appears when I use Kea instead.

Regarding raw versus UDP sockets, I did not intentionally change Kea away from its default socket behaviour. My understanding is that Kea DHCPv4 uses raw sockets by default, unless dhcp-socket-type is explicitly configured otherwise. ISC's Kea documentation also notes that UDP sockets have limitations when responding directly to clients that do not yet have an IPv4 address.

I have a backup configuration on my test Virtual firewall, I can produce this if required.

Kind regards,
Stefan
 
Today at 11:19:02 AM #6
Can you show the Kea configuration? Possibly I can spot something "wrong"?

Also, but this is probably not related to the problem - with your advanced use of bridges I'd recommend creating and setting this tunable:

tunable: net.link.bridge.inherit_mac
value: 1

This way the bridges have a static MAC address across reboots.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)
Today at 11:27:46 AM #7
Hi Patrick,

Thanks, that would be greatly appreciated.

I can provide the generated Kea DHCPv4 configuration. Before I switched over to Legacy ISC for testing, Kea was configured against the assigned bridge interfaces themselves, not the individual VLAN members.

For example, VLAN 15 is:
lagg0 -> vlan0.1.15 ---\
                        bridge1 -> 10.100.15.1/24
igc0  -> vlan0.2.15 ---/

Neither VLAN member has an IP address. The IPv4 address exists only on bridge1.

For the A/B test I completely disabled the Kea DHCP interfaces/service before enabling Legacy ISC DHCPv4 on the bridge. With essentially the same subnet, pool, gateway and DNS configuration, ISC successfully leases addresses across the bridge. The same Mac that previously failed with Kea immediately obtained 10.100.15.10/24 via ISC and could communicate normally.

So at present the evidence is:
Same client
Same switch port
Same Cisco trunk/LACP
Same VLAN interfaces
Same bridge
Same OPNsense gateway

Kea DHCP  -> fails
ISC DHCP  -> works

Regarding the socket type, I did not deliberately change Kea to UDP sockets. Kea normally uses raw sockets by default, unless dhcp-socket-type is explicitly configured otherwise.

I'll retrieve the actual generated Kea configuration so we can confirm exactly:

"interfaces-config": {
    "interfaces": [...],
    "dhcp-socket-type": "..."
}

Thanks for that suggestion. I hadn't configured it.

I checked the FreeBSD 15.1 bridge documentation. A non-zero net.link.bridge.inherit_mac causes a newly created bridge to inherit the MAC address of its first member, providing a more predictable bridge MAC. However, FreeBSD currently describes this feature as experimental, disabled by default, and notes that it can break some L2 protocols such as PPPoE.

Given that, I'll certainly investigate it, but I'd prefer to keep it separate from the DHCP troubleshooting initially so that I don't introduce another variable while comparing Kea against ISC.

Kind regards,
Stefan
Today at 11:30:36 AM #8
Quote from: merrins63 on Today at 11:27:46 AMI can provide the generated Kea DHCPv4 configuration.

So please do :-)
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)
Today at 12:28:03 PM #9
Hi Patrick,

Absolutely. I managed to retrieve the actual generated Kea DHCPv4 configuration from the firewall. I've only redacted the internal domain name, UUIDs and descriptive labels. The technically relevant configuration is unchanged.

This also confirms your earlier question regarding socket type. Kea was configured with:

"dhcp-socket-type": "raw"

Please see the below extract from my Test Firewall

________________________________________________
{
    "Dhcp4": {
        "valid-lifetime": 4000,
        "decline-probation-period": 600,

        "interfaces-config": {
            "interfaces": [
                "bridge0",
                "bridge1",
                "bridge2",
                "bridge3",
                "bridge4",
                "bridge5",
                "bridge6",
                "vtnet1",
                "lagg0",
                "vtnet4"
            ],
            "dhcp-socket-type": "raw",
            "service-sockets-max-retries": 5,
            "service-sockets-retry-wait-time": 5000
        },

        "lease-database": {
            "type": "memfile",
            "persist": true
        },

        "control-socket": {
            "socket-type": "unix",
            "socket-name": "/var/run/kea/kea4-ctrl-socket"
        },

        "loggers": [
            {
                "name": "kea-dhcp4",
                "output_options": [
                    {
                        "output": "syslog"
                    }
                ],
                "severity": "INFO"
            }
        ],

        "subnet4": [
            {
                "id": 1,
                "subnet": "10.100.100.0/24",
                "next-server": "",
                "match-client-id": true,
                "option-data": [
                    {
                        "name": "domain-name-servers",
                        "data": "10.100.100.1"
                    },
                    {
                        "name": "routers",
                        "data": "10.100.100.1"
                    },
                    {
                        "name": "domain-name",
                        "data": "(redacted internal domain)"
                    }
                ],
                "pools": [
                    {
                        "pool": "10.100.100.10-10.100.100.20"
                    }
                ],
                "reservations": [],
                "valid-lifetime": 86400,
                "user-context": {
                    "uuid": "(redacted UUID)",
                    "description": "(redacted subnet description)"
                }
            },

            {
                "id": 2,
                "subnet": "10.100.14.1/29",
                "next-server": "",
                "match-client-id": true,
                "option-data": [
                    {
                        "name": "domain-name-servers",
                        "data": "10.100.100.1"
                    },
                    {
                        "name": "routers",
                        "data": "10.100.14.1"
                    },
                    {
                        "name": "domain-name",
                        "data": "(redacted internal domain)"
                    }
                ],
                "pools": [
                    {
                        "pool": "10.100.14.2-10.100.14.6"
                    }
                ],
                "reservations": [],
                "valid-lifetime": 86400,
                "user-context": {
                    "uuid": "(redacted UUID)",
                    "description": "(redacted subnet description)"
                }
            },

            {
                "id": 3,
                "subnet": "10.100.10.0/24",
                "next-server": "",
                "match-client-id": true,
                "option-data": [
                    {
                        "name": "domain-name-servers",
                        "data": "10.100.100.1"
                    },
                    {
                        "name": "routers",
                        "data": "10.100.10.1"
                    },
                    {
                        "name": "domain-name",
                        "data": "(redacted internal domain)"
                    }
                ],
                "pools": [
                    {
                        "pool": "10.100.10.10-10.100.10.250"
                    }
                ],
                "reservations": [],
                "valid-lifetime": 86400,
                "user-context": {
                    "uuid": "(redacted UUID)",
                    "description": "(redacted VLAN 10 description)"
                }
            },

            {
                "id": 4,
                "subnet": "10.100.15.0/24",
                "next-server": "",
                "match-client-id": true,
                "option-data": [
                    {
                        "name": "domain-name-servers",
                        "data": "10.100.100.1"
                    },
                    {
                        "name": "routers",
                        "data": "10.100.15.1"
                    },
                    {
                        "name": "domain-name",
                        "data": "(redacted internal domain)"
                    }
                ],
                "pools": [
                    {
                        "pool": "10.100.15.10-10.100.15.250"
                    }
                ],
                "reservations": [],
                "valid-lifetime": 86400,
                "user-context": {
                    "uuid": "(redacted UUID)",
                    "description": "(redacted VLAN 15 description)"
                }
            },

            {
                "id": 5,
                "subnet": "10.100.23.1/29",
                "next-server": "",
                "match-client-id": true,
                "option-data": [
                    {
                        "name": "domain-name-servers",
                        "data": "10.100.100.1"
                    },
                    {
                        "name": "routers",
                        "data": "10.100.23.1"
                    },
                    {
                        "name": "domain-name",
                        "data": "(redacted internal domain)"
                    }
                ],
                "pools": [
                    {
                        "pool": "10.100.23.2-10.100.23.6"
                    }
                ],
                "reservations": [],
                "valid-lifetime": 86400,
                "user-context": {
                    "uuid": "(redacted UUID)",
                    "description": "(redacted subnet description)"
                }
            }
        ],

        "hooks-libraries": [
            {
                "library": "/usr/local/lib/kea/hooks/libdhcp_lease_cmds.so"
            },
            {
                "library": "/usr/local/lib/kea/hooks/libdhcp_host_cmds.so"
            }
        ]
    }
}
_______________________________________________________________________

Regards
Today at 01:02:26 PM #10
Code Select
[...]
                "subnet": "10.100.14.1/29",
[...]
                "subnet": "10.100.23.1/29",
[...]

These are not valid subnets. 10.100.14.0/29 and 10.100.23.ü/29 would be if that is what is intended.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)
Today at 01:09:31 PM #11
Thanks, good spot.

Those two /29 entries are unrelated to the issue I'm troubleshooting. They are temporary device/transit networks on this test firewall and were not involved in the DHCP testing.

The relevant test networks are:

VLAN 10
Subnet: 10.100.10.0/24
Gateway: 10.100.10.1
Bridge: bridge0

VLAN 15
Subnet: 10.100.15.0/24
Gateway: 10.100.15.1
Bridge: bridge1


VLAN 15 has been my primary troubleshooting network. With the same bridge configuration and client:

Kea DHCP  -> client fails to obtain/use a lease
ISC DHCP  -> client successfully receives 10.100.15.10/24
Static IP -> connectivity to 10.100.15.1 works

So please focus primarily on the 10.100.10.0/24 and 10.100.15.0/24 Kea configuration.

I'll correct the two /29 definitions separately. Thanks for spotting them
Today at 01:20:12 PM #12 Last Edit: Today at 01:23:18 PM by Patrick M. Hausen
These definitions match the interface configuration. I am out of ideas ... er ... one moment ...

Did you check this option?



If you did not that would perfectly explain your observed symptoms.

ISC creates the necessary firewall rules for DHCP to work by default, if I remember correctly. For Kea that's optional, because some users complained that OPNsense should not create any rules automatically giving full control to the admin.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)
Today at 03:17:58 PM #13
I have got a question that really bugs me :

Why would you do this =>
Quote from: merrins63 on September 28, 2026, 01:38:52 PMI also have an Intel i226 2.5 GbE trunk, with corresponding VLAN interfaces bridged to the X550/LAGG VLAN interfaces.
Aren't you effectively Bridging 2x 2,5 Gbps with 2 x 10 Gbps ?!

What is the purpose of such a setup ??
Weird guy who likes everything Linux and *BSD on PC/Laptop/Tablet/Mobile and funny little ARM based boards :)
Print
Go Up Pages1
User actions