- I know OPNSense removed this from the UI.
- I know it was announced.
- I know it is still supported if you export config, edit config, re-import config.
- I do not really understand why it was removed?
- OPNSense is missing on a very important use case: Transparent Shaper.
- A Transparent Shaper is possible ONLY using Interfaces: Virtual IPs: Settings > Mode=Other.
More details why:
- Queuing is never efficient; only pipes are.
- Queuing is never efficient, from any vendor, software or hardware, or both (appliance); only pipes are.
- A shaper is best when transparent.
- A Shaper is best when standalone.
- Any additional service is pure noise.
This is more of a feature request: Please bring back Virtual IP Mode = Other to the UI. Adding "Other" interfaces does not mean I have to restart the shaper.
> community/25.1/25.1.3:o interfaces: remove defunct "other" VIP type
To our knowledge it wasn't even creating a VIP, just being selectable in some legacy pages as a single pseudo-alias and we simply did not want to bring this cruft into MVC to ease future maintenance burden.
Cheers,
Franco
Quote from: franco on August 17, 2026, 08:05:44 AM> community/25.1/25.1.3:o interfaces: remove defunct "other" VIP type
To our knowledge it wasn't even creating a VIP, just being selectable in some legacy pages as a single pseudo-alias and we simply did not want to bring this cruft into MVC to ease future maintenance burden.
Cheers,
Franco
The problem is: You cannot use OPNSense like a ROUTER-THAT-DOES-NOT-NAT-AND-STILL-HAVE-FIREWALL *except* with this trick.
- I do not want NAT.
- I do not want anything *except* a SHAPER THAT ROUTES and that HAS A FIREWALL.
- Traffic insights are a bonus!
Do you see any way to achieve that other than with VIP=Other?
Config snips attached.
Quote from: MK4L on August 17, 2026, 10:52:12 AMThe problem is: You cannot use OPNSense like a ROUTER-THAT-DOES-NOT-NAT-AND-STILL-HAVE-FIREWALL *except* with this trick.
I'm probably missing something, but if you don't want NAT, don't configure NAT?
You may have to disable source NAT, which is "Automatic" by default:
Firewall -> NAT -> Source NAT, set Mode to "Disable ..."
> Do you see any way to achieve that other than with VIP=Other?
I just don't understand the problem to be honest.
What's the use of a VIP that doesn't create a VIP in the grand scheme of things? How does it flaw the firewall in your view?
Cheers,
Franco
Quote from: dseven on August 17, 2026, 11:19:41 AMQuote from: MK4L on August 17, 2026, 10:52:12 AMThe problem is: You cannot use OPNSense like a ROUTER-THAT-DOES-NOT-NAT-AND-STILL-HAVE-FIREWALL *except* with this trick.
I'm probably missing something, but if you don't want NAT, don't configure NAT?
You may have to disable source NAT, which is "Automatic" by default:
Firewall -> NAT -> Source NAT, set Mode to "Disable ..."
Already disabled.
Quote from: franco on August 17, 2026, 11:36:30 AM> Do you see any way to achieve that other than with VIP=Other?
I just don't understand the problem to be honest.
What's the use of a VIP that doesn't create a VIP in the grand scheme of things? How does it flaw the firewall in your view?
Cheers,
Franco
- When I first used OPNSense, like 10 years ago, I tried static routing.
- With all NAT disabled, routing just *did not function in any way possible*.
- After too many trials, I said to myself: to the dump with it, make it transparent; bump in the wire.
- And it just worked; only with VIP=Other
This is my setup; I wanted to place OPNSense between 2 routers to do what it is supposed to do: SHAPE TRAFFIC.
VIP=Other is the only way it worked for me.
Sorry, I'm lost.
Cheers,
Franco
Setup in attached image. How do you suggest to do it without VIP=Other?
BTW, I only need the firewall to protect the OPNSense shaper; I do not give a blink what passes through. If you took a look at the config snips you will know that I already combined LAN+WAN into a single BRIDGE.
Quote from: MK4L on August 17, 2026, 11:46:29 AMWhen I first used OPNSense, like 10 years ago, I tried static routing.
- With all NAT disabled, routing just *did not function in any way possible*.
I don't know what issues may have existed 10 years ago, but this is not normal. Can you demonstrate OPNsense failing to function as a non-NAT router today?
Quote from: dseven on August 17, 2026, 12:45:36 PMQuote from: MK4L on August 17, 2026, 11:46:29 AMWhen I first used OPNSense, like 10 years ago, I tried static routing.
- With all NAT disabled, routing just *did not function in any way possible*.
I don't know what issues may have existed 10 years ago, but this is not normal. Can you demonstrate OPNsense failing to function as a non-NAT router today?
i will see if I can create a test VM for that, and get back to you.
A transparent shaper ?
Traffic shaping is by nature "transparent". All traffic passes the txqueue and you "simply" apply some fancy algorithms as managers of the txqueue.
Sounds strange your setup.
Is it a bridge or a routed device ? It is a bridge.
You use two different Interfaces? Lan and Wan are bridged.
Pipes and Queues are implemented in OPNsense to bind it on interfaces.
Every simple datacenter router or switch is capable to control the traffic flow. Why not implement it directly on the two routers ?
If you make a setup out of scope, why not use BSD native instead of OPNsense?
This will be the best for you and you have "no noisy disturbing services" as you wrote before.
From the picture you shared,
This looks like a transparent bridge e.g a transparent FW.
Is your point about, you are worried that you can not without that feature create a transparent bridge?
Regards,
S.
When I updates this doc I also took the note from the old page that the traffic shaper is not supported for transparent bridges:
https://docs.opnsense.org/manual/how-tos/transparent_bridge.html
Maybe something is missing? Did it ever work and the assumption is wrong?
Quote from: MK4L on August 17, 2026, 11:46:29 AMThis is my setup; I wanted to place OPNSense between 2 routers to do what it is supposed to do: SHAPE TRAFFIC.
Would it be better to say you have a transparent firewall with traffic shaping?
What purpose do the VIP's serve in your configuration?
The truth is that he only want a "layer 2 only / traffic shaping box".
Quote from: notspam on August 17, 2026, 03:16:58 PMThe truth is that he only want a "layer 2 only / traffic shaping box".
Yes, I understand that. The configuration has VIP's assigned to LAN A1, LAN A2, WAN A1 & WAN A2, the purpose of which is unclear.
Quote from: notspam on August 17, 2026, 03:16:58 PMThe truth is that he only want a "layer 2 only / traffic shaping box".
In my interpretation; they want a traffic shaping box, but they were unable to get (layer 3) routing to work they way that they expected it to, so they cobbled something together with a transparent bridge instead...
Quote from: dseven on August 17, 2026, 04:00:52 PMQuote from: notspam on August 17, 2026, 03:16:58 PMThe truth is that he only want a "layer 2 only / traffic shaping box".
In my interpretation; they want a traffic shaping box, but they were unable to get (layer 3) routing to work they way that they expected it to, so they cobbled something together with a transparent bridge instead...
That was exactly the case, 10 years ago!
For the question about what the Other mode VIPs are doing: they allow traffic to be routed *without any static routes*. The system does not even generate dynamic routes for the Other mode VIPs, but routing works exactly like I expect it to.
Not sure what I did back then, but I have just completed the testing *now* and it worked!
No VIPs, only static routing and 2 manual Gateways.
Thank you all so much for your interest to help.
Quote from: MK4L on August 17, 2026, 04:59:59 PMOther mode VIPs are doing: they allow traffic to be routed *without any static routes*.
I wonder if the routing issue back then was to do with ARP.
Glad it's all working for you!
Quote from: dseven on August 17, 2026, 04:00:52 PMQuote from: notspam on August 17, 2026, 03:16:58 PMThe truth is that he only want a "layer 2 only / traffic shaping box".
In my interpretation; they want a traffic shaping box, but they were unable to get (layer 3) routing to work they way that they expected it to, so they cobbled something together with a transparent bridge instead...
I am back to square 1. I recalled all the pain of the past.
I know why I chose to make it transparent!
When you start assigning IP addresses to WAN/LAN interfaces in the first place, 2 ugly things happen:
- UI navigation becomes very much slower and lagging.
- Routing decisions must be taken *on* OPNSense. Routing becomes horribly unreliable.
Like, I only rebooted, and I lost access to the console from OPT1, which I setup for admin access.
This is my test setup...
Interfaces...
LAN Interface: 192.168.10.2/24
WAN Interface: 192.168.11.2/24
OPT1: DHCP IP 172.16.100.6/24, GW 172.16.100.1
Bridge: I should have removed that from prod setup, but it should not really matter, WAN+LAN combined in Bridge0.
Firewall...
- Admin access is allowed only from OPT1 for admin IP 172.16.100.100/24
- IPv4 is allowed IN/OUT using a floating rule
- IPv6 is all dropped
NAT: Disabled IN/OUT. Completely disabled.
Gateways...
LAN-G: 192.168.10.1/24 on LAN (priority 255, connected to completely *open* router Forward/Input)
WAN-G: 192.168.11.1/24 on WAN (priority 255, connected to completely *open* router Forward/Input)
Dynamic OPT1 GW 172.16.100.1/24 on OPT1 (priority 254)
Routing...
Route 1: 10.10.10.0/24 next-hop LAN-G
Route 2: 10.10.11.0/24 next-hop WAN-G
Test...
- Ping from 10.10.10.2 -> 10.10.11.2 (success)
- Ping from 10.10.11.2 -> 10.10.10.2 (success)
- Shaper rules test on file copy (success)
After reboot setup was *still* working but console UI was completely blocked on OPT1
I must have hit a very similar scenario where I realized that OPNSense, if left to its own devices, does horrible routing/blocking decisions on its own, and if not, at least UI navigation becomes very much slower and lagging.
What I have been able to achieve using VIP=Other, for almost 10 years:
- Never get UI console blocked at OPT1.
- Completely secure access to UI console.
- Decision-less, *constant*, and *reliable* layer-3 routing.
- UI navigation is super fast and super reliable.
How I do it (example)...
LAN interface *no* IP assigned, whatsoever
WAN interface *no* IP assigned, whatsoever
Bridge0 combine LAN+WAN
Internal router with IP 192.168.10.1/30
Edge router with IP 192.168.10.2/30
VIP(Other) 192.168.10.1/32 on LAN interface
VIP(Other) 192.168.10.2/32 on WAN interface
Firewall floating rule allow IPv4 from all-to-all in both directions
...and it just works. No surprises. No lag. No blocking. Super reliable.
You cannot bridge interfaces with IP addresses assigned. In a bridged scenario the IP address must go on the bridge interface. A bridge member (LAN and WAN in your case) must not have an IP address. This is documented for standard FreeBSD and consequently transfers to OPNsense.
Also why are you setting a gateway on your management interface? Are there networks behind that? And should OPNsense route its own Internet access through the management interface instead of WAN?
Quote from: Patrick M. Hausen on August 17, 2026, 07:24:24 PMYou cannot bridge interfaces with IP addresses assigned.
I never used a native BSD setup. Did not know. Nonetheless, my first ever test did not involve bridging; I only used it to make it transparent when I gave up.
And I think it should not affect OPT1, which is not a member?
Quote from: Patrick M. Hausen on August 17, 2026, 07:24:24 PMAlso why are you setting a gateway on your management interface?
This is the dynamic gateway created with DHCP client on OPT1. It naturally sits within the admin subnet.
Yes, I prefer to have OPNSense get its own system traffic through the admin subnet.
I would never use DHCP except on WAN if that's what the ISP delivers.
Yes, OPT will not be affected by your bridge configuration.
All you need should be perfectly doable with routing, though. You can switch off NAT globally. You need a default GW on WAN and none on OPT. You need a static route on your upstream gateway for the LAN network. Done.
Two statements:
1) Bridge:
Yes, like Patrick told you, a network bridge is a layer 2 only and fully transparent device.
Often told "bump in the wire".
Not one with ip addresses on interfaces.
There is only the bridge interface.
And normally a bridge is not a DHCP server or client.
And last thing: A bridge itself is not a routing device. Only the management interface is routed.
2) Management Interface:
Ok, a management interface can have individual routes f.e. to a dedicated out of band management. In the best case as an own routing instance (like virtual router forwarding vrf implementation).
In other words:
Decide if you bridge or route.
What you build is far away from network standards and the reason for the trouble.
Quote from: Patrick M. Hausen on August 17, 2026, 08:03:20 PMI would never use DHCP except on WAN if that's what the ISP delivers.
Is that consideration specific to OPNSense? Can I flexibly use DHCP on OPT in a native BSD setup?
Quote from: Patrick M. Hausen on August 17, 2026, 08:03:20 PMAll you need should be perfectly doable with routing, though. You can switch off NAT globally. You need a default GW on WAN and none on OPT. You need a static route on your upstream gateway for the LAN network. Done.
- I always and consistently disable NAT completely.
- "default GW on WAN and none on OPT": This means I have to reach UI either from LAN, or being directly connected to OPT1?
You can add a manual static route if your management PC is connected to OPT via some other router. But if you configure OPT via DHCP and the DHCP server offers a default gateway, OPNsense will use it. And since there is no VRF, only a single routing table, that would explain why you had so much trouble. You need an upstream gateway to WAN to reach the Internet. With two upstream gateways, one on WAN, one on OPT, all sorts of weird stuff happens.
As for the "no DHCP" - this is not a BSD nor an OPNsense requirement. Just what I consider best practice. Infrastructure is configured statically.
Quote from: Patrick M. Hausen on August 17, 2026, 08:32:02 PMno VRF
That explains all! I often use overlapping destination subnets in routes to multiple gateways, for all sorts of things, not specifically in OPNSense.
Would this also mean that the transparent setup I'm using could collapse with any future upgrade?
I would rather still keep it transparent, even with this information in hand.
You can use a transparently bridged setup - no idea about the shaping, though. But remove the IP addresses from bridge member interfaces. That configuration breaks multicast and that might result in all sorts of mysterious issues.
I'd rather route whenever I can instead of bridging.
The official documentation for a transparent filtering bridge is here: https://docs.opnsense.org/manual/how-tos/transparent_bridge.html
Kind regards,
Patrick
Quote from: Patrick M. Hausen on August 17, 2026, 09:06:49 PMBut remove the IP addresses from bridge member interfaces
Looks like everyone is fixated on accusing me of doing that :D :D I just never do; this was the test setup I made *today* to see if non-transparent is going to work! And the bridge was a leftover from my prod setup!
Thank you for your dedicated help (Y)
Quote from: Patrick M. Hausen on August 17, 2026, 09:06:49 PMThe official documentation for a transparent filtering bridge is here: https://docs.opnsense.org/manual/how-tos/transparent_bridge.html
Oh yes :D Tis I, once again!
After staring at that page for so long I discovered this:
- This page is a Deja-Vu!
- I followed these steps to the character and ended up with toast routing.
- The steps, now, are outdated and do not represent current UI design/pages.
- Specifically, and since 2017 when I first read it, the system tunable instructions actually block routing (because there is no such thing as a Bridge interface to use in Firewall/Rules)
..which makes my setup unique and superior ;P
And, yes: Please bring back VIP Mode=Other to the UI.
Quote from: MK4L on August 17, 2026, 11:12:45 PMbecause there is no such thing as a Bridge interface to use in Firewall/Rules
Verify the bridge interface is enabled
(https://forum.opnsense.org/index.php?action=dlattach;attach=57598;image)
I have set up a transparent firewall using these instructions and it is working for me.
Here's my list of interface assignments.
(https://forum.opnsense.org/index.php?action=dlattach;attach=57600;image)
Quote from: MK4L on August 17, 2026, 11:15:05 PMAnd, yes: Please bring back VIP Mode=Other to the UI.
Maybe I missed it, but I don't believe you have yet explained the purpose of this dummy/fake VIP. Maybe if you could explain, architecturally, what you're trying to do, and how this fake VIP fits into that, another solution can be found.
I still believe that a routed solution is the proper way, though. There's no reason (that I can see) for it not to work, if you stop contorting it with things like multiple default routes.
Quote from: lmoore on August 18, 2026, 09:21:18 AMQuote from: MK4L on August 17, 2026, 11:12:45 PMbecause there is no such thing as a Bridge interface to use in Firewall/Rules
Verify the bridge interface is enabled
(https://forum.opnsense.org/index.php?action=dlattach;attach=57598;image)
I have set up a transparent firewall using these instructions and it is working for me.
This setting vanished somewhere between upgrades...
I'm on latest OPNsense 26.7.2_2-amd64 FreeBSD 15.1-RELEASE-p2 OpenSSL 3.5.7
Quote from: lmoore on August 18, 2026, 09:41:11 AMHere's my list of interface assignments.
(https://forum.opnsense.org/index.php?action=dlattach;attach=57600;image)
This listing also vanished.
Bridge interfaces are now either created, or not.
I'm on latest OPNsense 26.7.2_2-amd64 FreeBSD 15.1-RELEASE-p2 OpenSSL 3.5.7
Quote from: dseven on August 18, 2026, 10:09:13 AMyou have yet explained the purpose of this dummy/fake VIP
I wish I could, form a sound BSD perspective.
But, like I said:
- Attached is my prod setup full list of
System: Routes: Status- You see, I only have a route to the admin interface (OPT1) where I connect and where the system gets it own updates (and resolves DNS in the way).
- Not a single other route is there.
- From your description, you should be surprised to know that I have 15 pairs of Pseudo Other-mode interfaces, total of 30, plus 1 for the larger LAN IP subnet.
- From your description, you should be surprised to know that, without these, no routing is done.
- The Other-mode IPs are created in *pairs* that are *conflicting*-and-*matching* the actual IPs on both routers. I think this would give you an idea how it works, which I cannot explain in informed literature!
- What I was helplessly trying to do with that is *enforce* OPNSense to somehow route traffic where I want it to go, without assigning any IPs, AND, without causing any ARP disturbance. When I did that in 2017, it was a helpless attempt *based on the docs description of Mode=Other*
Please note that I still have the system tunables from the docs page at default values. When I modify them, routing commits suicide.
routes.png
Quote from: MK4L on August 18, 2026, 12:23:38 PMQuote from: dseven on August 18, 2026, 10:09:13 AMyou have yet explained the purpose of this dummy/fake VIP
I wish I could, form a sound BSD perspective.
But, like I said:
- Attached is my prod setup full list of System: Routes: Status
- You see, I only have a route to the admin interface (OPT1) where I connect and where the system gets it own updates (and resolves DNS in the way).
- Not a single other route is there.
- From your description, you should be surprised to know that I have 15 pairs of Pseudo Other-mode interfaces, total of 30, plus 1 for the larger LAN IP subnet.
- From your description, you should be surprised to know that, without these, no routing is done.
- The Other-mode IPs are created in *pairs* that are *conflicting*-and-*matching* the actual IPs on both routers. I think this would give you an idea how it works, which I cannot explain in informed literature!
- What I was helplessly trying to do with that is *enforce* OPNSense to somehow route traffic where I want it to go, without assigning any IPs, AND, without causing any ARP disturbance. When I did that in 2017, it was a helpless attempt *based on the docs description of Mode=Other*
Please note that I still have the system tunables from the docs page at default values. When I modify them, routing commits suicide.
routes.png
And, guess what? It just worked! For almost 10 years.
Maybe it's time to move on to a supported setup and not an accidental side effect.
If it cannot be explained properly and everybody is confused occam's razor makes it look like this:
https://xkcd.com/1172/
Quote from: MK4L on August 18, 2026, 12:23:38 PM- The Other-mode IPs are created in *pairs* that are *conflicting*-and-*matching* the actual IPs on both routers
This suggests you are experiencing ARP issues over the bridge where the router on the other side of the bridge does not receive the ARP request and/or vice-versa.
A transparent firewall does not route traffic, it is simply a bridge inserted in the path of a network connection going from point A to point B.
On my test machine I have a default route on the LAN interface going to my production OPNsense router. Based upon your drawing earlier, this is the
Internal Router.
Quote from: MK4L on August 18, 2026, 12:23:38 PMPlease note that I still have the system tunables from the docs page at default values. When I modify them, routing commits suicide.
If you didn't reconfigure your firewall rule/s to use the
Bridge interface, then this is expected when you change the Tunables to filter on the bridge.
(https://forum.opnsense.org/index.php?action=dlattach;attach=57622;image)
Quote from: lmoore on August 18, 2026, 02:09:20 PMThis suggests you are experiencing ARP issues over the bridge where the router on the other side of the bridge does not receive the ARP request and/or vice-versa.
A transparent bridge operates by forwarding Ethernet frames based on MAC addresses. It doesn't look at IP addresses or make routing decisions.
Since I'm not interested in messing up the routing AS IT IS in my setup, I will never set a default route to the WAN.
I have multiple destination networks on both sides, and I'm not giving that up. Ever.
Quote from: Monviech (Cedrik) on August 18, 2026, 01:32:14 PMIf 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
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!
However, doing so means you aren't utilizing 90% of OPNsense's capabilities.
OPNsense is a stateful L3/L4 router with firewalling features.
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.
Quote from: franco on August 17, 2026, 08:05:44 AM> community/25.1/25.1.3:o interfaces: remove defunct "other" VIP type
To our knowledge it wasn't even creating a VIP, just being selectable in some legacy pages as a single pseudo-alias and we simply did not want to bring this cruft into MVC to ease future maintenance burden.
Cheers,
Franco
"mode=other" was a hack in the source code. The OPNsense team removed the mode because it was architecturally unsound and caused confusion in standard setups—even though it had worked for 10 years.
I hope you find the best solution for your needs, but it is possible that OPNsense—in its current and future versions—is no longer the right fit.
Quote from: RES217AIII on August 18, 2026, 05:26:01 PMIf 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 (https://developers.cloudflare.com/dns/cname-flattening/)!
Quote from: RES217AIII on August 18, 2026, 05:26:01 PMHowever, 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
Quote from: RES217AIII on August 18, 2026, 05:26:01 PMI 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.
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.
Quote from: mimugmail on August 18, 2026, 10:22:07 PMSorry 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...
QuoteWhy "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:
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 (https://docs.netgate.com/pfsense/en/latest/firewall/virtual-ip-addresses.html). I just hate the UI of pfSense.
To be honest:
> Other
>
> Other type VIPs define additional IP addresses for use when
> ARP replies for the IP address are not required. The only
> function of adding an Other type VIP is making that address
> available in the NAT configuration drop-down selectors. This
> is convenient when the firewall has a public IP block routed
> to its WAN IP address, IP Alias, or a CARP VIP.
Just use a plain IP or alias in NAT, done? There is absolutely no need for this type of VIP.
Yes, this would also be of interest, to see what happens when type is Alias instead of Other
Quote from: franco on August 19, 2026, 07:32:44 AMThere 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.
FWIW, I've run up OPNsense 25.1 and configured VIP's using "Other" and applied them to the interfaces used in the bridge.
I cannot find the addresses referenced anywhere in OPNsense's running configurations.
All I'll add is that the messages appearing in System -> Log Files -> General of type Notice advising of impending changes, @MK4L may need to find another solution.
2026-08-19T10:09:02 Notice kernel <6>[120603] re0: WARNING: Assigning an IP address to an interface which is also a bridge member is deprecated and will be unsupported in a future release.
We should call time on this discussion.
Quote from: MK4L on August 19, 2026, 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! (https://share.gemini.google/ylRVVxKFKbgk)
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 (https://forum.opnsense.org/index.php?action=profile;u=26898) (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 (https://man.freebsd.org/cgi/man.cgi?query=if_bridge&sektion=4)
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 (https://forum.opnsense.org/index.php?action=profile;u=26898): Special thanks for the time you took to help and your remarks.
Why do you need proxy ARP? Why do you need to assign a VIP to the bridge at all?
The upstream router is on the WAN side of the bridge, the clients are on the LAN side of the bridge. The clients just use the upstream router as if the bridge wasn't there at all. That's what "transparent" means. That's how it has worked in OPNsense since the feature was introduced.
Quote from: Patrick M. Hausen on August 19, 2026, 06:01:18 PMWhy 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.
Why do you need a bridge at all if you are routing in the end?
This is all going in circles.
Quote from: Monviech (Cedrik) on August 19, 2026, 06:20:44 PMWhy 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"!
Quote from: Monviech (Cedrik) on August 19, 2026, 06:20:44 PMWhy 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.
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!
log.png
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.
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.
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. (http://removed)
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
Gemini is stating BS. You cannot deprive a bridge device from operating on layer 3. It never will, because a bridge is layer 2.
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 (https://forum.opnsense.org/index.php?action=profile;u=26898) (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 (https://man.freebsd.org/cgi/man.cgi?query=if_bridge&sektion=4)
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 (https://forum.opnsense.org/index.php?action=profile;u=26898): Special thanks for the time you took to help and your remarks.
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)
Quote from: Monviech (Cedrik) on August 20, 2026, 07:37:52 AMa bit wonky
Yes, cluttered, messy, and split over 2 pages!
pf.shaping.png
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
@MK4L just an outside observer on this; seems like the distilled version would be a great add to "Tutorials and FAQ"
Quote from: Monviech (Cedrik) on August 20, 2026, 07:37:52 AMIt means that for IPFW dummynet shaping it needs an additional tunable.
A little more is required.
I suspect I know the reason why fudging of ARP was initially used in @MK4L's environment.
I'm including the steps required to set up a Transparent Traffic Shaper based upon @MK4L's description of their environment.
Overview:
Guide to build a Transparent Traffic Shaper using OPNsense.
The configuration steps described here is based upon @MK4L's description of their environment.
Some points for the keen observer;
- The bridge interface has not been assigned in Interfaces -> Assignments and is not required.
- This configuration can work without any PF rules applied to the WAN & LAN interfaces by adjusting one setting.
These instructions were performed on bare-metal hardware which included the following NIC's and their assignments:
- em0 -> [OPT1]
- igb0 -> [LAN]
- igb1 -> [WAN]
The version of OPNsense used when creating this configuration: OPNsense 26.7.2_2 (amd64)
With exception to the interface names, follow the steps verbatim and in order as listed.
Requirements:
- Computer meets OPNsense system requirements
- Computer has a minumum of 3 x NIC's
Assumptions:
- The reader is familiar with configuring OPNsense
- The computer being used for this installation is a test machine
Disclaimer:
There may be errors or omissions in the steps below.
Priot to perfoming the following instructions, prepare your system using one of these two options.
1) Perform a fresh installation and at the end shut down and power off the computer.
2) Reset OPNsense settings to factory defaults.
First time start-up and initial configuration using LAN interface:
- Remove all network cables from the computer
- Power on computer
- Wait for the computer to display the login prompt on the console.
- Plug a network cable into the LAN port
- Login on the console as root
- Select option 2 - Set interface IP address
- Enter 1 - LAN listed under 'Available interfaces'
- Enter 'y' to assign an IPv4 address using DHCP
- Enter 'n' to disable IPv6 WAN tracking
- Enter 'N' to not use DHCP6
- Press Enter to skip entering an IPv6 address
- Press Enter to skip GUI protocol
- Press Enter to skip GUI certificate
- Press Enter to skip GUI access defaults
- Log on to the WebGUI
- Interfaces -> Neighbors -> Automatic Discovery
- Enabled: untick
- Click 'Apply'
- Interfaces -> Assignments
- Add
- Select device from drop-down list: em0
- Click 'Save'
- Click 'Apply'
- Refresh browser page (F5)
- Interfaces -> [OPT1]
- Enable: tick to enable the interface
- IPv4 Configuration Type: DHCP
- IPV6 Configuration Type: <optional>
- Click 'Save'
- Click 'Apply changes'
- Firewall -> Rules
- Edit Interface rule Default allow LAN to any rule
- Enable 'adavanced mode'
- Description: <optional>
- Interface: Include 'OPT1'
- Source: Include 'OPT1 network'
- Disable reply-to: tick
- Click 'Save'
- Edit Interface rule Default allow LAN IPv6 to any rule
- Enable 'adavanced mode'
- Description: <optional>
- Interface: Include 'OPT1'
- Source: Include 'OPT1 network'
- Disable reply-to: tick
- Click 'Save'
- Click 'Apply'
- Lobby -> Logout
- Close the browser
- Unplug the network cable from the LAN port
- Plug the network cable in to the OPT1 port
- On the console select 0 to logout
- Log back in on the console as root
- Open a new browser to the address listed on the console for OPT1
- Log on to the WebGUI
Complete System Configuration Wizard
- Welcome tab
- Click 'Next'
- General Information tab
- Hostname: TTS-IPFW
- Timezone: <optional>
- DNS servers: Enter address of internal DNS server
- Click 'Next'
- Network [WAN] tab
- Disable LAN: tick
- Block RFC1918 Private Networks: untick
- Block bogon networks: untick
- Click 'Next'
- Network [LAN] tab
- Disable LAN: tick
- Configure IP address: clear text in field 'dhcp/'
- Configure DHCP server: untick
- Click 'Next'
- Deployment type tab
- Optimize for Multiwan: untick
- Automatic DHCP/DNS registration: untick
- Click 'Next'
- Set initial password tab
If not already changed from its default, change the Root Password.
- Click 'Next'
- Finish tab
- Click 'Apply'
Configure LAN & WAN interfaces
- Interfaces -> LAN
- Enable: tick
- IPv4 Configuration Type: None
- IPV6 Configuration Type: None
- Click 'Save'
- Click 'Apply changes'
- Interfaces -> WAN
- Enable: tick
- Block private networks: untick
- Block bogon networks: untick
- IPv4 Configuration Type: None
- IPV6 Configuration Type: None
- Click 'Save'
- Click 'Apply changes'
Update firewall settings
- Firewall -> NAT -> Source NAT
- Mode: Disable Source NAT rule generation
- Click 'Apply'
- Firewall -> Rules
- Edit Interface rule Default allow LAN to any rule
- Description: <optional>
- Interface: Deselect 'LAN'
- Source: Deselect 'LAN network'
- Click 'Save'
- Edit Interface rule Default allow LAN IPv6 to any rule
- Description: <optional>
- Interface: Deselect 'LAN'
- Source: Deselect 'LAN network'
- Click 'Save'
- Click 'Apply'
Enable sysctl options required for this configuration.
- System -> Settings -> Tunables
- Add
- Tuneable: net.link.bridge.ipfw
- Value: 1
- Description: Layer2 filter with IPFW
- Click 'Save'
- System -> Settings -> Tunables
- Add
- Tuneable: net.link.ether.ipfw
- Value: 1
- Description: Pass ether pkts through firewall
- Click 'Save'
- Services -> Unbound -> Query Forwarding
- Use System Nameservers: tick
- Click 'Apply'
Add a Bridge device with description 'Traffic Shaper' and include the EGRESS and INGRESS interfaces as members and click on Save
- Interfaces -> Devices -> Bridge
- Add
- Member interfaces: WAN, LAN
- Description: Traffic Shaper
- Click 'Save'
- Click 'Apply'
Create firewall rule for the bridge.
- Firewall -> Rules
- Add
- Enable 'advanced mode'
- Description: Traffic Shaper
- Interface: LAN, WAN
- Direction: Both
- State type: no state
- Click Save
- Click Apply
Create shaping pipes
- Firewall -> Shaper -> Pipes
- Create Download pipe
- Add
- Bandwidth: 4
- Bandwidth Metric: Mbit/s
- Description: Pipe_4Mbps
- Click 'Save'
- Create Upload pipe
- Add
- Bandwidth: 2
- Bandwidth Metric: Mbit/s
- Description: Pipe_2MBps
- Click 'Save'
- Click 'Apply'
Create shaping rules
- Firewall -> Shaper -> Rules
- Create Download rule for subnet 10.200.128.0/24
- Add
- Enable 'advanced mode'
- Enabled: ticked
- Interface: WAN
- Interface 2: LAN
- Source: any
- Destination: 10.200.128.0/24
- Direction: In
- Target: Pipe_4MBps
- Description: Shape traffic for subnet 10.200.128.0/24
- Click 'Save'
- Create Upload rule for subnet 10.200.128.0/24
- Add
- Enable 'advanced mode'
- Enabled: ticked
- Interface: WAN
- Interface 2: LAN
- Source: 10.200.128.0/24
- Destination: any
- Direction: Out
- Target: Pipe_4MBps
- Description: Shape traffic from subnet 10.200.128.0/24
- Click 'Save'
- Click 'Apply'
Check for updates
- Check for OPNSense updates and install if available
Final reboot
- Power -> Reboot
- Click 'Yes'
Plug appropriate network cables in to the LAN & WAN ports and commence testing. Enjoy!
The problem is a bit the thread starter itself.
Without knowledge of basic network design rules all effort is in reality a waste of time.
It is important to seriously consider the issues and not just start building without a plan.
I have rarely read so many false things.