Happy New Year!
Searching the forum for VLANs on bridges results in a lot of information and configurations (e.g. link (https://forum.opnsense.org/index.php?topic=29886.msg144322#msg144322), link (https://forum.opnsense.org/index.php?topic=41209.msg202007#msg202007), link (https://forum.opnsense.org/index.php?topic=48601.msg245495#msg245495)) where the bottomline seems to be "bridge over VLANs" and not use (not possible in OPNsense config) VLANs on bridges.
Now I have been reading up on the matter and see that"
- in FreeBSD 14.x man for IF_BRIDGE(4) there is no VLAN support (link (https://man.freebsd.org/cgi/man.cgi?query=if_bridge&apropos=0&sektion=4&manpath=FreeBSD+14.3-RELEASE+and+Ports&arch=default&format=html))
- in FreeBSD 15.x man for IF_BRIDGE(4) there is VLAN support (see quote below, link (https://man.freebsd.org/cgi/man.cgi?query=if_bridge&apropos=0&sektion=4&manpath=FreeBSD+15.0-RELEASE+and+Ports&arch=default&format=html))
Where I am aware that OPNsense is currently based on FreeBSD 14.3 I assume that OPNsense will move to 15.x at some point. this will offer VLAN support on bridges judging by the FreeBSD documentation.
Is this VLAN support on bridges also moving into OPNsense? Couldn't find it on the forum, but when is OPNsense moving to FreeBSD 15.x/16.x?
Arguably, having VLAN support on bridges could make multi-NIC box configurations (such as my trusty Qotom) a little easier with IPTV VLANs, WLAN VLANs, IOT VLANs etc. on top of a multi-NIC LAN_bridge with a single WAN interface. ;-)
From the FreeBSD 15.x man IF_BRIDGE(4)
QuoteVLAN SUPPORT
The if_bridge driver has full support for virtual LANs (VLANs). The
bridge implements independent VLAN learning, i.e. MAC addresses are
learned on a per-VLAN basis, and the same MAC address may be learned on
multiple interfaces on different VLANs. Incoming frames with an 802.1Q
tag will be assigned to the appropriate VLAN.
Traffic sent to or from the host is not assigned to a VLAN by default.
To allow the host to communicate on a VLAN, configure a vlan(4) inter-
face on the bridge and (if necessary) assign IP addresses there.
By default no access control is enabled, so any interface may partici-
pate in any VLAN.
VLAN filtering may be enabled on a bridge using the ifconfig(8)
vlanfilter option. When VLAN filtering is enabled, an interface may
only send and receive frames based on its configured VLAN access list.
The interface's untagged VLAN ID may be configured using the
ifconfig(8) untagged option. If an untagged VLAN ID is configured, in-
coming frames will be assigned to that VLAN, and the interface may re-
ceive outgoing untagged frames in that VLAN.
The tagged VLAN access list may be configured using the tagged, +tagged
and -tagged options to ifconfig(8). An interface may send and receive
tagged frames for any VLAN in its access list.
The bridge will automatically insert or remove 802.1q tags as needed,
based on the interface configuration, when forwarding frames between
interfaces. This tag processing is only done for interfaces with VLAN
filtering enabled.
Quote from: Rene78 on January 01, 2026, 01:28:04 PMSearching the forum for VLANs on bridges results in a lot of information and configurations[...]where the bottomline seems to be "bridge over VLANs" and not use (not possible in OPNsense config) VLANs on bridges.[...]
Are you suggesting that it's not possible to assign a VLAN interface to a bridge? It works fine. I use four bridges with nine VLAN interfaces (interfaces on a 10-port switch, broken out as a port expander) assigned among them.
Currently you can bridge VLAN interfaces but not the other way round.
E.g. with FreeBSD 14:
igc0.1 - VLAN 1 on igc0
igc0.2 - VLAN 2 on igc0
igc1.1 - VLAN 1 on igc1
igc1.2 - VLAN 2 on igc1
bridge1 - members igc0.1, igc1.1
bridge2 - members igc0.2, igc2.2
This works well but is complicated and error prone to set up.
With FreeBSD 15:
bridge0 - members igc0, igc1
bridge0.1 - VLAN 1 on all bridge ports
bridge0.2 - VLAN 2 on all bridge ports
HTH,
Patrick
Quote from: Patrick M. Hausen on January 01, 2026, 03:12:21 PMCurrently you can bridge VLAN interfaces but not the other way round.
E.g. with FreeBSD 14:
igc0.1 - VLAN 1 on igc0
igc0.2 - VLAN 2 on igc0
igc1.1 - VLAN 1 on igc1
igc1.2 - VLAN 2 on igc1
bridge1 - members igc0.1, igc1.1
bridge2 - members igc0.2, igc2.2
This works well but is complicated and error prone to set up.
With FreeBSD 15:
bridge0 - members igc0, igc1
bridge0.1 - VLAN 1 on all bridge ports
bridge0.2 - VLAN 2 on all bridge ports
HTH,
Patrick
Will this also be implemented in OPNsense? Not sure if all FreeBSD options are also implemented in OPNsense
Quote from: Patrick M. Hausen on January 01, 2026, 03:12:21 PMCurrently you can bridge VLAN interfaces but not the other way round.[...]
Ah, I missed the intent. The original VLAN assignment scheme was not a limitation/inconvenience for me. The value added by the new scheme seems limited, as it only provides a more traditional bridge-like configuration with no (apparent) added functionality. Not that I can say much about that, as I treat my firewall like a bridge and my bridges like port expanders, but I could use either method with little modification. (I actually prefer the old method, as some of my equipment is only manageable from VLAN 1, so isolating it would be potentially inconvenient.)
https://github.com/opnsense/core/issues/10576
https://github.com/opnsense/core/pull/10584
Quote from: Monviech (Cedrik) on July 22, 2026, 11:23:51 AMhttps://github.com/opnsense/core/issues/10576
https://github.com/opnsense/core/pull/10584
Thanks for the update. Just to make sure, it is not in OPNSense 26.7.1, correct? While I do not require this feature at this time (currently bridging VLANs), I have upgraded to 26.7.1 and I checked the VLAN setup page in Interfaces/Devices/VLANs and was unable to add a VLAN to a bridge interface.
It was merged today, if you want to use it right away you can try it on 26.7.1 with the following command
opnsense-patch https://github.com/opnsense/core/commit/137513c
If you have any issues you can revert the patch with the same command.
I tested it on my hardware box and everything worked correctly for me. I also did a jail setup and verified the vlans working.
Tests welcome :)
PS:
My test setup looked like this:
Attention: I only used tagged vlans. igc0/igc2 and bridge0 receive only tagged frames from my switch, and don't have layer3 configured. I don't think I would recommend using the bridge0 itself for untagged frames as well. Aka don't use a native vlan if possible, also tag vlan 1 on the switch trunk.
igc0: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
options=4802028<VLAN_MTU,JUMBO_MTU,WOL_MAGIC,HWSTATS,MEXTPG>
ether f4:90:ea:00:d9:f1
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
igc2: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=4802028<VLAN_MTU,JUMBO_MTU,WOL_MAGIC,HWSTATS,MEXTPG>
ether f4:90:ea:00:d9:f3
media: Ethernet autoselect
status: no carrier
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
bridge0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: bridge0 (opt3)
options=10<VLAN_HWTAGGING>
ether 58:9c:fc:10:3b:7c
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
bridge flags=0<>
member: igc2 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
port 3 priority 128 path cost 2000000 vlan protocol 802.1q
member: igc0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
port 1 priority 128 path cost 55 vlan protocol 802.1q
groups: bridge
nd6 options=9<PERFORMNUD,IFDISABLED>
vlan0.3: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1496
description: bridge0_vlan3 (opt5)
options=0
ether 58:9c:fc:10:3b:7c
inet 172.16.2.30 netmask 0xffffff00 broadcast 172.16.2.255
groups: vlan
vlan: 3 vlanproto: 802.1q vlanpcp: 0 parent interface: bridge0
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
vlan0.4: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1496
description: bridge0_vlan4 (opt4)
options=0
ether 58:9c:fc:10:3b:7c
inet 172.16.3.30 netmask 0xffffff00 broadcast 172.16.3.255
groups: vlan
vlan: 4 vlanproto: 802.1q vlanpcp: 0 parent interface: bridge0
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
Quote from: Monviech (Cedrik) on July 22, 2026, 01:37:27 PMIt was merged today, if you want to use it right away you can try it on 26.7.1 with the following command
Tests welcome :)
PS:
My test setup looked like this:
Attention: I only used tagged vlans.
Thanks! I will try and get some time to test it. Not all my physical ports on the OPNsense box are connected to a VLAN capable switch. Some bridge ports are connected to clients directly, such as IoT devices (bridge used there as IOT LAN interface).
On the tagged VLANs... Isn't tagged the only way to process correctly in OPNsense. Untagged would not really make sense to separate stuff, right? From the looks of it, an untagged VLAN cannot be defined in the VLAN interface setup. :)
There are new capabilities to define vlan filtering and per port untagged vlan settings but they will not be implemented in OPNsense since a router is not a managed switch.
Imagine the "confusion of da highest orda" if you could suddenly do full managed switching with a firewall appliance, that would definitely not go wrong... xD
So if you need some untagged "access" ports you might still need the old bridge setup where you bridge single vlans with a single port or whatever you did there.
Thanks for looking into it :)
I think the actual usecase for the real vlan on bridge is very small, mostly e.g for vxlan over VPN setups to span multiple layer 2 networks from headquarters to branch offices... if you know the comparable product it would be like a Sophos SD Red 60.
Quote from: Monviech (Cedrik) on July 22, 2026, 05:04:30 PMThere are new capabilities to define vlan filtering and per port untagged vlan settings but they will not be implemented in OPNsense since a router is not a managed switch.
Agree. ;-)
Quote from: Monviech (Cedrik) on July 22, 2026, 05:04:30 PMSo if you need some untagged stuff you might still need the old bridge setup where you bridge single vlans with a single port or whatever you did there.
Thanks for looking into it :)
I'll probably move my IPTV VLAN (now a local VLAN 40 on igb0 physical port, which is the trunk to a managed switch near my TV) to the bridge (now multiple igbXX, including igb0) which is the LAN (basically combining multiple ports into a single interface (i.e. a switch ;-)). Current setup chosen since I also need the normal LAN (connected to internet) on the managed switch.
With the IPTV VLAN (interface) moved to the bridge (or a new VLAN for testing), it should work out of the box... IGMP proxy etc works on IPs and interfaces. This was not possible earlier.
EDIT: on the other hand... thinking about it.... This might cause a lot of crap on the bridge ports other than igb0... While the IGMP Proxy is obviously on OPNSense, IGMP snooping is not... That is a switch thing.... Need to think some more.
Quote from: Monviech (Cedrik) on July 22, 2026, 01:37:27 PMTests welcome :)
I did today and can confirm it's working on a small MS01.
I will be testing on a Dell R740 in the coming week too.
Our usecase is that we have a 4 port sfp+ NIC passed through to an OPNSense VM on a Dell that is part of a three node Proxmox Cluster.
The vlan-on-bridge feature is actually exactly what we need right now: Bridging the 3 ports for the Proxmox hosts and plugging them straight into the virtualized OPNSense, because we now mitigate the need for an additional switch with this while getting the Proxmox VLAN aware.
Thanks for adding this.
Any idea which update it will land in or when it will be officially rolled out?
Will report back when I have tested with the passed through NIC on the Dell.
Thanks for testing.
I think it might come in 26.7.2 or .3, but there is no schedule for this yet.
Quote from: Monviech (Cedrik) on July 22, 2026, 01:37:27 PMopnsense-patch https://github.com/opnsense/core/commit/137513c
Just wanted to let you know, that the patch does not seem to work with 26.7.2.
Yeah I guess interfaces.inc changed a bit in the meantime, the above patch only works for 26.7.1.
If you patch https://github.com/opnsense/core/commit/6de81ecaf17ed5ba1 beforehand it should work.
Thanks franco.
After applying the recommended patch beforehand and afterwards the patch from Cedrik it is working.
Bug report — CARP VIP on VLAN-over-bridgeWe are running 137513c on
26.7.1_1 per the instructions earlier in this thread — the feature itself works great for us (bridged SFP+ fabric in a virtualized HA pair). With
CARP on top of the VLAN-on-bridge interfaces, however, we hit what looks like a gap in if_bridge's local-delivery path:
ARP and CARP advertisements work, but unicast to the VIP's virtual MAC is never delivered.Setup- bridge0 over five physical members (VM with PCIe passthrough NICs, but nothing here is virtualization-specific).
- L3 untagged directly on bridge0 (assigned interface), plus tagged VLANs vlan0.10 ... vlan0.19 with parent bridge0 (per the patch), each assigned with a static IPv4 and a CARP VIP (vhid = VLAN tag).
- Second node with an identical layout; CARP advertisements cross a bridged peer link.
What works- L3 on the VLAN-on-bridge interfaces: unicast to the interface's own address/MAC is fine.
- CARP election per VLAN: advertisements are sent and received tagged, MASTER/BACKUP negotiate correctly, failover and preempt work.
- ARP for the VIP: clients resolve it and learn the virtual MAC (00:00:5e:00:01:<vhid>).
- A CARP VIP configured on bridge0 itself (the untagged side): fully functional including unicast — this one is not affected.
The bugUnicast frames addressed to the CARP virtual MAC of a VLAN-on-bridge interface are never delivered to that interface's IP stack. Observed on the box itself:
# tcpdump -i bridge0 -e -nn ether host 00:00:5e:00:01:0a
xx:xx:xx:xx:xx:xx > 00:00:5e:00:01:0a, 802.1Q, vlan 10, IPv4,
10.0.10.53 > 10.0.10.3: ICMP echo request ...
(frames arrive continuously)
# tcpdump -i vlan0.10 -nn host 10.0.10.3
(nothing - ever)
So the frames reach bridge0 with the correct tag, but the bridge treats unicast to the VLAN child's virtual MAC as unknown unicast (floods it to the members) instead of delivering it upward. The second HA node shows the same split from its own vantage point: it can ping the untagged VIP on bridge0, but none of the tagged VIPs — with identical CARP config (unique vhids, verified) and a healthy MASTER/BACKUP election on every vhid. The client side shows the classic signature: the VIP's ARP resolves, the neighbor entry then hangs in PROBE, pings to the VIP are 100% loss while pings to the interface address on the same VLAN work — and the firewall log shows the flows as passed, so everything looks healthy.
Suspected causeThe bridge's "is this ours?" check on the RX path appears to match member MACs, the bridge's own MAC, and CARP MACs bound to the bridge interface itself — but not CARP vhids attached to VLAN interfaces stacked on the bridge. The untagged case working while every tagged case fails is consistent with that.
Repro- Apply 137513c on 26.7.1, create bridge0 with at least one member, assign and address it.
- Create vlan0.10 with parent bridge0, assign, address it (e.g. 10.0.10.1/24).
- Add a CARP VIP 10.0.10.3/24, vhid 10, on that VLAN interface.
- From any host on VLAN 10: ping 10.0.10.1 → works; ping 10.0.10.3 → ARP resolves, then 100% loss. tcpdump as above shows the frames dying inside the bridge.
ImpactCARP VIPs on VLANs-over-bridge cannot serve as gateway addresses at all, which silently breaks HA-gateway designs on this topology. It is doubly deceptive because everything observable (election, ARP, firewall logs) looks fine.
Is this addressed in the native FreeBSD 15 / 27.1 implementation, or does it need a separate if_bridge fix (consulting the CARP MACs of stacked VLAN devices in the local-delivery decision)? Happy to test patches — we can reproduce this on demand.
Please prove it with jails:
https://github.com/opnsense/core/pull/10584#issuecomment-5025745485
Example in this comment. You can extend my baseline jail scripts, if you have a reproducible case please share the updated jail scripts.
Thank you.
Reproduced in jails on a clean FreeBSD 15.1-RELEASE (GENERIC). No OPNsense code involved, so this is not specific to the 137513c backport — the native implementation behaves the same way, and 27.1 would inherit it.
I extended your setup script with CARP. Jail b gets a VIP on its vlan3 (over the bridge) and a second VIP untagged on bridge0 itself; jail c gets a VIP on its vlan3 (directly on the epair) as control. Fresh 15.1 VM, kldload carp, nothing else.
Pings from jail a:
- interface addresses (172.16.2.2, 172.16.3.2, 172.16.2.3): all fine
- VIP on vlan-over-epair, jail c (172.16.2.23): fine
- VIP untagged on bridge0 itself, jail b (172.16.3.13): fine
- VIP on vlan3 over bridge0, jail b (172.16.2.13): ARP resolves, then 100% loss. The echo requests show up on epair1b and on bridge0, never on vlan3, and netstat's ICMP input counter in jail b stays flat.
carp_jail_setup.sh (your setup + CARP)
#!/bin/sh
# Extension of Monviech's baseline jail scripts (opnsense/core PR #10584)
# to reproduce: CARP VIP on a VLAN-over-bridge interface does not receive unicast.
#
# jail a = client (tagged vlan3 + untagged leg)
# jail b = DUT: vlan3 stacked on an internal bridge0
# -> CARP VIP on vlan3 (vhid 13, 172.16.2.13) = the bug case
# -> CARP VIP on bridge0 (vhid 33, 172.16.3.13) = control, untagged on the bridge itself
# jail c = control: vlan3 directly on the epair
# -> CARP VIP on vlan3 (vhid 23, 172.16.2.23) = control, no bridge involved
kldload -n carp
ifconfig epair0 create
ifconfig epair1 create
ifconfig epair2 create
ifconfig bridge0 create \
addm epair0a \
addm epair1a \
addm epair2a \
up
ifconfig epair0a up
ifconfig epair1a up
ifconfig epair2a up
jail -c name=a path=/ persist vnet allow.raw_sockets=1
jail -c name=b path=/ persist vnet allow.raw_sockets=1
jail -c name=c path=/ persist vnet allow.raw_sockets=1
ifconfig epair0b vnet a
ifconfig epair1b vnet b
ifconfig epair2b vnet c
# jail a - client
jexec a ifconfig epair0b inet 172.16.3.1/24 up
jexec a ifconfig vlan3 create vlan 3 vlandev epair0b
jexec a ifconfig vlan3 inet 172.16.2.1/24 up
# jail b - DUT: vlan on bridge, CARP on both layers
jexec b ifconfig epair1b up
jexec b ifconfig bridge0 create addm epair1b up
jexec b ifconfig bridge0 inet 172.16.3.2/24
jexec b ifconfig vlan3 create vlan 3 vlandev bridge0
jexec b ifconfig vlan3 inet 172.16.2.2/24 up
jexec b ifconfig vlan3 vhid 13 pass testpass alias 172.16.2.13/32
jexec b ifconfig bridge0 vhid 33 pass testpass alias 172.16.3.13/32
# jail c - control: vlan directly on the epair, CARP on it
jexec c ifconfig epair2b up
jexec c ifconfig vlan3 create vlan 3 vlandev epair2b
jexec c ifconfig vlan3 inet 172.16.2.3/24 up
jexec c ifconfig vlan3 vhid 23 pass testpass alias 172.16.2.23/32
carp_jail_test.sh#!/bin/sh
# Test companion to carp_jail_setup.sh - CARP VIP on VLAN-over-bridge repro.
# Expected on an affected kernel:
# interface addresses : all reachable
# VIP on vlan-over-epair (c) : reachable (control 1)
# VIP untagged on bridge (b) : reachable (control 2)
# VIP on vlan-over-bridge (b): ARP resolves, 100% loss - frames visible on
# the bridge member and bridge0, never on vlan3,
# ICMP input counter on b does not move. (BUG)
LOG=${1:-carp-vlan-bridge-test.log}
TMP=/tmp/carp-vlan-bridge-test.$$
wait_master() { # jail iface
n=0
while [ $n -lt 15 ]; do
jexec "$1" ifconfig "$2" | grep -q "carp: MASTER" && return 0
sleep 1; n=$((n+1))
done
echo "WARNING: $1/$2 never reached MASTER"
jexec "$1" ifconfig "$2"
}
icmp_in_echo() { # jail - echo requests received (Input histogram: echo)
jexec "$1" netstat -s -p icmp | sed -n '/Input histogram/,/^[^[:space:]]/p' \
| awk '/echo:/{print $2; exit}'
}
{
echo "=== CARP election state ==="
wait_master b vlan3
wait_master b bridge0
wait_master c vlan3
jexec b ifconfig vlan3
jexec b ifconfig bridge0
jexec c ifconfig vlan3
echo
echo "=== baseline: interface addresses ==="
jexec a ping -c 2 -t 4 172.16.2.2 || true
jexec a ping -c 2 -t 4 172.16.3.2 || true
jexec a ping -c 2 -t 4 172.16.2.3 || true
echo
echo "=== CONTROL 1: CARP VIP on vlan-over-EPAIR (c, 172.16.2.23, vhid 23) ==="
jexec a ping -c 2 -t 4 172.16.2.23 || true
echo
echo "=== CONTROL 2: CARP VIP UNTAGGED on the bridge itself (b, 172.16.3.13, vhid 33) ==="
jexec a ping -c 2 -t 4 172.16.3.13 || true
echo
echo "=== BUG CASE: CARP VIP on vlan-over-BRIDGE (b, 172.16.2.13, vhid 13) ==="
BEFORE=$(icmp_in_echo b)
jexec b tcpdump -nlei epair1b ether host 00:00:5e:00:01:0d >"${TMP}.member" 2>&1 &
PID0=$!
jexec b tcpdump -nlei bridge0 ether host 00:00:5e:00:01:0d >"${TMP}.bridge" 2>&1 &
PID1=$!
jexec b tcpdump -nlei vlan3 host 172.16.2.13 >"${TMP}.vlan" 2>&1 &
PID2=$!
sleep 1
jexec a ping -c 3 -t 6 172.16.2.13 || true
sleep 1
kill "$PID0" "$PID1" "$PID2" 2>/dev/null
wait "$PID0" "$PID1" "$PID2" 2>/dev/null
AFTER=$(icmp_in_echo b)
echo
echo "--- client (a) neighbor table: virtual MAC resolved? ---"
jexec a arp -an | grep 172.16.2.13 || echo "(no ARP entry)"
echo
echo "--- ICMP echo requests received by b's stack: before=$BEFORE after=$AFTER ---"
echo
echo "--- tcpdump b:epair1b, bridge member (frames TO the virtual MAC 00:00:5e:00:01:0d) ---"
cat "${TMP}.member"
echo
echo "--- tcpdump b:bridge0 (frames TO the virtual MAC 00:00:5e:00:01:0d) ---"
cat "${TMP}.bridge"
echo
echo "--- tcpdump b:vlan3 (host 172.16.2.13) ---"
cat "${TMP}.vlan"
} >"$LOG" 2>&1
rm -f "${TMP}.member" "${TMP}.bridge" "${TMP}.vlan"
cat "$LOG"
carp_jail_teardown.sh#!/bin/sh
for j in a b c; do
jail -r "$j" 2>/dev/null
done
for i in epair0a epair1a epair2a; do
ifconfig "$i" destroy 2>/dev/null
done
ifconfig bridge0 destroy 2>/dev/null
Log excerpts (full log available if useful):
$ uname -a
FreeBSD carp-jailtest 15.1-RELEASE FreeBSD 15.1-RELEASE releng/15.1-n283562-96841ea08dcf GENERIC amd64
=== CONTROL 1: CARP VIP on vlan-over-EPAIR (c, 172.16.2.23, vhid 23) ===
2 packets transmitted, 2 packets received, 0.0% packet loss
=== CONTROL 2: CARP VIP UNTAGGED on the bridge itself (b, 172.16.3.13, vhid 33) ===
2 packets transmitted, 2 packets received, 0.0% packet loss
=== BUG CASE: CARP VIP on vlan-over-BRIDGE (b, 172.16.2.13, vhid 13) ===
3 packets transmitted, 0 packets received, 100.0% packet loss
--- client (a) neighbor table: virtual MAC resolved? ---
? (172.16.2.13) at 00:00:5e:00:01:0d on vlan3 expires in 1193 seconds [vlan]
--- ICMP echo requests received by b's stack: before=6 after=6 ---
--- tcpdump b:epair1b, bridge member (frames TO the virtual MAC 00:00:5e:00:01:0d) ---
10:45:21.508388 58:9c:fc:10:6e:52 > 00:00:5e:00:01:0d, ethertype 802.1Q (0x8100), length 102: vlan 3, p 0, ethertype IPv4 (0x0800), 172.16.2.1 > 172.16.2.13: ICMP echo request, id 33033, seq 0, length 64
10:45:22.577402 58:9c:fc:10:6e:52 > 00:00:5e:00:01:0d, ethertype 802.1Q (0x8100), length 102: vlan 3, p 0, ethertype IPv4 (0x0800), 172.16.2.1 > 172.16.2.13: ICMP echo request, id 33033, seq 1, length 64
10:45:23.605646 58:9c:fc:10:6e:52 > 00:00:5e:00:01:0d, ethertype 802.1Q (0x8100), length 102: vlan 3, p 0, ethertype IPv4 (0x0800), 172.16.2.1 > 172.16.2.13: ICMP echo request, id 33033, seq 2, length 64
--- tcpdump b:vlan3 (host 172.16.2.13) ---
10:45:21.508379 58:9c:fc:10:6e:52 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.2.13 tell 172.16.2.1, length 28
10:45:21.508382 26:00:ce:58:28:8e > 58:9c:fc:10:6e:52, ethertype ARP (0x0806), length 42: Reply 172.16.2.13 is-at 00:00:5e:00:01:0d, length 28
(nothing else - the echo requests never appear)
So ARP and CARP adverts go out via vlan3, but inbound unicast to 00:00:5e:00:01:0d stops between bridge0 and vlan3.
Do you want me to add this to github as well or shall we continue here?
Quote from: lively1355 on Today at 12:54:10 PMReproduced in jails on a clean FreeBSD 15.1-RELEASE (GENERIC). No OPNsense code involved, so this is not specific to the 137513c backport — the native implementation behaves the same way, and 27.1 would inherit it.
Since there is a lot of ongoing work being put into the bridge subsystem, most of it by Lexi, did you open an issue on the FreeBSD bug tracker, or is there one, already?
Quote from: Patrick M. Hausen on Today at 01:00:59 PMSince there is a lot of ongoing work being put into the bridge subsystem, most of it by Lexi, did you open an issue on the FreeBSD bug tracker, or is there one, already?
No I have not and haven't checked either. Just ran the tests according to Monviech's instructions.
Very cool, thank you.
All three neighboring cases:
VLAN over bridge with normal interface MAC works.
CARP directly on the bridge works.
CARP on VLAN over a normal epair works.
-> Only CARP on VLAN over bridge fails.
This is definitely freebsd bug territory now as Patrick also suggested:
https://bugs.freebsd.org/bugzilla/
If you have opened one you can also backlink it here:
https://github.com/opnsense/src/issues
Thank you for your help!