Interfaces: Virtual IPs: Settings > Mode=Other

[RES217AIII]

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.

> 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.

[MK4L]

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.

[mimugmail]

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.

[MK4L]

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.

[franco]

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.

[mimugmail]

Yes, this would also be of interest, to see what happens when type is Alias instead of Other

[MK4L]

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.

[lmoore]

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.

Code Select Expand

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.