Messages

a bit wonky

Yes, cluttered, messy, and split over 2 pages!

You cannot view this attachment.


Off-topic: If you like DeepHouse, this is a little AI thank you :D You will be surprised.

https://www.youtube.com/watch?v=sPk2viKd0cE
https://www.youtube.com/watch?v=6K7PQviILDg

[This is the correct setup for OPNSense in-line TRANSPARENT BRIDGE shaper:]

I had to do it, so i just did. Nothing is like debugging on prod! ;D

This is 100% tested, using all combinations, surviving too many reboots, so there is 0% chance it had accidental results.
This is the correct setup for OPNSense in-line TRANSPARENT BRIDGE shaper: (Corrections made with help from @Cedrik (Y) )

- LAN interface IP assignments are NONE. (Interfaces: [LAN])
- WAN interface IP assignments are NONE. (Interfaces: [WAN])
- Create a Bridge Device combining LAN + WAN. (Interfaces: Devices: Bridge)
- You can assign an interface to the Bridge Device (Interfaces: Assignments), but it does not matter.
- You can enable the Bridge Device, but it will be UP in any scenario on its own.
- Set Firewall rules to allow all-to-all traffic in both directions for LAN + WAN. (Firewall: Rules)
- DO NOT use Virtual IPs of any mode, whatsoever. (Interfaces: Virtual IPs: Settings)
- Add tunable > net.link.bridge.ipfw > set to 1 > Apply. (System: Settings: Tunables)
- Create your Traffic Shaper Pipes and Rules. (Firewall: Shaper)


What you DO NOT need:
- Allowing 2-way all-to-all traffic to pass the bridge device in the firewall. Filtering happens on the LAN & WAN interfaces.
- Adding Virtual IPs of any mode, or even actual IPs to that matter. It breaks current FreeBSD rules if you add them to bridge members.
- Adding static routes in OPNSense. You route in your routers. You do not need to route in OPNSense, forwarding works normally.
- Modify .pfil_ System Tunables. You only need to (System: Settings: Tunables)Add tunable > net.link.bridge.ipfw > set to 1 > Apply:

From FreeBSD ManPages

net.link.bridge.ipfw
        Set to 1 to enable layer2 filtering with ipfirewall(4), set to 0 to
        disable  it.  This  needs  to  be enabled for dummynet(4) support.
        When ipfw is enabled, pfil_bridge and pfil_member will be    disabled
        so that IPFW is not run twice; these can be re-enabled if desired.

@franco: You can kill the cruft!
@everyone: Thank you so much for caring to reply. Pushing is healthy.
@Cedrik: Special thanks for the time you took to help and your remarks.

From Gemini:  I added a bridge device in OPNSense, did not assign it to interface, did not enable it, but it is always up after reboot. Explain.

brief: Not assigning the bridge deprives it the ability to work on layer 3. It will be up in all cases.

Scrap that; AI slop.

I did not say you route.

I totally understand. That is why I need Proxy ARP, because I do not want to put static routes in OPNSense. A bridge won't route for me.

Sorry, I retract that. Very long day. I did not want traffic to use the bridge as is because it skips Shaper rules.
I definitely tested that, with an IP that I did not assign to LAN, and it went out of shaper control.

there does not need to be any IP address on neither WAN nor LAN for that, and definitely no proxy ARP.

I *do not* route in OPNSense. I just don't.

and shaping on the individual interfaces or in the bridge interface

Shaper *does not* work on a bridge. It has no effect whatsoever. I enforce 5 Mbps, the client gets 100.

This is what it looks like!

You cannot view this attachment.

Why do you need a bridge at all if you are routing in the end?

Good point to add the setup message above! I'm not routing in OPNSense. I'm routing in my routers.

[Routing halts completely if I do not add the bridge device "turned off"!]

Why do you need a bridge at all if you are routing in the end?

Please advise me on this; I'm not the expert here!
Routing halts completely if I do not add the bridge device "turned off"!

Why do you need to assign a VIP to the bridge at all

There is no actual bridge. It exists only as a *hardware device*.
If it was enabled and assigned, Shaper will not work on it.
Shaper does not work on it in any given scenario.

[This is the correct setup for OPNSense in-line TRANSPARENT BRIDGE shaper:]

I had to do it, so i just did. Nothing is like debugging on prod! ;D

This is 100% tested, using all combinations, surviving too many reboots, so there is 0% chance it had accidental results.
This is the correct setup for OPNSense in-line TRANSPARENT BRIDGE shaper: (Corrections made with help from @Cedrik (Y) )

- LAN interface IP assignments are NONE. (Interfaces: [LAN])
- WAN interface IP assignments are NONE. (Interfaces: [WAN])
- Create a Bridge Device combining LAN + WAN. (Interfaces: Devices: Bridge)
- You can assign an interface to the Bridge Device (Interfaces: Assignments), but it does not matter.
- You can enable the Bridge Device, but it will be UP in any scenario on its own.
- Set Firewall rules to allow all-to-all traffic in both directions for LAN + WAN. (Firewall: Rules)
- DO NOT use Virtual IPs of any mode, whatsoever. (Interfaces: Virtual IPs: Settings)
- Add tunable > net.link.bridge.ipfw > set to 1 > Apply. (System: Settings: Tunables)
- Create your Traffic Shaper Pipes and Rules. (Firewall: Shaper)


