Messages

Hello,

We run OPNsense v25.10.2_12 with OPNWAF v2.1 proxy on top of it. There's a commercial wildcard certificate *.example.com installed on the machine. A couple of web sites use the cert with no problem. We also have a bunch of other web sites which use Let's Encrypt certificates managed by the OPNWAF built-in ACME client.

Now I need to set up a web site like a.b.example.com which is obviously not covered by the *.example.com certificate. I've enabled ACME in the respective Virtual Server configuration, but the certificate was not issued. What's worse, when I accept the self-signed fallback certificate, the proxy returns error 503. It does not even try to contact the upstream (back-end) web server.

Tried to set up another web site ab.example.com. It works with *.example.com but returns 503 when ACME is enabled (and fallback cert accepted). I cannot find any other output, there's no error in /var/log/apache/* log files even when I set logging to debug level. The Apache configuration in /usr/local/etc/apache24/Includes/gateway_vhosts.conf seems to be correct. Can it be that the two certificates (commercial + ACME one) cannot coexist for the same domain?

Thank you,
Ivo

P.S. Every OPNWAF reload takes 2-3 minutes during which one httpd process utilizes 100 % of one CPU core. None of web sites is working in such a moment of course which makes a reconfiguration quite difficult. The Apache error log reads "SIGUSR1 received. Doing graceful restart". Can it be that the config check takes so long? We have about 120 virtual hosts at the moment.

Hello,

I see your point. The configuration you suggest unfortunately doesn't seem to work.

I also tried other combinations of <Location> or <LocationMatch> and Redirect or RedirectMatch, the only working one is when Redirect is nested in <Location>, as mentioned in Apache docs: https://httpd.apache.org/docs/current/mod/mod_alias.html#redirect. It does not solve the problem though.

Code Select Expand

<Location "/one">
    Redirect 301 "http://newserver.com/one"
</Location>
RedirectMatch apparently cannot be enclosed in <Location>, at least the documentation doesn't mention such a case: https://httpd.apache.org/docs/current/mod/mod_alias.html#redirectmatch. If I am getting it right, RedirectMatch is interpreted before LocationMatch but due to the fact that it's enclosed inside LocationMatch, the whole block never gets triggered.

However, thanks to the Apache docs and ChatGPT, I've found a workaround which can even be used with the current GUI and Redirect Match type. :-) It makes use of environment variables.

The GUI fields look like this:

  Local path: /mailman/(?<CUSTOMPATH>.*)
  Remote destinations: https://<LIST-SERVER>/mailman/%{env:MATCH_CUSTOMPATH}

It translates into following configuration block in gateway_vhosts.conf:

Code Select Expand

<LocationMatch "/mailman/(?<CUSTOMPATH>.*)">
    RedirectMatch 308 "https://<LIST-SERVER>/mailman/%{env:MATCH_CUSTOMPATH}"
</LocationMatch>
It is a bit cumbersome, but works well. :-)

As a longer-term solution, perhaps implementing some basic GUI interface for mod_rewrite in addition to mod_alias would be fruitful?

Ivo

Hello all,

Running version 25.10.2_4 business. I need to redirect a local path to a particular remote destination; quite a usual task for which Apache RedirectMatch can be used.

According to https://docs.opnsense.org/vendor/deciso/opnwaf.html#redirect-match, I've set up the location this way (FQDNs have been redacted):

  Local path: ^/mailman/(.*)$
  Remote destinations: https://<LIST-SERVER>/mailman/$1

Basically it should catch requests for https://<MAIN-SERVER>/mailman/<ANYTHING> and redirect them to https://<LIST-SERVER>/mailman/<ANYTHING>. However, it does not work, the group captured in $1 is not passed to the destination, all requests end up at https://<LIST-SERVER>/mailman/.

The corresponding piece of configuration in /usr/local/etc/apache24/Includes/gateway_vhosts.conf looks like this.

  <LocationMatch "^/mailman/(.*)$">
    RedirectMatch 308 "https://<LIST-SERVER>/mailman/$1"
  </LocationMatch>

It doesn't seem to be correct though. <LocationMatch> does match ^/mailman/(.*)$, but RedirectMatch does NOT reuse that match, so $1 inside RedirectMatch is undefined. In Apache, <LocationMatch> captures are not passed into directives inside the block so RedirectMatch needs its own regex to define $1. Working configuration would look like this:

  <VirtualHost *:443>
  ...
  RedirectMatch 308 ^/mailman/(.*)$ https://<LIST-SERVER>/mailman/$1
  Redirect 301 / https://<MAIN-SERVER>/
  ...
  </VirtualHost>

I've actually updated gateway_vhosts.conf by hand and it works well. Until someone makes an update via GUI. :-)

Greetings,
Ivo

Ah right, the OPNWAF-made certificates are not included in /conf/config.xml that is synced to the Backup. The Caddy way seems to be somewhat bumpy, but the ACME plugin + OPNWAF could be a viable solution, I will give it a try. Thanks for the hint!

Another possibility, somewhat harsh though, would be to reboot the Master from time to time to make the Backup take over and force it to renew the certs. :-)

Hello,

We have two OPNsense nodes in High Availability setup. We use the OPNWAF plugin to proxy back-end hosted web sites. The plugin automatically manages TLS certificates from Let's Encrypt using the ACME protocol.

I've realized that the certificates are not synced from Master to Backup. The folder structure /usr/local/md/domains, where the certificates are stored on Master, is created on Backup but each subfolder contains a fallback cert+key only. In the result, when the Backup node takes over, all web sites throw a certificate error. The certs do get gradually renewed from LE but it takes a while during which the web sites are unreachable.

Is this on purpose? Wouldn't it be better to synchronize the certs+keys from Master to Backup as well?

Thank you,
Ivo