Audit Log file shows proxy IP instead of client IP (possible solution included)

[LaggAt]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug

When accessing the OPNsense WebGui via an reverse proxy the audit log contains the proxy IP address, not the client IP.

`
This is a Request via the reverse proxy on 127.0.0.1:
2024-11-25T22:30:56 | Notice | audit | /index.php: Successful login for user 'root' from: 127.0.0.1

This is a request from the same client to the WebGui directly:
2024-11-25T22:31:24 | Notice | audit | /index.php: Successful login for user 'root' from: 192.168.10.1
`

Minimal example setup:
Client --> Caddy Reverse Proxy on OPNsense (os-caddy) on :443 --> OPNsense on :8443

The issue is based on the fact, that we use $_SERVER['REMOTE_ADDR'] in the authgui.inc everywhere:

core/src/www/authgui.inc

Line 184 in 669a602

auth_log(sprintf("Successful login for user '%s' from: %s", $_POST['usernamefld'], $_SERVER['REMOTE_ADDR']), LOG_NOTICE);

I couldn't find an older version handling that different, so it seems this behavour is there forever.

According to this link below we could use HTTP_X_FORWARDED_FOR to get the real client's address. Caddy should already forward this. Only if this is empty we could fallback to REMOTE_ADDR. This should be the right value for 'trusted proxies'.

https://stackoverflow.com/a/4594873

My final use case would be CrowdSec to be able to block the original client, which therefore must be known in the audit logs.

To Reproduce

Steps to reproduce the behavior:

1. Go to 'System - Settings - Administration - Web Gui', configure "TCP Port" to 8443, and "HTTP Redirect" to disabled/checked, Alternate host names to the domain used to access the web UI (see 4.)
2. Go to 'System - Firmware - Plugins', istall os-caddy
3. Go to 'Services - Caddy Web Server - General', enable Caddy
4. Go to 'Services - Caddy Web Server - Domains', add a domain which points to the firewall (don't know if you could just use the IP address, that should be possible)
5. Go to 'Services - Caddy Web Server - HTTP Handlers', add a handler for the domain to Protocol https, Upstream Domain 127.0.0.1, Upstream Port 8443, and to make things easy here set the Checkbox for disable TLS Insecure Skip Verify.
6. If accessing from WAN, add a firewall rule to allow 443/TCP
7. log in via the Proxy via https://domain
8. Audit log shows 127.0.0.1 instead of your client IP.

Expected behavior

For a setup behind a reverse proxy we should have the client IP address in the audit logs.

Describe alternatives you considered

Two thoughts:

1. It may be an option to show both addresses (if they are set and differ). Then the log could look like: '/index.php: Successful login for user 'root' from: 192.168.10.1, via: 127.0.0.1'. This may require some follow up work on Crowdsec to recognize this, but it may be worth the effort.
2. we must have a list of trusted proxies in 'System - Settings - Administration - Web Gui'. Only if a host is in that list we trust and use HTTP_X_FORWARDED_FOR.

Screenshots

Configuration in System

Configuration in Services - Caddy Web Server (3 Screenshots)


I did use the self signed cert in trust pool instead of 'TLS Insecure Skip Verify':

Relevant log files

`
This is a Request via the reverse proxy on 127.0.0.1:
2024-11-25T22:30:56 | Notice | audit | /index.php: Successful login for user 'root' from: 127.0.0.1

This is a request from the same client to the WebGui directly:
2024-11-25T22:31:24 | Notice | audit | /index.php: Successful login for user 'root' from: 192.168.10.1
`

Additional context

https://stackoverflow.com/a/4594873
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For

Environment

OPNsense 24.7.9_1-amd64.

[LaggAt]

I'm happy to work on a fix on my own, after my vacation. In the meanwhile I am happy to hear your thoughts.

[fichtner]

Quick note from my side: yes, but...

HTTP_X_FORWARDED_FOR

This is harmful as a default. It can only be trusted if explicitly configured.

Cheers,
Franco

[fichtner]

EDIT:

we must have a list of trusted proxies in 'System - Settings - Administration - Web Gui'. Only if a host is in that list we trust and use HTTP_X_FORWARDED_FOR.

sounds like a plan so it still defaults to off

[LaggAt]

Yes, exactly. I'll reserve some time when I get back to get a development environment up and running. Thanks for your opinion on that matter.