You should never use a publicly routed subnet for the purposes of NAT on your LAN. It is bad practice and makes it impossible for you to ever get to the real 192.254.222.x/24 subnet.
You need to use any subnet from the RFC1918 allocation:
10.0.0.0/8 aka 10.0.0.0-10.255.255.255
172.16.0.0/12 aka 172.16.0.0-172.31.255.255
192.168.0.0/16 aka 192.168.0.0-192.168.255.255
If you wanted to be obscure, you could have used 10.254.222.0/24 or 172.31.222.0/24 or 192.168.222.0/24 but do please absolutely change your LAN subnet to something proper instead of hijacking an ARIN assigned address block.
whois 192.254.222.0
#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/resources/registry/whois/tou/
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/resources/registry/whois/inaccuracy_reporting/
#
# Copyright 1997-2019, American Registry for Internet Numbers, Ltd.
#
NetRange: 192.254.128.0 - 192.254.255.255
CIDR: 192.254.128.0/17
NetName: HGBLOCK-9
NetHandle: NET-192-254-128-0-1
Parent: NET192 (NET-192-0-0-0-0)
NetType: Direct Allocation
OriginAS:
Organization: WEBSITEWELCOME.COM (BO)
RegDate: 2013-06-11
Updated: 2013-06-11
Ref: https://rdap.arin.net/registry/ip/192.254.128.0
OrgName: WEBSITEWELCOME.COM
OrgId: BO
Address: 5005 Mitchelldale
Address: Suite #100
City: Houston
StateProv: TX
PostalCode: 77092
Country: US
RegDate: 2011-02-16
Updated: 2019-09-03
Ref: https://rdap.arin.net/registry/entity/BO
I’m not sure why your internal network IPs matter as long as it shares the same subnet. In large or in my case small environment, it’s not uncommon to use subnet values outside of RFC1918 because those addresses are the first to be crawled for nefarious purposes by malware, etc.
I’m also having this issue. The Plex Server is 20.1.10.6 and even when I connect to it from a 20.1.10.58 directly, it still listed as Remote. All clients in the house also load as remote.
Do we have a configuration that can be changed to account for systems that don’t use the normal out of box ranges?
As the text states: “… when enforcing bandwidth restrictions…”
It does not state it changes the behavior to create exceptions to the RFC-1918 requirement.
I forgot to mention. I had a Windows PC running Plex with this same IP and everything was listed as local, recently switched to a NAS and have this remote issue.
Isn’t the reason for transcoding a bandwidth restriction between the server and client?
Primarily, transcoding is to convert the source media into a format which is acceptable to the client.
The Plex Transcoder can be also used to enforce streaming bandwidth restrictions. It does this by ‘down transcoding’ to a lower quality for specific segments of the stream as it is occurring.
Okay. I think the solution will have to be set all clients to Maximum quality as default.
Would using IPv6 change this if the server doesn’t have a IPv4 address?
Also, I tried your SSH advice in another thread and can connect to my nas with an Admin user. However when I visit http://127.0.0.1:8888/web I see in terminal: channel 3: open failed: administratively prohibited: open failed
I can give you a very good reason not to use publicly routable IP ranges for your LAN: They are almost certainly going to be owned by someone and in many cases they will have a web presence. In the event that you actually attempt to visit a website which uses an IP address covered in your LAN range, you will not be able to reach it.
In your specific example, 20.1.10.6 is owned by Microsoft. Here’s the ‘whois’ data:
NetRange: 20.0.0.0 - 20.31.255.255
CIDR: 20.0.0.0/11
NetName: MSFT
NetHandle: NET-20-0-0-0-1
Parent: NET20 (NET-20-0-0-0-0)
NetType: Direct Assignment
OriginAS:
Organization: Microsoft Corporation (MSFT)
RegDate: 2017-10-18
Updated: 2017-10-18
Ref: https://rdap.arin.net/registry/ip/20.0.0.0
OrgName: Microsoft Corporation
OrgId: MSFT
Address: One Microsoft Way
City: Redmond
StateProv: WA
PostalCode: 98052
Country: US
RegDate: 1998-07-09
Updated: 2017-01-28
They may or may not be using that range for something public-facing, but they could. You’d be far better off using a range earmarked for LAN usage. Your security concerns are noted, but it may be that they are overshadowed by the likelihood that some bad actor will be probing ranges owned by Microsoft or some other corporation. Do yourself a favor and fix your network. The (in)correctness of PMS’ logic for determining whether or not a network is local aside, it’s just a good idea.
Sorry but I am not going to spend time teaching you network engineering. Short answer, do not use public IP space for your LAN. There are things that Plex does with the IP address reported to plex.tv and in your case it will be trying to contact MSFT servers.
