Messages

Hello,

i think something isn´t correct in my setup. most of the time, Caddy crashes and authentication doesn´t work as expected.

I´m running a synology NAS on IP 10.10.5.151 with some Docker images:

it-tools = 10.10.5.151:8080
authelia = 10.10.5.151:9091

results while testing authentication:

from external: tools.home.mydomain.com

if i open https://tools.home.mydomain.com - i directly get the it-tools installation - without an Authelia forwarding.
if i open https://auth.home.mydomain.com i get the Authelia login and authentication works.
if i open https://auth.home.mydomain.com?rd=tools.home.mydomain.com - authentication works an i get an redirect to "it-tools".

from internal:
if i open https://auth.home.mydomain.com i get the Authelia login and authentication works.
if i open https://auth.home.mydomain.com?rd=tools.home.mydomain.com - i get an error regarding "forwarding is insecure" and caddy crashes

in unbound dns i configured the hosts with the internal ip pointing to the firewall-lan interface (10.10.5.1)

auth.home.mydomain.com IN A 10.10.5.1
tools.home.mydomain.com IN A 10.10.5.1
fw.home.mydomain.com IN A 10.10.5.1

ds.mydomain.com IN A 10.10.5.151 (Synology NAS / Docker Host)


reverse proxy with certifcates etc. - without any authentication - work - but sometimes caddy crashes, too.


Caddyfile:

Code Select Expand

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


# caddy_user=root

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

servers {
protocols h1 h2
log_credentials
}

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

# Reverse Proxy Configuration


# Reverse Proxy Domain: "dc203656-b1d5-4b74-9e16-86dd1e64652b"
ds.home.mydomain.com {
log {
output file /var/log/caddy/access/dc203656-b1d5-4b74-9e16-86dd1e64652b.log {
roll_keep_for 2d
}
}

handle {
forward_auth https://auth.home.mydomain.com:443 {
uri /api/authz/forward-auth
copy_headers Remote-User Remote-Groups Remote-Name Remote-Email
}
reverse_proxy 10.10.5.151:5000 {
}
}
}
# Reverse Proxy Domain: "6272e920-fdb3-4f5a-93f7-baeb70c45108"
fw.home.mydomain.com {
log {
output file /var/log/caddy/access/6272e920-fdb3-4f5a-93f7-baeb70c45108.log {
roll_keep_for 2d
}
}

handle {
reverse_proxy https://10.10.5.1:9443 {
transport http {
tls_insecure_skip_verify
tls_trust_pool file /var/db/caddy/data/caddy/certificates/temp/6704dd221487f.pem
tls_server_name fw.home.mydomain.com
}
}
}
}
# Reverse Proxy Domain: "ca806ad3-e0cd-45ca-8585-5299e86f9ce8"
tools.home.mydomain.com {
log {
output file /var/log/caddy/access/ca806ad3-e0cd-45ca-8585-5299e86f9ce8.log {
roll_keep_for 2d
}
}

handle {
forward_auth https://auth.home.mydomain.com:443 {
uri /api/authz/forward-auth
copy_headers Remote-User Remote-Groups Remote-Name Remote-Email
}
reverse_proxy ds.mydomain.com:8080 {
}
}
}
# Reverse Proxy Domain: "b105594c-de36-4ecb-b10b-7d3bd33e57ad"
auth.home.mydomain.com {
log {
output file /var/log/caddy/access/b105594c-de36-4ecb-b10b-7d3bd33e57ad.log {
roll_keep_for 2d
}
}

handle {
reverse_proxy ds.mydomain.com:9091 {
}
}
}

