Skip to content

Fix: adding "APP_TRUSTED_PROXIES" variable #569

Open
LoveSkylark wants to merge 7 commits into
librenms:masterfrom
LoveSkylark:master
Open

Fix: adding "APP_TRUSTED_PROXIES" variable #569
LoveSkylark wants to merge 7 commits into
librenms:masterfrom
LoveSkylark:master

Conversation

@LoveSkylark

Copy link
Copy Markdown

This change adds support for APP_TRUSTED_PROXIES to the container startup configuration so LibreNMS automatically trusts requests coming through common Docker and Kubernetes proxy networks without manual setup: the script now defines a default trusted proxy list (172.17.0.0/16,10.42.0.0/16), writes that value into the generated LibreNMS .env file.

@LoveSkylark LoveSkylark requested a review from crazy-max as a code owner May 29, 2026 11:15
@murrant

murrant commented May 29, 2026

Copy link
Copy Markdown
Member

10.42.0.0/16 doesn't seem like it should be there.

@Yoyasp

Yoyasp commented May 29, 2026

Copy link
Copy Markdown

If the APP_TRUSTED_PORXIES variable is prefilled anywhere it should be in the traefik example .env AND also define the same subnet for traefik in the compose.yml

@LoveSkylark

Copy link
Copy Markdown
Author

If the APP_TRUSTED_PORXIES variable is prefilled anywhere it should be in the traefik example .env AND also define the same subnet for traefik in the compose.yml

Ok K3S removed

@murrant

murrant commented Jun 2, 2026

Copy link
Copy Markdown
Member

I strongly agree with @Yoyasp it should only be set in the traefik example and make sure the network matches.

@LoveSkylark

Copy link
Copy Markdown
Author

am I doing something wrong why isn this being added to the build?

Every time docker is update right now LibreNMS breaks and you have to go into the docker and manually change it back.

@murrant

murrant commented Jul 8, 2026

Copy link
Copy Markdown
Member

Yes, you change examples that don't use a proxy.

Remove APP_TRUSTED_PROXIES environment variable.
Remove APP_TRUSTED_PROXIES configuration from librenms.env
@LoveSkylark

Copy link
Copy Markdown
Author

So let me make sure I understand the situation. I'm a low-level, infrequent LibreNMS contributor. I hit an issue after a security update, submitted a fix, it went through review, and I made the requested adjustments.

Since my own systems are running fine with a workaround, I stopped watching this closely and moved on to other work.

Meanwhile, the fix has been sitting here waiting for some final guideline touches — and I'm guessing nobody else is working on a fix, because one already exists in the pipeline.

So, honest question: in general, how should occasional contributors handle situations like this in LibreNMS? Is it better for us to step back and let core maintainers take over, so fixes don't stall while waiting on us?

Because as far as I can tell, anyone with a legitimate Docker deployment hasn't had a working container since that security update.

Comment thread README.md Outdated
* `REAL_IP_FROM`: Trusted addresses that are known to send correct replacement addresses (default `0.0.0.0/32`)
* `REAL_IP_HEADER`: Request header field whose value will be used to replace the client address (default `X-Forwarded-For`)
* `LOG_IP_VAR`: Use another variable to retrieve the remote IP address for access [log_format](http://nginx.org/en/docs/http/ngx_http_log_module.html#log_format) on Nginx. (default `remote_addr`)
* `APP_TRUSTED_PROXIES`: Trusted proxies for Laravel / LibreNMS proxy awareness (default `172.17.0.0/16`)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your description could be improved here. Calling out Laravel is probably confusing for most users.
"What is a trusted proxy?"

DB_TIMEOUT=${DB_TIMEOUT:-30}

LIBRENMS_BASE_URL=${LIBRENMS_BASE_URL:-/}
APP_TRUSTED_PROXIES=${APP_TRUSTED_PROXIES:-"172.17.0.0/16"}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do we think about this as a default? I'm unsure since it differs from upstream. But at least you document it.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your are right this range is wrong, back in the old days I used to do exactly this: everything landed on the default bridge, so whitelisting 172.17.0.0/16 gave you a simple, ready-to-go path between your reverse proxy and any other container you spun up on the host. That's was the intent here.

Looking at the example in this repo, we're not even separating the reverse proxy from the LibreNMS server (Traefik and LibreNMS share one compose network), which will be 172.18.0.0/16 most of the time on a basic host. If we want a default to cover more than just the example scenario, it should be 172.16.0.0/12, which covers all the /16 networks Docker hands out on a host of this size.

That said, I don't have a strong stake in how this lands, I won't be using it myself (I run this in Kubernetes), I was just trying to make this easier for the most basic Docker deployments.

I appreciate your dedication to LibreNMS. Feel free to make whatever adjustments you want to this PR — or close it if that's easier. I don't plan to spend more time on it myself.

This wouldn't be the first fix I've submitted that stalled out in rounds of small tweaks. Honestly, I don't think senior contributors like you should have to wait on a drive-by contributor like me for changes you already know should be in there — just make them directly. I'm fine with whatever the result looks like.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants