Interfaces: Virtual IPs: Settings > Mode=Other

Started by MK4L, August 16, 2026, 06:50:16 PM

Previous topic - Next topic
So, I thought this was a transparent firewall.

It is a Clayton's router - A router you use when you're not using a router.

Meaning of Clayton's: https://slang.com.au/c/claytons/

It seems the bridge is somewhere to park the Proxy ARP addresses to fool the traffic into passing through the traffic shaper.

This is what it looks like!

You cannot view this attachment.

He's bridging LAN and WAN and then transparently filtering as far as I get it. But there does not need to be any IP address on neither WAN nor LAN for that, and definitely no proxy ARP.

If you assign and enable the bridge depends on if you want to place the firewall rules and shaping on the individual interfaces or in the bridge interface. There are tunables for that.

In case of a "software switch", i.e. a LAN bridge, you generally filter on the bridge interface assigning that as LAN.

In case of a transparent filtering bridge you generally filter in the member interfaces as appropriate, if I am not mistaken.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Quote from: Patrick M. Hausen on August 19, 2026, 07:08:06 PMthere 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.


Quote from: Patrick M. Hausen on August 19, 2026, 07:08:06 PMand 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.


I did not say you route. I said if you bridge you do not need IP addresses. Bridging is layer 2. It's completely oblivious of any upper layer protocol like IPv4, IPv6, or (*gasp*) IPX or Appletalk.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

August 19, 2026, 07:23:54 PM #65 Last Edit: August 19, 2026, 07:36:47 PM by MK4L
Quote from: Patrick M. Hausen on August 19, 2026, 07:19:27 PMI 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.

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 ran this whole thread through Chatgpt and it says this (didnt fact check)

-----

FreeBSD actually documents this quite clearly.

A bridge does not need IP addresses to transparently forward traffic, and FreeBSD explicitly supports using a bridge as a traffic shaper with Dummynet. (FreeBSD Dokumentation)

The interesting part for your issue is if_bridge(4): bridged traffic can be filtered on the member interfaces or on the bridge itself, controlled by net.link.bridge.pfil_member and net.link.bridge.pfil_bridge. For Dummynet specifically, FreeBSD also documents net.link.bridge.ipfw as the Layer-2 filtering path and explicitly says it "needs to be enabled for dummynet(4) support." (FreeBSD Manpages)

FreeBSD if_bridge(4)
FreeBSD Handbook — Bridging

So I don't think Proxy ARP or VIPs are the solution here. If bridged packets bypass your shaper rules, the interesting question is which bridge filtering hook the packets and Dummynet rules are traversing. That's exactly what the FreeBSD bridge filtering knobs control.

https://man.freebsd.org/cgi/man.cgi?query=if_bridge&sektion=4

https://docs.freebsd.org/en/books/handbook/advanced-networking/#network-bridging
Hardware:
DEC740

Gemini is stating BS. You cannot deprive a bridge device from operating on layer 3. It never will, because a bridge is layer 2.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Today at 12:35:14 AM #69 Last Edit: Today at 01:45:24 AM by MK4L
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
Quotenet.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.

Today at 07:37:52 AM #70 Last Edit: Today at 07:40:03 AM by Monviech (Cedrik)
Now that sounds more like it.

It means that for IPFW dummynet shaping it needs an additional tunable.

But that also means without that tunable, shaping via PF should also work (which is available in the new Rules, you can attach pipes via PF there so PF sends it to dummynet, IPFW is not needed then. But its still a bit wonky probably)
Hardware:
DEC740

Quote from: Monviech (Cedrik) on Today at 07:37:52 AMa 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