"Recent posts
#1
General Discussion / Re: VLAN support on bridges fr...
Last post by Monviech (Cedrik) - Today at 12:15:46 PMPlease 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.
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.
#2
General Discussion / Re: VLAN support on bridges fr...
Last post by lively1355 - Today at 12:11:50 PMBug report — CARP VIP on VLAN-over-bridge
We 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
What works
The bug
Unicast 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:
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 cause
The 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
Impact
CARP 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.
We 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 bug
Unicast 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:
Code Select
# 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 cause
The 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.
Impact
CARP 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.
#3
26.7 Series / Certificate has no "Purpose" /...
Last post by sommer920471 - Today at 12:04:17 PMHey all,
on OPNsense 26.7.2_2-amd64 my new ACME-issued certificate isn't assigned a "Purpose". Furthermore, when inspecting the response to the /api/trust/cert/search/ request, one can see, it's the only cert with an empty "cert_type" field (aka cert_type: ""). Also, when inspecting the "x509v3 Key Usage" field of the new certificate without a "Purpose", it only shows "Digital Signature", while my other certs, which have an assigned "Purpose", show "Key Encipherment" along "Digital Signature" in said field.
The only notable difference between this "Purpose"-less and my other ACME-issued certs is that this one was issued with Key type "Elliptic Curve secp384r1" instead of "RSA-4096".
Do you perhaps know the reason for this behavior?
Attached is a picture of the overview of some of my current certs to help you understand.
If you need any more information, please feel free to ask.
Best regards,
sommer920471
on OPNsense 26.7.2_2-amd64 my new ACME-issued certificate isn't assigned a "Purpose". Furthermore, when inspecting the response to the /api/trust/cert/search/ request, one can see, it's the only cert with an empty "cert_type" field (aka cert_type: ""). Also, when inspecting the "x509v3 Key Usage" field of the new certificate without a "Purpose", it only shows "Digital Signature", while my other certs, which have an assigned "Purpose", show "Key Encipherment" along "Digital Signature" in said field.
The only notable difference between this "Purpose"-less and my other ACME-issued certs is that this one was issued with Key type "Elliptic Curve secp384r1" instead of "RSA-4096".
Do you perhaps know the reason for this behavior?
Attached is a picture of the overview of some of my current certs to help you understand.
If you need any more information, please feel free to ask.
Best regards,
sommer920471
#4
26.7 Series / Re: where are logs for failed ...
Last post by franco - Today at 11:37:11 AMTo my knowledge AMD wasn't affected and Intel one isn't necessary on DEC hardware and won't load anyway. I'm unsure what problem we're trying to solve.
Cheers,
Franco
Cheers,
Franco
#5
General Discussion / Re: IPV6-ICMP "Echo service re...
Last post by OPNenthu - Today at 11:21:18 AMICMP / Echo Request is for IPv4.
Side note: I've seen a bug in OPNsense when editing rules that sometimes the "ICMP / Echo Request" values stick around when changing the IP version from IPv4 to IPv6. You get an error when trying to save the rule in that case and then you have to just change them to "IPV6-ICMP / Echo service request" manually and re-save.
Side note: I've seen a bug in OPNsense when editing rules that sometimes the "ICMP / Echo Request" values stick around when changing the IP version from IPv4 to IPv6. You get an error when trying to save the rule in that case and then you have to just change them to "IPV6-ICMP / Echo service request" manually and re-save.
#6
26.7 Series / Re: where are logs for failed ...
Last post by DEC740airp414user - Today at 11:12:35 AMI decided to give it try number 4 this morning
I have read on the forums to remove the os-cpu-microcode-intel plugin on certain hardware to fix update issues. I thought for giggles to remove it for my Dec740 appliance. the process went completely different and worked and now I am updated.
was this expected to have to remove the and cpu plugin?
should I reinstall the plugin now?
I have read on the forums to remove the os-cpu-microcode-intel plugin on certain hardware to fix update issues. I thought for giggles to remove it for my Dec740 appliance. the process went completely different and worked and now I am updated.
was this expected to have to remove the and cpu plugin?
should I reinstall the plugin now?
#7
General Discussion / IPV6-ICMP "Echo service reques...
Last post by proctor - Today at 11:00:45 AMHello,
there are two options to get Ping for IPv6 to work:
What is "Echo service request"? - I got no results searching for that exact phrase.
Thanx for any hint.
there are two options to get Ping for IPv6 to work:
- IPv6 / ICMP / Echo Request
- IPv6 / IPV6-ICMP / Echo service request
What is "Echo service request"? - I got no results searching for that exact phrase.
Thanx for any hint.
#8
26.7 Series / Re: Interfaces: Virtual IPs: S...
Last post by MK4L - Today at 10:56:04 AMQuote from: MK4L on Today at 09:06:34 AMIf you could give me direction where this happens inside BSD itself (the side-effect, you say), I will just call it a day.
A day!
#9
German - Deutsch / Re: Interfaces anpassen: WAN a...
Last post by Stephan M. - Today at 10:48:11 AMQuote from: Monviech (Cedrik) on August 06, 2026, 02:25:30 PMDer Plan ist es, dass es irgendwann in der GUI möglich ist.Vielen Dank @Monviech (Cedrik), das werde ich probieren. Klingt aber nach einer guten Option. Vermutlich muss man dann aufpassen, dass opt7 dann überall ersetzt wird durch wan.
https://github.com/opnsense/core/issues/7522
Ansonsten config.xml backup bearbeiten und halt sehr aufpassen und dann importieren.
#10
Intrusion Detection and Prevention / Re: Policy Editor?
Last post by OPNenthu - Today at 10:16:33 AMGot curious as I'd never seen a 'policy editor' UI.
That text seems related to IDS:
https://github.com/opnsense/core/blob/e5f01510072b2602cfe215fbb0d51cda33999035/src/opnsense/mvc/app/controllers/OPNsense/IDS/Api/SettingsController.php#L741
It links to /ui/ids/policy#rules and I guess triggers if rule count > 100.
Makes sense why I never saw this before as I'm not running IDS. OP was right to post in this section but the 'policy' wording is ambiguous and made me also think 'pf' rules :P
That text seems related to IDS:
https://github.com/opnsense/core/blob/e5f01510072b2602cfe215fbb0d51cda33999035/src/opnsense/mvc/app/controllers/OPNsense/IDS/Api/SettingsController.php#L741
It links to /ui/ids/policy#rules and I guess triggers if rule count > 100.
Makes sense why I never saw this before as I'm not running IDS. OP was right to post in this section but the 'policy' wording is ambiguous and made me also think 'pf' rules :P
