after upgrade to OPNsense 25.1.7 caddy stopped working with reverse_proxy config

[Patrick M. Hausen]

My Nextcloud installation is rated A+ for SSL by Qualys and A+ by the Nextcloud security scan.

I fail to see what else I could do to harden the installation. In the hosting environment we sell the entire OS and "middleware" (installed packages) is mounted read-only into the customer jail.

What else? As an operator, not a developer!

Kind regards,
Patrick

[0zzy]

@meyerguru
you bring in the words I was searching for.
There isn't only one way. But many ways to reach a goal.

[0zzy]

My Nextcloud installation is rated A+ for SSL by Qualys and A+ by the Nextcloud security scan.

I fail to see what else I could do to harden the installation. In the hosting environment we sell the entire OS and "middleware" (installed packages) is mounted read-only into the customer jail.

What else? As an operator, not a developer!

Kind regards,
Patrick

I suggest to take a look at the following sites:

First is relative easy, also with a free account
https://www.cisecurity.org/

Take a look on the security benchmarks.

Second is made by multiple guys who are working on a tool named hardn.

It simplifies the art to get a system hardened.


https://undercodetesting.com/hardn-the-linux-security-project/


Also they are working on a BSD hardn project.

With that you get a quiet good score in different benchmarks.


Also not bad to have because it's free and gives you a little deep dive what's going on in your systems is an siem/xdr tool like wazuh.  It could help you to find out more deeply off your systems.


It isn't a dev thing I think. I'm not a dev, simply a tech guy who works in the it and appreciates to share my knowledge.

[Patrick M. Hausen]

But you started with this claim:

the problem is that the most homelab things are insecure by default.
mandatory security mechanisms like TLS-SNI, OCSP, Input Validation & Output Escaping, CSRF Protection, Secure Headers etc. are only mediocrely implemented in caddy on opnsense.

Caddy's job is SSL termination and reverse proxying. I don't see how OPNsense fails to deliver what the product is supposed to do. You will get an A from Qualys with just the default settings and an A+ when you add HSTS.

Everything else is just completely outside of the scope of Caddy on OPNsense. I guess what you want is a WAF ;-)

Kind regards,
Patrick

[meyergru]

Correct. Also, Caddy should not be adding things to the application stream, like HTTP headers. By trying to please security scanners, you might break some applications behind it.

Think of HTTP-Referrer policy: Yes, you could add a "samesite" to get a higher score, but depending on the application, it could break, so that should be the application's choice.

If at all, such things must be configurable. If you seek for more flexibility: HAproxy can do this by adding rules. I use it to add headers for signaling the backend servers of the incoming IP.

[0zzy]

Thanks guys for your comments for completeness.

Ok nevertheless, it's curious that after the newest update of opnsense and caddy,
That none of my reverseproxied entries in the caddy plugin are working except one.

If I try to, as an example invoice ninja, add it like ip/port 192.168.11.60:8035 http,
It doesn't work.
Where and that's really confusing only one entry is working (I have remotely an remote support tool configured without custom config).


So to get back to my previous question:

Why are my reverse proxy settings aren't work if I configure them over the caddy plugin in the webui?

[Patrick M. Hausen]

Post the caddyfile minus any secrets and we can pull in @Monviech for help.

[0zzy]

Of course:

Code Select Expand

# DO NOT EDIT THIS FILE -- OPNsense auto-generated file


# Global Options
{
log {
output net unixgram//var/run/caddy/log.sock {
}
format json {
time_format rfc3339
}
}

servers {
protocols h1 h2 h3
trusted_proxies static 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8
}

dynamic_dns {
provider cloudflare
domains {
zerot3ch.de *
zerot3ch.de remotely
}
ip_source interface igc0
update_only
}

email xxx@gmail.com
grace_period 10s
import /usr/local/etc/caddy/caddy.d/*.global
}

# Reverse Proxy Configuration


*.zerot3ch.de {
log {
output file /var/log/caddy/access/bb35164d-3b13-4c5c-a47e-6499b75c76da.log {
roll_keep_for 10d
}
}
tls {
issuer acme {
dns cloudflare
}
}

@258c701d-7862-4552-b894-d961cdbab7e4_zerot3chde {
not client_ip 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8
}
handle @258c701d-7862-4552-b894-d961cdbab7e4_zerot3chde {
abort
}
}

remotely.zerot3ch.de {
log {
output file /var/log/caddy/access/2b8651a0-b5db-41f6-9d3b-9a8f1109f3e1.log {
roll_keep_for 10d
}
}

@258c701d-7862-4552-b894-d961cdbab7e4_remotelyzerot3chde {
not client_ip 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8
}
handle @258c701d-7862-4552-b894-d961cdbab7e4_remotelyzerot3chde {
abort
}

handle {
reverse_proxy 192.168.11.60:5000 {
transport http {
}
}
}
}

This is the only reverse proxy entry which works.

Curiously if I remove the Access List from other entries than the remotely entry, it works.

Can someone explain why?

I use this described at https://docs.opnsense.org/manual/how-tos/caddy.html#restrict-access-to-internal-ips

Options Values
Access List Name: private_ipv4
Client IP Addresses: 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8
Description: Allow access from private IPv4 ranges

[Monviech (Cedrik)]

Sorry kinda low energy now at the end of the week.

Maybe do not attach the access list to the wildcard domain?

If not, I don't have a guess right now. Try to troubleshoot it yourself and if you find it out poke me so we can see if its something we have to fix in the template, or report upstream.