Explanation, in technical detail, about how to avoid relaying?

Can anyone take a few minutes to explain, in technical detail, how to avoid relaying? More specifically, an explanation of how Plex works behind the scenes to find a “local” Plex server.

I’ve found a few articles[0][1] that talk about what relaying is, but nothing that explains in detail what happens behind the scenes.

Best I can tell, the Plex client will broadcast on a x.x.x.255 address looking for the server. That’s great, but not sufficient.

My networks are strictly segregated. Wireless clients (which Roku uses, on which Plex runs) are on a separate VLAN and network than the Plex server. It’s not going to find the server with a simple broadcast like that.

Before I go down the road of trying to hack together an IGMP relay or multicast routing, are there any alternative solutions as part of Plex itself?

Thanks!

[0] https://support.plex.tv/articles/204604227-why-can-t-the-plex-app-find-or-connect-to-my-plex-media-server/
[1] Why does my direct connection keep failing?

1 Like

https://support.plex.tv/articles/216766168-accessing-a-server-through-relay/

Thanks for the link, but my post was explicitly about how to avoid relaying.

If I have my Plex server and my Roku on the same network, everything works fine. However, that doesn’t work for me.

It is all in there. Follow the links.

The only relevant link on that page is about networking[0], and the only part of that which I think is relevant is the GDM settings. I know it’s a Monday but I can’t see anything in the link you provided that talks about how to avoid relaying, in fact all the content is about how to enable relaying (which I’m wanting to avoid).

I’ve got Remote Access enabled, and LAN networks configured properly.

[0] https://support.plex.tv/articles/200430283-network/

The last 3 paragraphs deal with it.

Having Trouble Enabling Remote Access?

If you experience trouble with getting Remote Access enabled, we have some detailed troubleshooting information available to help narrow down what the particular issue is and then fix it.

Lots of good troubleshooting information, no doubt.

The troubleshooting can help you identify and fix possible problems such as being in a “Double NAT” situation or using Jumbo Frames on your computer.

There’s no double NAT, and definitely no jumbo frames over 802.11a/b/g/ac/n

Our support forums are also an excellent resource for assistance. If you’re having trouble getting Remote Access to work and post in our forums, be sure to include details such as the specific information you gathered while going through the troubleshooting article.

Remote access works fine, relaying works fine. So good in fact that I’m not able to make a direct connection from the Plex client to the Plex server and I think a better understanding of how a Plex client discovers a “local” server would help.

I definitely don’t want to sound unappreciative or ungrateful for the help but I’m not so sure that the link you posted contains technical information about how local server discovery works, direct connections, or how to avoid relayed connections in my scenario given the details I’ve provided about my network setup.

3 Likes

If you client is using a relayed connection, it means it could not reach your server directly.
Switching off the relay connection would result in no connection at all.

Now why the client cannot reach the server directly, can have several reasons:

  1. The server has no public IPv4 address (if your internet service provider only assigns you a public IPv6 address, you cannot use direct Plex remote access at all)
  2. There are issues with the domain name resolution of the .direct TLD. Your server is contacted by clients with its own FQDN (xxx.yyy.plex.direct), which it gets assigned upon server start. Many ISP-provided DNS server mess this up. This can be rectified by using other DNS servers, Google’s for instance (8.8.8.8)
  3. If you also cannot connect directly to your server in your own local network, it may be also have to do with your router. see PMS using wrong IP for a quick test and some things you can try.
  4. If your server is running in a virtualized environment (Docker et al.) it could be indeed a double-NAT issue.
  5. If your local network has more than one router (or any other device which performs NAT [even some PowerLAN bridges do it], it could be a double-NAT issue).
  6. If your router is isolating the ‘wired’ from the ‘wireless’ portion of your local network, your local client can also have difficulty to reach the server directly.

Great information, thanks again for the suggestions. I’ll break them down:

  1. The server has no public IPv4 address (if your internet service provider only assigns you a public IPv6 address, you cannot use direct Plex remote access at all)

The server has appropriate ports forwarded to it from the public IPv4 address. This is what allows relayed connections and other remote clients to connect. Plex remote access works properly.

  1. There are issues with the domain name resolution of the .direct TLD. Your server is contacted by clients with its own FQDN (xxx.yyy.plex.direct), which it gets assigned upon server start. Many ISP-provided DNS server mess this up. This can be rectified by using other DNS servers, Google’s for instance (8.8.8.8)

I have a local nameserver on which bind is configured properly. I see some .direct TLD queries coming from the Plex client:

Dec 31 11:56:07 fw01.home.dtrainor.net named[21367]: client 10.16.16.150#34663 (192-168-200-1.7e87a4bc07f042f098336737be9e0c09.plex.direct): query: 192-168-200-1.7e87a4bc07f042f098336737be9e0c09.plex.direct IN A + (10.16.16.1)
Dec 31 11:56:07 fw01.home.dtrainor.net named[21367]: client 10.16.16.150#43972 (70-176-219-102.7e87a4bc07f042f098336737be9e0c09.plex.direct): query: 70-176-219-102.7e87a4bc07f042f098336737be9e0c09.plex.direct IN A + (10.16.16.1)
Dec 31 11:56:07 fw01.home.dtrainor.net named[21367]: client 10.16.16.150#56094 (10-10-50-200.d4c62cb492c04767905eff0876ea7edf.plex.direct): query: 10-10-50-200.d4c62cb492c04767905eff0876ea7edf.plex.direct IN A + (10.16.16.1)
Dec 31 11:56:07 fw01.home.dtrainor.net named[21367]: client 10.16.16.150#55962 (192-168-0-217.e89f4f93243b4c27977f0e48e7a94e17.plex.direct): query: 192-168-0-217.e89f4f93243b4c27977f0e48e7a94e17.plex.direct IN A + (10.16.16.1)
Dec 31 11:56:07 fw01.home.dtrainor.net named[21367]: client 10.16.16.150#56927 (72-222-200-30.e89f4f93243b4c27977f0e48e7a94e17.plex.direct): query: 72-222-200-30.e89f4f93243b4c27977f0e48e7a94e17.plex.direct IN A + (10.16.16.1)
Dec 31 11:56:17 fw01.home.dtrainor.net named[21367]: client 10.16.16.150#48530 (184-105-148-96.7e87a4bc07f042f098336737be9e0c09.plex.direct): query: 184-105-148-96.7e87a4bc07f042f098336737be9e0c09.plex.direct IN A + (10.16.16.1)
Dec 31 11:56:17 fw01.home.dtrainor.net named[21367]: client 10.16.16.150#55371 (192-168-99-10.f6b5afa0e8c346f3902766d46302317b.plex.direct): query: 192-168-99-10.f6b5afa0e8c346f3902766d46302317b.plex.direct IN A + (10.16.16.1)

I’ve seen your other replies[0][1] on the forum that describe the .direct TLD being incorrectly configured and while that’s great, it’s the technical detail of such that I’m interested in learning more about. None of the hostnames on the .direct TLD that the Plex client queries, are A RRs that represent anything on my network, with the exception of the external IPv4 address. Even then, that does not help, because the only reason that would be used is for relayed connections which I’m trying to avoid in the first place. Even if I had a specific zone configured for the “plex.direct” domain, it looks as if the Plex client wouldn’t even be using the correct server address because it looks like it’s querying for made-up addresses (with the exception of the external IPv4 address.

  1. If you also cannot connect directly to your server in your own local network, it may be also have to do with your router. see PMS using wrong IP for a quick test and some things you can try.

Properly configuring my router is the exact reason I’m making this post. I’m looking for detailed information on what the proper configuration is to make sure my configuration is suitable. I believe it to be, though I need detailed information on discovery to confirm this.

I can connect directly on the same network on which the Plex server is located. I cannot connect directly to the Plex server when the connection comes from another VLAN on a different RFC1918 IPv4 address space. My firewall and router are configured sufficiently to forward this traffic.

  1. If your server is running in a virtualized environment (Docker et al.) it could be indeed a double-NAT issue.

Baremetal, as indicated earlier double-nat is not the issue here. The issue is Plex behaving unexpectedly.

  1. If your local network has more than one router (or any other device which performs NAT [even some PowerLAN bridges do it], it could be a double-NAT issue).

I have no indication that NAT, or even double-NAT, are the culprits.

  1. If your router is isolating the ‘wired’ from the ‘wireless’ portion of your local network, your local client can also have difficulty to reach the server directly.

I know :slight_smile: that’s why I’m making this post about the technical details of how local discovery works…

[0] Fully accessible but indirect connection
[1] Why does my direct connection keep failing? - #3 by plexpants

We ignore ethernet adapters with name starting with v - you may need to rename the adapters if they have names starting with v

Well. That’s not great. The interfaces that the Plex server is supposed to listen on are named “vlan10”, “vlan20” etc.

[0] Bind to IP address - #10 by jsloan117

No. For relayed access, no port forwarding is necessary. Therefore it is not conclusive that remote access is functional if you can access your server remotely. Because it could be only available due to the relay connection.

Sorry, that is above my grade of knowledge. I can only recommend you to read
https://support.plex.tv/articles/206225077-how-to-use-secure-server-connections/
and also

which have more in-depth explanations.

It’s working, now that my interfaces are renamed to “lan10” etc from “vlan10” etc.

Really disappointed that it came down to this. That’s not what I wanted to have to do to “fix” this.

1 Like

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