import /usr/local/etc/caddy/caddy.d/*.conf




Docker-Image Authelia-Logs
time="2025-02-02T17:38:12Z" level=error msg="unable to determine if uri tools.home.mydomain.com is safe to redirect to: failed to parse URI 'tools.home.mydomain.com': parse \"tools.home.mydomain.com\": invalid URI for request" method=POST path=/api/checks/safe-redirection remote_ip=10.10.5.220

time="2025-02-02T17:38:49Z" level=error msg="unable to parse target URL tools.home.mydomain.com: parse \"tools.home.mydomain.com\": invalid URI for request" method=POST path=/api/firstfactor remote_ip=10.10.5.220

time="2025-02-02T17:38:40Z" level=error msg="Request timeout occurred while handling request from client." error="read tcp 172.17.0.3:9091->172.17.0.1:34082: i/o timeout" method=GET path=/ remote_ip=172.17.0.1 status_code=408

time="2025-02-02T17:38:40Z" level=error msg="unable to parse target URL tools.home.mydomain.com: parse \"tools.home.mydomain.com\": invalid URI for request" method=POST path=/api/firstfactor remote_ip=10.10.5.220

Code Select Expand

time="2025-02-02T17:45:05Z" level=error msg="Request timeout occurred while handling request from client." error="read tcp 172.17.0.3:9091->172.17.0.1:34320: i/o timeout" method=GET path=/ remote_ip=172.17.0.1 status_code=408


Caddy Logfile

Code Select Expand

"warn","ts":"2025-02-02T18:05:48Z","logger":"http","msg":"HTTP/2 skipped because it requires TLS","network":"tcp","addr":":80"}
with a bunch of these errors:

Code Select Expand

"debug","ts":"2025-02-02T17:58:38Z","logger":"http.handlers.reverse_proxy","msg":"upstream roundtrip","upstream":"auth.home.mydomain.com:443","duration":0.299655262,"request":{"remote_ip":"10.10.5.1","remote_port":"27569","client_ip":"10.10.5.1","proto":"HTTP/2.0","method":"GET","host":"tools.home.mydomain.com","uri":"/api/authz/forward-auth","headers":{"Cache-Control":["no-cache"],"Sec-Ch-Ua-Mobile":["?0"],"X-Forwarded-For":["10.10.5.1"],"Sec-Fetch-Mode":["no-cors"],"Sec-Fetch-Dest":["image"],"Sec-Ch-Ua":["\"Not A(Brand\";v=\"8\", \"Chromium\";v=\"132\", \"Google Chrome\";v=\"132\""],"Accept":["image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8"],"X-Forwarded-Method":["GET"],"X-Forwarded-Host":["tools.home.mydomain.com"],"Referer":["https://tools.home.mydomain.com/"],"Accept-Language":["de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7"],"X-Forwarded-Proto":["https"],"Priority":["u=1, i"],"X-Forwarded-Uri":["/api/authz/forward-auth"],"User-Agent":["Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/132.0.0.0 Safari/537.36"],"Cookie":["authelia_session=K^P1omP********DmBs!1yTfdqEblibj"],"Sec-Fetch-Site":["same-origin"],"Pragma":["no-cache"],"Sec-Ch-Ua-Platform":["\"Windows\""],"Accept-Encoding":["gzip, deflate, br, zstd"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"auth.home.mydomain.com"}},"error":"context canceled"}
Authelia configuration.yaml

Code Select Expand

server:
  address: tcp://0.0.0.0:9091/
  endpoints:
    authz:
      forward-auth:
        implementation: 'ForwardAuth'
        authn_strategies: []

access_control:
  default_policy: deny
  rules:
    - domain: '*.mydomain.com'
      policy: one_factor

identity_validation:
  reset_password:
    jwt_secret: *****************************
session:
  name: authelia_session
  secret: ********************************
  expiration: 1h
  cookies:
    - domain: mydomain.com
      authelia_url: 'https://auth.home.mydomain.com'

authentication_backend:
  file:
    path: /config/users_database.yml
storage:
  local:
    path: /config/db.sqlite3
  encryption_key: *************************

notifier:
  filesystem:
    filename: /config/notification.log

Thanks a lot!

We found an info, that we need to set: "reply-to"  to inactive. 

this was the key, but i wonder  why this setting was not needed on our other installations.

hi, is there anything changed in 21.1 behaviour regarding opening WebGUI access from WAN interface?

we have freshly installed opnsense and

- configured a new webgui port,
- proved listining on "all" interfaces is checked
- added a firewall rule to allow to "this firewall",

the firewall log shows, that everything is "green", so firewall shouldn´t be the problem..


but we cannot connect to the gui via wan port.

> Jedenfalls kann ich mich gelegentlich nicht einloggen. Laut Protokoll bin ich aber "erfolgreich eingeloggt":

Und was IST "nicht einloggen"? Timeout vom Browser? Lädt endlos?

sobald ich Username u. Passwort eingebe und absende, erscheint die geleerte Anmeldemaske erneut. Im Log sehe ich aber, dass ich "angeblich" korrekt eingeloggt bin.

->> Dec 10 13:26:34   opnsense: /index.php: Successful login for user 'root' from: 178.142.XXX.XXX

Dann kann man sich auch ggf. mit SSH etwas "bauen", einen Grund die administrative UI public im Web zu öffnen sehe ich da aber nicht...

Gruß

Um wenigstens den Großteil der Angriffe abzublocken, habe ich das GUI auf einen Highport > 1024 abgelegt.

Hallo, ich habe das WegGUI über WAN freigegeben (ja, ich weiß, sollte man nicht tun;)), ich habe nur leider nicht immer VPN-Zugang zur Verfügung...

Jedenfalls kann ich mich gelegentlich nicht einloggen. Laut Protokoll bin ich aber "erfolgreich eingeloggt":

Dec 10 13:26:34   opnsense: /index.php: Successful login for user 'root' from: 178.142.XXX.XXX

Per VPN und über LAN Schnittstelle anmelden (192.168.x.x) klappt es immer.  Hat jemand eine Idee, was da falsch läuft?

Das Problem hatte ich damals auch schon häufiger, als ich noch mit pfSense gearbeitet hatte.

Danke! Seltsam, ich habe da keine "block all" rule.. ??? Ist die auf dem jeweiligen Interface-Tab der Firewall-Rules sichtbar, oder muss man die in den Einstellungen deaktivieren? Bei mir klappt Ftp zur Zeit nur, wenn ich high-ports komplett erlaube - aber das sollte ja nicht so bleiben.

Hey, habe das gleiche Problem. Konntest du es lösen, ohne die Ports wieder aufzumachen?
VG Holger