Messages

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!

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?

[Virtual Server]

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!

Thanks for taking the time to look into this and for explaining the expected flow.

I agree that a catch-all HTTPS redirect in the Exchange HTTP template would be the most consistent behavior with the documented global HTTP→HTTPS option.

I'll open a feature request for this. Thanks for clarifying!

https://github.com/opnsense/plugins/issues/5645

Hi,

I'm using OPNsense Business Edition with the OPNWAF plugin as a reverse proxy for an on-premises Exchange Server.
I have enabled the global "Redirect HTTP to HTTPS" option under the OPNWAF general settings.

According to the documentation, this option:
"Enables a permanent redirect (301 Moved Permanently) from HTTP to HTTPS. This will bind the default HTTP port additionally for all virtual hosts."

Therefore, I assumed that a request such as:
http://webmail.example.com/ would be redirected to: https://webmail.example.com/

However, this does not seem to be the case with an Exchange Server virtual host.

The generated Apache configuration contains the following for the HTTP virtual host:

<VirtualHost *:80>
    ServerName webmail.example.com
    Options -FollowSymLinks
    Options -Indexes
    Options -ExecCGI
    LogLevel warn
    ProxyRequests Off

    # Start ExchangeHttps
    Header always set X-Frame-Options SAMEORIGIN
    Header set Server Apache
    RequestHeader unset Expect early
    Header unset X-AspNet-Version
    Header unset X-OWA-Version
    Header unset X-Powered-By

    RewriteEngine On
    RewriteCond %{HTTPS} !=on
    RewriteRule ^/owa(.*) https://webmail.example.com/owa$1 [R,L]
    RewriteRule ^/ecp(.*) https://webmail.example.com/ecp$1 [R,L]
    RewriteRule ^/Microsoft-Server-ActiveSync(.*) https://webmail.example.com/Microsoft-Server-ActiveSync$1 [R,L]

    # End ExchangeHttps
</VirtualHost>

As you can see, there are rewrite rules for:

•   /owa
•   /ecp
•   /Microsoft-Server-ActiveSync

but there is no general rule for /.

When I run:
curl.exe -I http://webmail.example.com/

I get:
HTTP/1.1 403 Forbidden
Server: Apache

Whereas the request is correctly handled when accessing /owa.

The documentation for the Exchange Server location also states:
"Access to path / is filtered per default with a redirect to /owa."

This makes me wonder whether the behavior I'm seeing is intentional.

My questions

1.   Is it expected that the global "Redirect HTTP to HTTPS" setting does not generate a HTTP→HTTPS redirect for the / path of an Exchange virtual host?
2.   Should the Exchange Server template normally generate an additional / → /owa redirect?
3.   If both behaviors are expected, should I see something similar to:

RewriteRule ^/(.*) https://webmail.example.com/$1 [R=301,L]

and/or a rule redirecting / to /owa in the generated configuration?

4.   If this is intentional, what is the recommended way to redirect the root path / to HTTPS (and subsequently /owa) without manually modifying the generated gateway_vhosts.conf? Just

I'm asking because the wording of the global HTTP→HTTPS option led me to expect that all HTTP requests for all virtual hosts, including the root path of an Exchange virtual host, would receive a 301 redirect.

Thanks!

Hello, thank you for the suggestions.

After increasing the regex limits, I was able to identify additional rules that were blocking the attachment upload.

However, I then reached a point where processing these rules caused the CPU usage to spike to 100% continuously — even though the attachments themselves were only a few KB in size.

At the moment, I have disabled all 941XXX and 942XXX rules. When these OWASP rules are skipped, the issue no longer occurs and attachments work as expected. From a security perspective, I cannot fully assess the impact of this change. However, we do have additional security measures in place, which likely helps keep the overall risk manageable.

Best regards

Hello everyone,

we are currently migrating from Sophos UTM9 to OPNsense Business Edition and are using the OPNWAF plugin.

The goal is to publish Outlook Web Application (Exchange Server SE) exclusively via reverse proxy/WAF. In general, access to OWA is already working stable.


Problem:

Uploading or attaching files in emails does not work. The upload area just shows a loading spinner which never completes.

No visible rule in the security log that is blocking the upload (at least not identifiable to me)

If Web Protection is disabled → uploads work immediately
If Web Protection is set to "Detect Only" → uploads still do not work ???
If Web Protection is enabled and all triggered rules are excluded/disabled, it also works



I have already disabled or excluded several triggered rules, including:

941100, 920451, 941160, 920640, 920450, 920420, 920180, 920440, 920650,
941180, 920480, 920340, 954130, 920171, 920540, 949059, 949159, 921130, 934100


Has anyone successfully run OWA behind OPNWAF?

If yes, which rules had to be disabled to make file uploads work?


Thanks in advance for any hints.

Best regards

Thanks for the fast reply!
OK, That makes sense. I'll go ahead and try using the regular ACME plugin together with OPNWAF as you suggested.

Thanks again!

Hy everyone,

I'm not sure if this is the right place for feature requests, but I'd like to ask for DNS-01 validation support in the ACME functionality of the OPNWAF Plugin in the Business Edition.

Right now, I can only find HTTP-01 validation in the Business ACME integration. Maybe I overlooked something, but DNS-01 support doesn't seem to be available.

Since the ACME plugin in the Community Edition already supports DNS-01, it would be extremely helpful to have the same capability in the Business Edition. Especially for environments where HTTP validation isn't possible (internal services, restricted firewalls, wildcard certificates, etc.).

Thanks, and apologies if this post should be placed elsewhere!