X-Forwarded-For Broken when IP is RFC1918

Plex Media Server
1

Server Version#: 1.20.2.3402
Running in Docker

Issue: Plex doesn’t honor X-Forwarded-For header if the IP in the header is coming from RFC1918. I can see the proper IP in the Verbose logging, but Plex itself ignores it and uses the Docker bridge IP instead. This only happens if the IP is RFC1918 - external clients work just fine.

As a result, Plex treats internal clients as WAN clients, which isn’t correct at all.

Example:
image

Here’s the snip of the logs for this stream that shows the X-Forwarded-For header is properly there when browsing plex.myurl.com:

Oct 06, 2020 21:45:01.774 [0x7f98027fc700] VERBOSE -  * Accept => */*
Oct 06, 2020 21:45:01.774 [0x7f98027fc700] VERBOSE -  * Accept-Encoding => gzip, deflate, br
Oct 06, 2020 21:45:01.774 [0x7f98027fc700] VERBOSE -  * Accept-Language => en-US,en;q=0.9
Oct 06, 2020 21:45:01.774 [0x7f98027fc700] VERBOSE -  * Host => plex.myurl.com
Oct 06, 2020 21:45:01.774 [0x7f98027fc700] VERBOSE -  * Referer => https://plex.url.com/web/index.html
Oct 06, 2020 21:45:01.774 [0x7f98027fc700] VERBOSE -  * Sec-Fetch-Dest => script
Oct 06, 2020 21:45:01.774 [0x7f98027fc700] VERBOSE -  * Sec-Fetch-Mode => no-cors
Oct 06, 2020 21:45:01.774 [0x7f98027fc700] VERBOSE -  * Sec-Fetch-Site => same-origin
Oct 06, 2020 21:45:01.774 [0x7f98027fc700] VERBOSE -  * User-Agent => Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.68 Safari/537.36 Edg/86.0.622.31
**Oct 06, 2020 21:45:01.774 [0x7f98027fc700] VERBOSE -  * X-Forwarded-For => 10.1.10.103**
Oct 06, 2020 21:45:01.774 [0x7f98027fc700] VERBOSE -  * X-Forwarded-Proto => https
Oct 06, 2020 21:45:01.774 [0x7f98027fc700] DEBUG - Final path: "/usr/lib/plexmediaserver/Resources/Plug-ins-0fec14d92/WebClient.bundle/Contents/Resources/js/chunk-8-19d56d8c33543111eef9-plex-4.34.4-7d609a3.js"
Oct 06, 2020 21:45:01.774 [0x7f98027fc700] VERBOSE - [IDLE] Adding (0->1) work item http_download - /web/js/chunk-8-19d56d8c33543111eef9-plex-4.34.4-7d609a3.js

I’ve confirmed via Chrome DevTools that I am talking 100% to plex.url.com (I’ve blocked plex.direct to force traffic through my proxy), I’ve confirmed that other non-RFC1918 IPs show up fine as X-Forwarded-For, and as a result, I’ve confirmed that my proxy (Caddy V2) is properly sending the header.

2

Anything here? Not even a look by anyone at Plex?

3

I imagine this is deliberate. Forging X-Forwarded-For headers is a common authentication bypass trick. If Plex trusted those addresses in XFF, anybody on the Internet could access any Plex server.

I don’t think Plex makes it possible to override this behavior or indicate that a proxy is trusted for XFF.

I think your choices are to configure 172.17.0.1 (the proxy, right?) as a LAN address in Plex. That should be fine since the XFF header will be parsed for external IPs.

Or change your setup so LAN clients communicate with Plex directly.

(Or do something horrible, like rewriting the XFF headers for LAN clients to some non-RFC1918 range …)

4

For now, internal clients just talk directly (I have my plex server IP in the “advertised clients” list, so that’s used, and https://plex.url.com:443 in there as second, so that’s used by external clients).

Just unfortunate that there’s an arbitrary block on RFC1918 addresses in x-forwarded-for. I guess I could hairpin NAT out my WAN back to my webserver, so requests look like they’re coming from my WAN IP. But that’s just as annoyingly complicated as anything else. Will probably just stick with my clients talking directly.

1 Like
5

Still no solutions here? I’d really rather not have to NAT loopback/hairpin as well. Why not allow a custom header to validate that traffic is through a reverse proxy?

6

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.