Server Version#: Version 4.57.4
Player Version#: 1.33.0.2444-a220eae4
On my Windows Plex Server, I have two network connections: 10.x.x.x wired and 192.x.x.x wireless (different ISPs). Is there a way for Plex to serve both networks? Right now it only serves the 10. I have the server setting “Preferred network interface” set to Any but the 192 network does not show in the drop down. Hopefully I have just overlooked something.
Thanks in advance for your help.
No, it is not possible to work on 2 networks simultaneously.
That stinks… but it is at least an answer. Thanks!
Not sure why this would not work, so long as the routing table for the PMS is correct.
And if it really doesn’t work, then what is the point of this setting???
Anyway, Plex aside… @deersew … I am guessing you are using 2 different routers with your 2 ISP’s and that is the reason there are 2 internal LAN’s??
If so, then have you considered swapping out your routers for a single unit that can handle multiple WAN’s?
Most of the DrayTek routers can certainly do that, and obviously this would effectively make your original question irrelevant as you would end up with a single router, controlling both internet connections, but only having a single internal LAN.
You are correct @axemanuk666. I have a work ISP and personal ISP. I also agree that the “all” option dropdown is odd if that is now the purpose of it.
I haven’t tried a DrayTek. I have tried some others and they just never worked well. I will give the DrayTek a shot. Thanks!
Depending on how your 2 services are presented to you, will depend on which model you will need.
If you decide to give it a go, and need some help choosing which model to get, do let me know as I am actually DrayTek certified, and have been using these units for years 
Because unfortunately it’s not only about routing. They issue a certificate for your server and in your url goes the IP in use.
Alternatively I think you could script that “high availability”.
Never tried it and I don’t know if it would work, but in my head it does haha
Indeed, however the certificate is NOT bound to your Internal LAN address. You can prove this by prefixing your URL in the browser with https://… You will find you get a Privacy Error, stating that the certificate .random-set-of-numbers-and-letters.plex.direct is invalid… Or some other related error.
I can well imaging that the certificate may be bound to your Public IP Address, but certainly not private.
Anyways, all that aside, as a networking engineer I certainly wouldn’t try to use it in a multi-LAN environment anyway, as that would just be considered bad practice.
Hence my suggestion to use a Multi-WAN capable router, such as a DrayTek.
It’s not, it uses your wan ip and I’m assuming he has to wan IPs.
Yes, he would have to WAN IP’s, which now I think about it, could be interesting!
If that was my setup, I would probably configure outbound routing to ensure that Plex traffic only uses 1 of the 2 WANs.
The server certificate is a wildcard cert in the form *.your_certificate_uuid.plex.direct. The final FQDN for any specific Plex Media Server ends up being that, with the server’s IP address (hyphen-delimited) in place of the asterisk. So, for example:
192-168-1-100.abcdef1234567890fedcba0987654321.plex.direct
How you determine what your certificate UUID is depends on the host; on a Mac for example, you can run defaults read com.plexapp.plexmediaserver CertificateUUID at the terminal to find it.
If your server has multiple interfaces, each configured with a valid default gateway, and you have Plex Media Server configured to use “Any” interface, you end up with multiple of these (including one for your WAN IP, if remote access is enabled):
192-168-1-100.abcdef1234567890fedcba0987654321.plex.direct
192-168-2-100.abcdef1234567890fedcba0987654321.plex.direct
203-0-113-125.abcdef1234567890fedcba0987654321.plex.direct
And that’s actually another point: In order for Plex to show an interface in the “Preferred network interface” selection, it must have a default gateway configured. That may be why @deersew only saw the one network available. But I think that’s ok, as it’s not generally recommended to have multiple default gateways configured, unless you know what you’re doing.
Thanks @pshanew for the info.
So in theory then, if the PMS will be assigned multiple certificates (or maybe using SAN’s), and you do have both LAN’s configured with a default gateway (I agree you shouldn’t do that) then maybe it should work?
Right. But it’s a wildcard, so there’s only the need for the CN; that leading ‘*’ takes care of all the potential hosts.
I tested this yesterday when I noticed this topic, and indeed it works (at least for local access). I set my Windows test server up on two different VLANs, configured default gateways for both interfaces, and was able to access the server from either.
I didn’t test remote access; I think that could be problematic, at least for Plex’s built-in functionality; because of the way Plex determines the public IP address, I believe it would only see one of them. But with manual port-forwarding and accessing via IP/FQDN, it should work.
Ah ok… That makes sense 
Great to know this, and certainly kudos to you for going to that trouble.
Indeed, this could still be problematic, but would also be interesting to know.
@deersew, what’s your goal? What are your expectations?
Active multihoming at the host level is a real PITA.
How does your host know which connections are “good”? Most of the time when an ISP fails, the interface itself, as well as the IP gateway, are still up and reachable.
Then, remote clients have to be able to find your Plex server. For them to be able to do that, the server needs to be registered with the Plex Cloud.
A Plex server will usually autodiscover its public IP address, based on the active outbound routing path packets take.
You could configure port forwarding on both connections, and then manually configure Plex to register the public IP addresses of both connections. Clients would connect to the IP addresses that were reachable. But I’m not sure if they can be prioritized - clients might not connect to your preferred connection.
Then you’d encounter another issue - asymmetric routing. Return packets don’t “go back” the way they came to you. They’ll take the default route back, and then they’ll be dropped by the first firewall they encounter.
There are a million routers with multi-WAN support. These have a few big advantages - your computer only needs one interface, and the router can do connectivity tests for both WAN interfaces. Those are both huge improvements.
These devices work GREAT for LAN clients and outbound surfing. They just switch NAT between the WAN interfaces.
They still aren’t automagically perfect for a Plex server, because it requires incoming traffic too. Plex still needs to register with the Plex Cloud. This registration needs to be updated if a WAN failover occurs. If you’re patient, Plex will (eventually) notice and refresh the registration.
Or when using a WAN failover router, manually registering both WAN IP addresses with Plex can really shine. Both can be registered simultaneously, although only one is active. Clients will test for which one is reachable at that moment.
On a DrayTek router controlling 2 WANs, this would be resolved using an outbound routing policy that forces all plex traffic out via a chosen WAN. This policy can also be configured to failover and failback.
Therefore almost all other network traffic would auto be auto load balanced, and go out any way it can, but Plex traffic would be more controlled.
The [any brand] router won’t automatically mediate the Plex Cloud registration. Something additional needs be done so that remote clients can find the Plex server at the new address after a WAN failover.
If Plex is using automatic port-mapping and address discovery, just waiting can be enough. Plex will eventually notice the address change.
Some failover routers can temporarily disconnect their LAN interfaces on failover. That’s usually disruptive … but Plex would notice the network interface change and re-register.
Or both WAN addresses can be manually configured in the Plex Media Server and registered with the cloud. Plex clients will probe them and will only connect to the currently-working address.
I see your point…
I guess if this is possible, then it would be the preferred way to go about it.
Unfortunately I don’t have 2 WAN’s so can’t test for this, but would be very interested in doing it to see how things behave.
EDIT: Actually 1 last thought… A script could be written to test for the “preferred” WAN, and if it is not available, it could kill the PMS process and respawn it. That’d work in the event of a failover.
Definitely. And some routers with WAN failover capability can trigger a script on a failover event, or can expose a status to indicate which WAN connection is active.
I think there are some softer ways to encourage Plex to re-check the network and re-register if necessary.
My intuition is that the safest/fastest failover method would be to register both the “active” and “failover” addresses, to avoid interrupting other Plex activity, to remove the dependency on Plex’s address discovery and registration, and to avoid spamming the Plex address discovery services.
Agreed