What you DO NOT need:
- Allowing 2-way all-to-all traffic to pass the bridge device in the firewall. Filtering happens on the LAN & WAN interfaces.
- Adding Virtual IPs of any mode, or even actual IPs to that matter. It breaks current FreeBSD rules if you add them to bridge members.
- Adding static routes in OPNSense. You route in your routers. You do not need to route in OPNSense, forwarding works normally.
- Modify .pfil_ System Tunables. You only need to (System: Settings: Tunables)Add tunable > net.link.bridge.ipfw > set to 1 > Apply:

From FreeBSD ManPages

net.link.bridge.ipfw
        Set to 1 to enable layer2 filtering with ipfirewall(4), set to 0 to
        disable  it.  This  needs  to  be enabled for dummynet(4) support.
        When ipfw is enabled, pfil_bridge and pfil_member will be    disabled
        so that IPFW is not run twice; these can be re-enabled if desired.

@franco: You can kill the cruft!
@everyone: Thank you so much for caring to reply. Pushing is healthy.
@Cedrik: Special thanks for the time you took to help and your remarks.

If 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!

There is absolutely no need for this type of VIP

If you could give me direction where this happens inside BSD itself (the side-effect, you say), I will just call it a day.
I can never trust routing/firewalling decisions of OPNSense while using static routes.

[Why "Other" Mode behaves this way in FreeBSD]

Sorry to be offtopic, but what happens in the OS when you add a Virtual IP with type other?? I never had a demand to even think about its reason.

You are actually spot on! I was hoping someone would explain, but I had to dig it myself, and Gemini, not DeepSeek, gave me a hint...

Why "Other" Mode behaves this way in FreeBSD
In FreeBSD, pf rules process packets before layer-2 ARP resolution or layer-3 routing lookup occurs.

Because an "Other" VIP exists strictly as a condition check in pf:

Plaintext
[ Incoming Packet ]
      │
      ▼
[ FreeBSD pf Engine ] ──► "Does destination match the Other VIP?"
      │                                                          │
      YES                                                  NO
      │                                                          │
[ Rewrite Packet Headers ]          [ Normal Routing / ARP ]
(Target host changed;                (Sent to actual physical IP)
real router bypassed)

The system never reaches the stage where it asks FreeBSD "Where is the MAC address for this IP?" for the real router. The pf match happens first, changing the packet's destination header and redirecting it elsewhere.


What you actually see in FreeBSD without NAT
If you run these diagnostic commands on FreeBSD while using an "Other" VIP without NAT:

Code Select Expand

Bash
# 1. Check interface aliases:
ifconfig
# Result: The "Other" VIP will NOT appear anywhere.

# 2. Check kernel routing table:
netstat -rn
# Result: No route or local loopback host route entry exists for that IP.

# 3. Check loaded pf filter rules:
pfctl -sr
# Result: Unless you explicitly wrote a custom firewall Pass/Block rule matching
# that specific IP string, it will not appear anywhere in pf's rule memory.
Why do you see entries in pfctl -ss then?
The state table (pfctl -ss) tracks active packet flows passing through the pf module.

If you see an IP listed in pfctl -ss on a non-NAT system, pf is simply logging that a routed packet passed through OPNSense with that IP address in its original IP header (as either the source or destination) from an upstream or downstream host. pf creates a state entry to allow returning reply traffic, but FreeBSD itself is taking no action on the IP address other than basic packet forwarding.

- I never had a chance to see what pfctl -ss says in my setup if I strip all Other VIPs, and use static routing instead. (maybe because OPNSense tends to block UI access on OPT1 if you follow their recommendations ;P)
- With Other VIPs in place, pfctl -ss shows Packet Filter routing all packets where my routers want them to go. No touching.
- I still have no clue where the entries in pfctl -ss come from! /tmp/rules.debug does not have them.
- I must use this setup because I must never be ROUTING in all 3 "routers" directly connected to each other. Only REAL routers should do routing! (this is the anti-rant, you see!)
- To top it up, routing in BSD is cranky.

P.S: pfSense still uses VIP=Other. I just hate the UI of pfSense.

If I understand correctly, you want to use OPNsense purely as a Layer 2 bridge and disable all services.
You want to avoid unpacking or readdressing IP packets (no NAT) and consulting routing tables in order to minimize latency.
That's a valid idea!

Thank you for understanding. It is is also why I see gold in this setup that would otherwise require much more complex alternatives.
I just wish the team had seen it as well.
I kid you not that it occurred to me more than once to ask them to keep it for a fee!
Where would you find a FREE Traffic Shaper that would not mess up your routes?
The response was like: Get lost. Sad.
Compare that to a setup that breaks standards like Cloudflare's CNAME Flattening!

However, doing so means you aren't utilizing 90% of OPNsense's capabilities.
OPNsense is a stateful L3/L4 router with firewalling features.

Those I implement standalone. I manage heavy traffic over a total of ~ 300 Mbps over multiple links. Shaping is something I cannot function without!
The only time I wanted to test IDS on the same box, I lost both under load :D

I get the feeling that specialized solutions would be far better and offer higher performance for your use case than trying to force OPNsense to do something it wasn't designed for.

Hardware solutions that promise shaping end up *queuing* and not *piping*.
I tried queuing in hardware and software and it never delivers.

On a final note: This forum thread managed to actually poison DeepSeek :D Like it is the main source on the subject.

If it cannot be explained properly and everybody is confused occam's razor makes it look like this:
https://xkcd.com/1172/

Believe me I tried, but your heating children are standing in my way :D :D