OPNWAF: Optional binding of Virtual Servers to specific Virtual IPs

[Zwiebelhacker]

Hi,

I'm currently using OPNWAF as a reverse proxy/WAF for several publicly accessible web services and was wondering if there is a possibility to bind a Virtual Server to a specific IP address.

Our setup includes a public IPv4 /24 range, and we use multiple addresses from this range as static Virtual IPs on OPNsense. We intentionally assign different publicly accessible services to different public IP addresses.

For example:

Public VIP A:443 → 123.example.com → Backend A
Public VIP B:443 → portal.example.com → Backend B
Public VIP C:443 → mail.example.com → Backend C

I understand that OPNWAF already supports hostname/SNI-based routing, so technically all of these services could share the same IP address.

However, we deliberately use separate public IPs for different services.

There are a few reasons for this:

• Separate IP reputation between services
• Reduced impact if one IP ends up on a blocklist
• Clear separation of publicly exposed services
• Easier troubleshooting and monitoring
• Avoiding an unintended service being reachable through another public IP

What I am looking for is therefore not a replacement for the existing hostname/SNI functionality, but rather an optional additional restriction.

For example:

Virtual Server
Hostname:    portal.example.com
Listen port: 443

[ ] Bind to specific Virtual IP
Virtual IP:  [ Public VIP B ]

With the option disabled, the current behaviour would remain unchanged.

With the option enabled, the Virtual Server would only accept connections on the selected Virtual IP and port.

Ideally, the available IPs could be selected from the Virtual IPs already configured in OPNsense instead of entering an arbitrary IP address manually. This would also make it possible for OPNsense to validate that the selected address actually exists.

Is something like this currently possible with OPNWAF?

If not, would an optional binding of a Virtual Server to an existing Virtual IP be considered a reasonable feature request?

I previously used Sophos UTM 9, where the Virtual Webserver configuration allowed selecting the interface/IP on which the webserver was exposed. With multiple public Virtual IPs, this made it possible to explicitly associate a public IP/port with a virtual webserver.

Something similar in OPNWAF would be really useful, especially for setups with multiple public Virtual IPs.

Thanks!

[Monviech (Cedrik)]

Its sadly not a good idea because the any interface will always assure a service can start even if an IP address is unavailable.

A feature request will not have much of a chance to change this design decision.

Full explanation here:
https://docs.opnsense.org/manual/settingsmenu.html#listen-interfaces

So if you want opnwaf only available on certain ip addresses, use upper ports and DNAT rules. SNI does the rest. Per IP address policy inside the proxy (even if optional) just makes it harder and more fragile for everyone.

[Zwiebelhacker]

Thanks for your explanation.

I have no experience with the OPNsense/OPNWAF implementation itself, so I might be missing some technical details.

From an administrator's point of view, I would expect that ensuring the configured IP is available is part of maintaining the configuration. If I explicitly bind a service to a specific static VIP and that VIP becomes unavailable for some reason, I think it would be reasonable that a service depending on that IP, such as OPNWAF/Apache, might not be able to start correctly.

The current "any interface" behaviour could of course remain the default, with IP binding being an optional setting for administrators who specifically need it.

I understand the reasoning behind the current design now. I do have to say that I find it a little unfortunate, though, as with more than a handful of web servers, the alternative approach with additional ports and DNAT rules would make the overall configuration harder to follow and maintain.

Wouldn't this also be a potential security concern when using multiple public IPs for different services?
For example, different VIPs might have different firewall policies or restrictions — such as GeoIP filtering, access restrictions, or different allowed source networks.

If OPNWAF listens on any interface, couldn't someone simply point a hostname to another VIP and reach the same Virtual Server through a different, less restrictive firewall rule?

That's another reason why I would find optional IP binding useful.

Or am I misunderstanding something here? Is using multiple public IPs for different services with different firewall policies simply not a common use case with OPNWAF?

[Monviech (Cedrik)]

Maybe the misunderstanding comes from the fact that you want to use OPNWAF as a multi-tenant installation, whereas it's current design favors single tenants more.

In your case it might be more practical to put the service in a DMZ (e.g. one DMZ per client/tenant) on a separate server and use the firewall only for packet processing. That would also cleanly separate concerns.

HA proxy might also be an alternative here.

[Zwiebelhacker]

I think the issue also applies to a single organization with multiple services.

For example, I might have a public website that should be accessible worldwide, while an ownCloud instance should only be accessible, for example, from Germany. If they use different public IPs, I can apply different firewall policies to those IPs.

So for me, the main issue isn't really multi-tenancy, but having different security policies for different services.

At the moment, I actually only have two web servers where different policies apply, so I tried the workaround with DNAT rules and separate ports for these. So far, this seems to work quite well. Thanks for that!

[Monviech (Cedrik)]

No problem, the DNAT rule is the currently supported approach. It keeps policy in the firewall and your service will survive any change of ip addresses (also missing ones during boot or dynamic ones in case of ipv6) transparently.