Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Lemimouth

#1
Thanks for your answer. I managed to get it working, I stupidely forgot that I have an other custom config file in /usr/local/etc/caddy/caddy.d, and it was listing to 443... I changed it to 8443 (same port as defined in Advanced Settings) and now everything's fine.

Sorry for this useless post !
#2
Hi,

I've set up Caddy plugin and bound it to a specific interface by following the doc here : https://docs.opnsense.org/manual/how-tos/caddy.html#bind-caddy-to-interfaces. It works fine.

Now, I'm trying to run it unprivileged (https://docs.opnsense.org/manual/how-tos/caddy.html#run-caddy-process-unprivileged), but even if I change the ports to 8080 and 8443 in the Advanced Settings page, it tries to listen on port 443 when applying the change and restarting.

In the logs :

Error: loading initial config: loading new config: http app module: start: listening on 10.0.0.5:443: listen tcp 10.0.0.5:443: bind: permission denied
And in Caddy > Diagnotics > JSON Configuration, I see that it specifically tries to listen to port 443 :

{
  "apps": {
    "http": {
      "grace_period": 10000000000,
      "http_port": 8080,
      "https_port": 8443,
      "servers": {
        "srv0": {
          "automatic_https": {
            "disable": true
          },
          "listen": [
            "10.0.0.5:443"
          ],

Any idea ? Are these 2 features (binding to a specific interface and running unprivileged) imcompatible with each other ?
#3
I wasn't aware of the add-package command, nice to know ! I also use Caddy in Docker in other parts of my network and simply build it with xcaddy to include the plugins I use. I don't feel THAT adventurous with my OPNSense installation. ;)

You're right, the Caddy's OPNSense plugin should be as generic as possible for ease of maintenance. This is totally not a feature request ;)
#4
Quote from: Monviech (Cedrik) on March 28, 2025, 10:17:49 PMIt would need to be added into caddy with one of those bouncer plugins to work.

Yes exactly.

I'm not sure it's (easily) feasible on OPNSense because, to my knowledge, Caddy must be compiled with the caddy-crowdsec-bouncer plugin. It's not something you can enable just by installing a plugin.

I'll disable CF proxy for now and let CrowdSec doing it's job.

Thanks for you time helping me ;)
#5
After doing some more tests, this in fact doesn't work, at least with the default bouncer that is installed with the CrowsSec plugin.

The reason is that in Caddy's log, I have now the correct value for the client_ip field (the real ip of the client), and CrowdSec blocks connections based on this ip. But as my domain is behind Cloudflare, the connection comes from the CF proxy ip address and not directly from the client.

I disabled CF proxy for the moment, and it's working again.

Also, I added the following block in /usr/local/etc/caddy/caddy.d/logger.conf :

:443 {
log {
output file /var/log/caddy/access/access.log {
roll_keep_for 10d
}
}

handle {
        abort
    }
}

If not doing that, Caddy is logging access ONLY for the configured domains in Reverse Proxy > Domains.
#6
Well the Caddy part seems to work. In Diagnostics > Caddyfile I have now :

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

servers {
protocols h1 h2 h3
trusted_proxies static 173.245.48.0/20 103.21.244.0/22 103.22.200.0/22 103.31.4.0/22 141.101.64.0/18 108.162.192.0/18 190.93.240.0/20 188.114.96.0/20 197.234.240.0/22 198.41.128.0/17 162.158.0.0/15 104.16.0.0/13 104.24.0.0/14 172.64.0.0/13 131.0.72.0/22
client_ip_headers Cf-Connecting-Ip
client_ip_headers X-Forwarded-For
}

auto_https off
grace_period 10s
import /usr/local/etc/caddy/caddy.d/*.global
}

In Caddy log, the client_ip field shows my real ip address :

"request": {
        "remote_ip": "162.158.xxx.xx",
        "remote_port": "48400",
        "client_ip": "194.xxx.xxx.xx",
        "proto": "HTTP/2.0",

Now I have to check if CrowdSed is doing it's job.

When doing cscli metrics, I can see that the counter for crowdsecurity/caddy-logs is increasing after each request, so it's a good sign.

Thank again !
#7
I didn't set these headers earlier because, to be honest, I hadn't figured out how to. But now it's done! 😉 (For the record, I had to add them first in Reverse Proxy > Headers, and only then could I select them in General > Advanced).

Thanks ! step 1 is done.

Regarding the trusted proxies, is there a way to automate this ?

In the Github issue, I can see :

trusted_proxies static <ips> # https://www.cloudflare.com/ips/
Do I have to manually add all ranges from https://www.cloudflare.com/ips-v4/# ?

#8
Hi,

I just set up Caddy with CorwdSec integration by following the doc (https://docs.opnsense.org/manual/how-tos/caddy.html#crowdsec-integration). How can I be sure that CrowdSec is parsing Caddy logs correctly ?

My external domain is proxified by Cloudflare, so in Caddy logs, the real client ip address is not in the remote_ip header, but in the X-Forwarded-For and Cf-Connecting-Ip headers.

I've checked the CrowdSec's Caddy parser configuration here : https://app.crowdsec.net/hub/author/crowdsecurity/log-parsers/caddy-logs

But it's not clear :



Thanks !