NGINX Proxy - X-Forwarded-For ignored for 192.168 / 10.0 / private addresses

Plex Media Server Desktops & Laptops
,
1

Server Version#: 1.13.6.5339
Player Version#: N/A

So a quick clip from my debug logs:

Aug 31, 2018 10:12:05.608 [0x7f7bf93fe700] VERBOSE - X-Forwarded-For: 12.150.5.XXX
Aug 31, 2018 10:12:05.608 [0x7f7bf93fe700] DEBUG - Using X-Forwarded-For: 12.150.5.XXX as remote address

Aug 31, 2018 10:09:28.167 [0x7f7bf43fe700] VERBOSE -  * X-Real-IP => 10.0.8.6
Aug 31, 2018 10:09:28.168 [0x7f7bf43fe700] VERBOSE -  * X-Forwarded-For => 10.0.8.6
Aug 31, 2018 10:09:28.168 [0x7f7bf43fe700] VERBOSE -  * X-Forwarded-Proto => https

If I have any private range IP addresses, they do not seem to get honored and report properly so everything shows from 127.0.0.1.

You can see on the non private, it generates the “Using X-Forwarded-For: 12.150.5.XXX as remote address” but never does on 10.0.8.0 or 192.168.1.0

Is that by design as the proxy is doing the right thing in terms of forwarding the proper IP.

2

Looks like you have a proxy configuration issue but unfortunately outside the scope of our help here.
Perhaps one of the other users can assist.

3

I’m pretty sure my proxy config is correct.

Is there any reason Plex would not honor the header for internal addresses? There is a similar issue for IPV6 not being honored which is a plex issue…

4

V6 isn’t supported by PMS for anything external (yet).
I remember seeing something about using a 301 rewrite (?) when using a proxy. I don’t know what that means but I’ve seen it makes a difference between success and failure.
Also, PMS does not like its cert usurped so be advised of that when using your cert.

LAN should be just LAN.

5

My config for the proxy is doing exactly the right thing to get the request to plex. With a non private IP, it does:

Aug 31, 2018 13:47:14.290 [0x7f1bec7ff700] VERBOSE - X-Forwarded-For: 73.81.0.XX
Aug 31, 2018 13:47:14.290 [0x7f1bec7ff700] DEBUG - Using X-Forwarded-For: 73.81.0.XX as remote address

but when it’s a private IP, it doesn’t create the 2nd line, which leads me to Plex not liking the private addresses. I can play / stream everything fine from every location, but since it doesn’t pass it, it thinks it is coming from 127.0.0.1 , which shows up as the WAN.

Aug 31, 2018 13:41:22.296 [0x7f1bc3ffd700] VERBOSE -  * X-Real-IP => 10.0.8.6
Aug 31, 2018 13:41:22.296 [0x7f1bc3ffd700] VERBOSE -  * X-Forwarded-For => 10.0.8.6
Aug 31, 2018 13:41:22.296 [0x7f1bc3ffd700] VERBOSE -  * X-Forwarded-Proto => https

Is there a check at this spot “DEBUG - Using X-Forwarded-For” for a private network and to drop it?

6

It isn’t else it’s would be working but why is the question and why it’s out of scope for us to support Proxy issues.

PMS does strictly adhere to RFC1918 Private Networking conventions.

7

Thanks for the quick replies.

So far all the data points to Plex not honoring the X-Forwarded-For tag that is coming in as the logs clearly show the proper private IP being passed.

It’s reproducible with 192.168.0/10.0.8.0.

8

This is why proxies are beyond scope…

PMS looks at the source IP field in the packet. If you’re injecting some tag (again , i don’t understand this stuff) it won’t see it.

9

No issues as I truly appreciate the feedback.

The source ip on the packet isn’t being used as that would be the proxy sending the traffic. The
X-Forwarded-For part of the HTTP traffic is what Plex is interpreting and replacing that with the IP.

Similar with proxying via Cloudflare:

I’m just baffled as to why the internal addresses are being ignored while external are as it’s in Plex since the packet captures and all the plex debug logs show the proper header.

In the cloudflare example, it’s just saying if you see a real ip that’s one of those, replace the real ip with the source IP from cloudflare that is passes over.

It’s the specific code in Plex that’s here:

14.290 [0x7f1bec7ff700] DEBUG - Using X-Forwarded-For: 73.81.0.XX as remote address

That’s ignoring the private RFC range.

10

If PMS is ignoring the (resending) IP of the proxy host itself, then one of the translations of IP addresses isn’t being done.

As I understand a proxy (an agent performing a task on the sender’s behalf)

  1. Client sends to Proxy
  2. Proxy rewrites all applicable elements of the original request, removes excess or adds elements (like token, etc) required.
  3. Sends request to destination.
  4. Destination (PMS) replies to Proxy
  5. Proxy reverse edits the data and sends back to the original requester.

Therefore, in #2 above, what’s not being done?

This is where I must now stop.
I wish you well.

11

That’s the point #2 is being done properly. The debug logs are the proof from Plex.

You can see it in the Plex Debug output as the proper X-Forwarded-For header that’s listed there:

Example:
The general format of the field is:

X-Forwarded-For: client, proxy1, proxy2[3]

Plex is ignoring the X-Forwarded-For header for the private addresses. This debug line is the key:

Aug 31, 2018 13:41:22.296 [0x7f1bc3ffd700] VERBOSE -  * X-Forwarded-For => 10.0.8.6

Plex should report the IP as 10.0.8.6 and it ignores is and reports as 127.0.0.1

The lines above it show it uses the same header and doing it properly.

12

Seems like Plex discards certain XFF headers based on some logic. A found a few posts (old) saying the same thing.

I worked around this issue as my real LAN connections show up 127.0.0.1 and added that on my LAN List.

My WANs show up as their proper IPs if anyone else hits the issue.

13

Same issue with Caddy as a proxy over NGINX.

# Plex Server
plex.example.com {
gzip
timeouts 1h
log /opt/caddy/logs/plex.log
tls {
	dns cloudflare
}
proxy / 127.0.0.1:32400 {
	transparent
 	websocket
	keepalive 12
	timeout 1h
    }
}

That’s 2 different proxy servers sending a proper X-Forward-For that plex is ignoring based on the debug / verbose plex logs.

15

I changed my internal network to 100.64.8.0 for my VPN and VPN’ed in tested, the config and I can see the X-Forward-For being passed.

This is normally used for Carrier Grade NAT -> https://en.wikipedia.org/wiki/Carrier-grade_NAT
so I was sure it wouldn’t be routed.

I changed the VPN NAT a few times to all the private ranges and they are not respected by Plex as the X-Forward-For.

The ones that do not work are the RFC private ranges 192.168.1/192.168.2/10.0.8.0 are the /24 I tested so I’d surmise it’s all the RFC subnets that Plex drops as an X-Forward-For.

16

Screenshot of it working:

image
image.png1006Ă—186 29.9 KB

18

I am having the same issue. And I can confirm this is not a config issue but a PMS issue. Any private address that gets sent as X-Forwarded-For is ignored.

More details here: Plex API - Sessions Status not honoring X-Forwarded-For & X-Real-IP with IPv6 clients

19

Hi all,

I’m also having the issue with my setup. I have plex hosted on a cloud VPS at scaleway. At my home I have a direct VPN connect to that VPS. When I’m at home / or connected to the VPN, traffic directed to my domain name is transparently routed towards the VPN tunnel. I also have traefik as a reversed proxy doing all the nice things with Let’s encrypt.

The following trick with the CGNat prefix works well, now I’m correctly seeing that it is correctly setting remote-addr from X-Forwarded-For header:
Nov 28, 2018 21:14:27.876 [0x7f5278bff700] DEBUG - Using X-Forwarded-For: 100.64.8.1 as remote address

But once you want to setup the list of IP addresses and networks that are allowed without auth. Basically accessing plex from within the LAN should not require authentication, things breaks. Because it wrongly evaluation 100.64.0.0/10 as a public routable address, which is not the case: https://en.wikipedia.org/wiki/Reserved_IP_addresses:

From the logs:
Nov 28, 2018 21:14:27.876 [0x7f5278bff700] ERROR - Illegal whitelist covers multiple WAN IPs

Do you have already observed that kind of issue?

Regards,

21

They have no plans to fix it as they refuse to admit it exists so I wouldn’t hope for any updates/fixes.

I just ignore it for now since it only impacts my internal clients anyway. It’s just annoying that they refuse to confirm it’s an issue.