OPNsense Forum

Setup

• OPNsense 26.1.8_5 running as VM on Proxmox VE 8.4
  
• VM has one virtio vNIC (vtnet0) on a Proxmox VLAN-aware bridge
  
• All interfaces are VLAN sub-interfaces of vtnet0:
  
  • LAN (untagged)
    
  • WAN (vlan0.11) → Vodafone Kabel, DHCP
    
  • WAN1 (vlan0.12) → fallback ISP, DHCP, working
    
• Between OPNsense and the Vodafone modem: Mikrotik switch (SwOS) — modem-facing port set to access on VLAN 11 (vlan-mode=strict, vlan receive=only untagged, default vlan id=11)
  
• Hardware offloading disabled in OPNsense
• Setup worked reliably in Bridge Mode until 4 May 2026. No deliberate changes were made to OPNsense, Proxmox, or the Mikrotik around that date.
  

Current behaviour

Modem in Bridge Mode

• OPNsense vlan0.11 sends DHCP DISCOVER, correctly tagged VLAN 11 (verified via tcpdump on vtnet0).
  
• No DHCP OFFER is returned to OPNsense.
  
• The same capture shows Vodafone CMTS DHCP traffic on the shared segment addressed to other modems' MACs (83.169.171.66 → kabelmodemaktivieren.vodafone.de) — so the bridge passes traffic, the line is up, and Vodafone DHCP is alive.
  
• A laptop plugged directly into the modem (MAC 1c:bf:ce:be:47:8d) receives a public IP immediately.
  
• WAN1 (vlan0.12), same vtnet0, same Proxmox bridge, same Mikrotik switch — works.
  

Modem in Router Mode

• OPNsense vlan0.11 receives a DHCP lease from the modem itself: 192.168.0.x/24, gateway 192.168.0.1.
  
• Internet works (double NAT).

Difference
In Bridge Mode the modem is supposed to pass DHCP transparently to Vodafone's CMTS, which should then issue a public lease bound to whatever client MAC asks. That works for the laptop but does not work for OPNsense's MAC. In Router Mode the modem answers DHCP itself and OPNsense gets a private lease — so the L2 path from OPNsense to the modem is fine; only the upstream provisioning step fails when bridging.

What's been tried

• Confirmed tagging is correct end-to-end (tcpdump shows tagged frames leaving OPNsense)
• DHCP Option 60 / Class ID set (dhcp-class-identifier "vodafone")
  
• WAN MAC changed from auto-generated locally-administered (7e:3e:12:74:01:f3) to globally-unique OUI MAC (00:1B:21:AA:BB:CC) — no change
  
• Modem power-cycled (≥2 min) after each MAC change
• Stale dhclient lease file removed
• Bridge Mode confirmed enabled in Vodafone portal

Question
What else, on the OPNsense side, can prevent Vodafone Kabel from issuing a public DHCP lease in Bridge Mode when DHCP requests are visibly leaving the firewall with valid tagging and a globally-unique MAC, while a laptop on the same modem port works — and the same setup worked without issue until 4 May 2026?

Are you using DHCPv4 advanced mode on that WAN?

There are unfortunate bugs in well unchartered territory since the security fix in 26.1.8 regarding what constitutes good and bad input in these fields lacking validation...


Cheers,
Franco

I tried DHCP4 basic and DHCP4 advanced with Send Options > dhcp-class-identifier "vodafone";
Did not seam to make a difference.

Thanks
Sergej

Ok so that's not it. Timing also doesn't match the 26.1.8 release.

One theory is that Vodafone changed something about their approach and is now ignoring the request. The crafty French people having to deal with Orange have done packet captures on the ISP devices in order to mock all their weird request/send options.


Cheers,
Franco