Server Version#: 1.13.9.5439
Server OS: Ubuntu 16.04.5 LTS (4.4.0-135-generic)
Player Version#:
Can someone, please, pretty please, with sugar on top, finally fix the blasted “Illegal whitelist covers multiple WAN IPs” error?
Assuming blindly that anything not in RFC1918 space is a “WAN” is WRONG.
Assuming blindly that everyone has a single IPv4 network is equally WRONG.
Assuming that someone who has multiple subnets is going to number them all out of RFC1918 space is WRONG.
Just because you’ve never run into it, doesn’t mean it isn’t PERFECTLY LEGITIMATE. In my case, I have an ARIN delegated “swamp C” and I use it. Don’t try to protect me from myself. I know better than you do.
I’m so, so tired of filling up logspace with this idiot warning being written to my logs EVERY HALF SECOND. If you stubbornly won’t fix the error, at least set it to only write the log message every 10 minutes or something.
Can you show me what you have and why it’s valid ?
Re: RFC1918, Can you provide me specific examples I can take to engineering and show them?
PMS 1.13.5 started to fix that. It didn’t work out the way they planned and it’s still not there. Engineering has been given working C code on how to do this. Why it’s not done is a mystery
Give me a snipped of that Log (or just the zip of the whole log) so I can take that with me as well to them?
I have this entry in “List of IP addresses and networks that are allowed without auth”:
192.104.XXX.0/24,192.168.217.0/24
(Note that I obfuscated the third octet here. I don’t mind sharing the actual block with Plex Dev, but not so much on an open forum as performing a whois lookup on the netblock returns PII)
My home network consists of several networks, connected by a multilegged firewall. One network with public IPs, which hosts servers etc., one for wifi users and another for IoT devices. The first two are the ones set in PMS.
When you ask “why it’s valid” I have to respond “why would you think it ISN’T valid?”
I don’t mean to be a jerk, but it’s like trying to prove a negative;
Consider that before NAT was invented and RFC1918 put in place, EVERY network segment had “regular” IP addresses. The RFC reserved 10/8, 172.16/12 and 192.168/16 as “private address space” so that they would only be used on LAN segmetns and not be routed across the internet, but that does NOT automatically make every other IP address a “WAN” address.
At one point it was possible to get a list of direct allocation networks from ARIN. No longer, apparently, but here is the definition from ARIN’s website (https://www.arin.net/knowledge/database_text.html)
" Direct Assignment : IP address space assigned directly from ARIN to an organization for its own exclusive use."
Using the config entries in #1 above, the log lines are like this:
Oct 17, 2018 16:07:02.312 [0x7fab4affd700] ERROR - Illegal whitelist covers multiple WAN IPs
Note that I’ve tried both “/24” and “/255.255.255.0” patterns for the mask and they are both accepted/give the same error, so it’s (probably) not a matter of syntax checking.
I do see that the rate at which the message is written to the logs slows down after a while, but
I asked, perhaps poorly, why it’s valid when I should have asked “What values do you have and where is PMS wrong?”
Past history:
Folks would disable remote security entirely.
Everyone could get in resulting in chaos and unauthorized use on WAN (including VPS)
Engineering enacted RFC1918 as the LAN vs WAN delimiter.
Any IP in same-subnet RFC1918 space could be designated as “auth free” in that setting. Otherwise, all clients, including LAN clients would require auth to connect to the server
Leveraging RFC1918 allows servers on one’s LAN to be ‘claimed’ with a mere token (Thought easier for most users)
what it does exclude, which you are now tripping over,
Authentication is required for PMS on a Campus-wide LAN style space.
Authentication is required for any client(s) not on the same subnet as the host itself and in RFC1918 space
All WAN-traversing (based on IP address) clients require auth. This means it won’t work if you setup PMS at Google, Apple, or any of the others who are publicly routable at the campus level (in spite of proper firewalls)
Engineering is protecting the home users who aren’t network savvy.
You and I know how to do this but the majority doesn’t.
Also, PMS is for domestic use and therefore should not be in a commercial IP space at a campus level where a netmask is required
So, I would ask why, if that’s the attitude, the option to set multiple nets/IPs is even present, except, I don’t want to see it disappear and then have to be MONUMENTALLY irritated.
IMO, the option to hide options by using the “Advanced” button is good for protecting casual users from dangerous options. I’d be absolutely fine with a documented set of options that have to be set via a config file that does not have a GUI for things that Plex engineering deems “only for those who are really savvy.”
I have “Prefer Auth” set, of course and this has only become an issue since the latest releases of the client for IOS and Roku do not work with PMS 1.13.9 (and maybe 1.13.8, I jumped from 1.13.5) in this network unless I set this option. That’s a different bug for a different thread.
I think it isn’t Plex’s developers job to try to distinguish what is truly a “campus” (which to me doesn’t mean multiple network segments, it means a complex of interconnected buildings) and what is a domestic network with multiple segments. (Aside: How would PMS treat a college dorm network? Many universities provision residence halls with public IP blocks).
If I tell PMS, via the options, that “here are the networks I consider local” then PMS needs to accept that, not decide it knows better. To do otherwise is deeply arrogant.
An educational institution is still outside the realm of of “Domestic use” and the EULA.
However, Plex has provided solutions under contract for such institutions and similar cases. For the greater-public, usage is constrained by the terms of the EULA. It is because of this publicly downloadable and otherwise-free software, Plex has chosen where and which constraints it will enforce.
Speaking to the point of multiple adapters at large, NAS users (myself included) have had issue with this for a long time. It’s not resolved. Professionally, i am optimistic. We will not discuss my personal views in this venue.
1.13.5 is flawed… simply flawed. It did not work out as they planned. They are still working on it. 1.13.9 still isn’t there.
If you want control, back down to 1.13.4 and do it manually with vlans and your own managed switch
This has wandered far astray from my initial post. Let me address that first:
Writing “error” messages at half second intervals is broken. Averageing 100 log entries for this per hour over 7 days is deeply broken.
Considering anything except RFC1918 space as “WAN” is not only deeply broken, but a complete misunderstanding of the findamental nature of the Internet. N.B. Comcast and Verizon provision RESIDENTIAL users with an IPv6 /56 block. That is 256 distinct LAN segments. This is not an oversight; it is BY DESIGN.
We can have philosophical discussions about how far to protect users from themselves until the cows from home. That won’t change any of the above facts.
Now, that said, you go on to write “publicly downloadable and otherwise-free software” and all I can do is look over at my icon, which, I’m rather convinced, indicates that someone, anyway, paid for this software and also rather expects it to follow basic standards.
I look forward to your forwarding my issues to the dev team so they can address the deficiencies.
Yes, having that error repeat so often is probably wrong. We can look into that. However, the error itself is correct. You are trying to do something that Plex doesn’t allow. If you want Plex to change that feature, please start a feature request and we can see if this is something that others also feel is needed.
Instead of worrying about the error, lets discuss why you want your publicly facing domain to be able to connect to your server without authentication. This would allow any computer on your entire network to be able to manage it and do whatever they want, including deleting your content. If you really want this option, you could just sign your server out from plex.tv then you don’t need authentication anymore.
I guess I’m trying to figure out why you would run any servers on the Net without them sitting behind a firewall with only ports that need to be open exposed? If you’re running throw away hosted servers then sure, but surely not anything you want to be secure like a Plex Server.
Move it to your inside LAN sitting behind the firewall NAT. Assign one of your “external IPs” to it on the firewall, setup routes and call it a day. You’re making this out to be something it’s not and you’re not following good security etiquette in doing so.
Do the above and you still have one of your IPs you fully control as the external IP Plex will use. You can then use the IP or assign a host.domain to it and use as you please.
But don’t expect non private IPs to get “free access” to the server.
And that has to do with Plex wanting to make sure your server isn’t exposed how?
I owned/ran one of the first ISP anywhere and developed into a wholesale business that over 500 other ISPs on multiple continents leased services from. I’m quite familiar with all the iana docs and specs. But that has nothing to do with Plex not wanting your server exposed to “external” IPs without authentication.
Probably less then 1 in a million Plex users will have your needs. It’s not reasonable to expect them to change this for a handful of users at best. Especially when these users should be among the most tech savvy users on the net. You should obviously know a handful of other ways you can achieve your goal with Plex being installed in this fashion.
I’m sure you’re quite aware you should be using private IPs internally with public IPs not going further than your firewall for security. If you did this you would not be having an issue.
I do not understand why you, ChuckPA and MovieFan.Plex, are SO invested in the idea that “not RFC1918” automatically means open to the public, or WAN or whatever you have defined it as.
It. Does. Not. Mean. Anything. Like. That.
It simply distinguishes routable address space vs non-routable address space: “Public” does NOT mean accessible, it means you can announce that space in the global internet route tables. There IS NO VALUE JUDGEMENT YOU CAN MAKE ABOUT HOW AN ADDRESS IS USED ON THE BASIS OF WHETHER IT IS ROUTABLE OR NOT.
Perhaps you are not aware that you can take ANY IP address range and use it inside your network and it will function JUST FINE (except that you won’t be able to connect to the real users of that block). Try it. Reconfgiure your home network to use 8.8.8.0/24. It’ll work fine, except you wont be able to reach Google’s DNS servers. Whups.
We do hear what you say but Plex has taken the decision that anything outside the definition of the Private Network Range https://en.wikipedia.org/wiki/Private_network cannot be whitelisted.
This has already been raised with the development team and I do not foresee any movement on that bearing in mind that it is only a handful of users it would benefit and in any case the decision was taken that authentication is the way to go and even localhost needs it and cannot be whitelisted and there is a bigger argument for that than your case
Agree that this should not be treated as an error and logging could be improved
you have an arin assigned publically routable subnet (regardless if you are using this as public or private)
you have your plex server an ip in this public subnet
plex does not whitelist public network ips
due to plex seeing the public ip as whitelisted, it logs an error too often
Already mentioned by plex team that the error logging could be improved
Already mentioned by plex team that white listing a public ip is not going to happen.
You have several choices;
a) put your plex server on a private ip and do ip and/or port mapping to the public ip of your choice.
b) leave it as is and hope that this thread has persuaded plex team to improve/reduce the amount of logging generated for this error for future releases
c) keep complaining
d) use a different product
did I miss anything?
edit: also it seems to be that the error should be rephrased as something like;
from: Illegal whitelist covers multiple WAN IPs
to: public network not authorized for whitelist
and log on start up
Or simply validate the whitelist subnet and prevent entry of non-RFC1918 networks from being added.
That is your interpretation but not in fact what is being done. Plex wants to be installed on a private address. This is not open to discussion. It should be in the range of:
10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
It has nothing to do with “public or private” per say but on a non-routable IP subnet. Anything outside this range of IPs is routable and there not where Plex wants to be installed.
But again this is easy/peasy stuff that you can “fix” or work-around quite easily if you choose to. You could for example assign an internal IP to the server, create a 1 to 1 translation on your router and you’re done.
Plex doesn’t want to open a can of security related worms for users who don’t understand routing. Those that want it on a public IP can “fake” it numerous different ways but MUST also take responsibility for this as well making things secure.
So just fix it using your router and a private IP and call it a day. No more bogus errors and it will be fully routable if that’s what you want.
