Player and Client on separate Subnets - Remote OK, Within Subnetted LAN not

Plex Media Server
, ,
1

Server Version#: 1.22.2.4282
Player Version#: 5.18.1 (Plex for Samsung)

Hey, I’ve had a look at some similar questions and articles but haven’t thus far found the information I’m after. I work in IT, so will explain as best I can, but there may be Plex-specific terminology or common slang I’m as yet unaware of.

I am running Plex on a Synology NAS. I have a Plex Pass.
Local (direct) connections to the server produce the expected Certificate error. Connections via plex.tv do not - it connects correctly from outside my network using a recognised Certification Authority.

Connections from the same subnet as the server, using the plex.tv method, work. This includes the app built into Samsung Smart TVs. They clearly are pre-programmed to go to plex.tv, register there, generate the 4 digit code, and link to your account. They then presumably use a bit of DNS magic to identify and connect to the Media Server on the local subnet. This is somehow translated into a local, secure connection directly between the Client and Server, ie. the actual streaming traffic does not go over the WAN.

The problem: I have multiple subnets. Routing works fine between these in all other respects. But a TV on a different subnet cannot locate the media library; it knows it exists because plex.tv tells it so; it just can’t locate it because it’s not on the same subnet.

I have tried configuring subnets as “local” under networking. This looks like it’s more about bandwidth restrictions than routing, and doesn’t fix it for me.
I’ve tried subnets that don’t require authorisation.
I’ve tried preferred / required secure connections.
I’ve tried the custom URL - I used a resolvable URL that does connect to the Plex server from anywhere inside my LAN.

It feels to me like the break is in the handoff from plex.tv (that knows about the library) to the client. If on the same subnet it can discover or find it, but there’s a missing step if it’s going via a router.

Might I need some service forwarding rule on the gateway?
Might I need a peculiar internal DNS entry so that the client can resolve the library (however plex.tv identifies it to the client behind the scenes, I’m unsure)

There doesn’t really seem to be any config I can perform on the client.

Maybe it’s thinking it’s remote, and trying to hairpin through the NAT rule on the firewall. Setting the option to “Treat WAN IP As LAN Bandwidth” doesn’t do anything for me.

It could even be a combination of things!

Any insight would be appreciated, cheers

2

Are you using RFC1918 addresses on all of your internal networks, including the PMS and clients?

Does your router/DNS server block “DNS Rebinding”? Some hints here: How to Use Secure Server Connections | Plex Support

When configuring LAN Networks and ... allowed without auth network settings, Plex is really picky about the contents. Spaces aren’t allowed and will break things.

3

I’m using slash notation to describe ordinary subnets in the config, eg 192.168.10.0/24,192.168.20.0/24

It’s a Microsoft DNS server. I’d have to dig into it. There’s also a PiHole in the chain. I’m happy to dig in there, if I can find a more detailed description of how the rebinding is intended to work.

But remember, the same subnet as the server does work; I see cases where turning on remote connectivity breaks people’s LAN connectivity altogether but that’s not happened to me.

Devices on all subnets use the same DNS server and DHCP server. They ultimately share a common path through the firewall to the internet also.

4

That looks fine. It gets angry if there are any spaces, leading or trailing, or any bogus network definitions.

Are your networks all RFC1918 addresses - 10/8, 172.16/12, 192.168/16? Plex really wants them to be.

I don’t think the Microsoft DNS server performs rebinding protection.

I believe the Pi-hole does, whether it’s using dnsmasq or unbound. Dnsmasq is mentioned in that link above. Unbound is similar. Pi-hole, Unbound, and Plex : pihole

5

I’m using a truncated 10. subnet; effectively class A chopped down to subnets the size of a C.

For example:
10.64.10.0/24 (Server, Functional Client)
10.64.30.0/24 (Broken Client)
Both of these hit SVIs on a Layer 3 switch and get kicked to the internet after another routing hop and a firewall.

The PiHole lives on the subnet with the server and the clients that work. I might look harder at that. But just to muddy the waters, the Microsoft DNS server handles all internal DNS and then uses the PiHole as a forwarder. The PiHole effectively thinks it has only one client, which means I don’t get granular analyses from it re. traffic and queries, but I do get the blocking functionality.
Perhaps it is still interfering with a rebind; somehow…

6

It’s good it’s 10/8; use of 100.64/10 and other non-RFC1918 addresses is problematic and becoming too common.

The Pi-hole is providing DNS resolution for external domains. If it blocks the responses for .plex.direct that include private IPs, clients will have problems discovering the Plex server.

An option would be to disable DNS Rebinding Protection for .plex.direct in the Pi-hole.

Another would be to configure the Windows DNS server with a Conditional Forwarder for .plex.direct (to 8.8.8.8 or 1.1.1.1) and bypass the Pi-hole for that domain.

Another approach is to enable NAT loopback, but that would force traffic through the router.

7

Hi,

I was about to sit down and try some of these suggestions; but it’s started working. Frustrating but welcome. Once I found it was working I even reset the app on the TV and re-linked it, just to make sure it was stable, and it seems fine!

If I have further trouble on other devices or subnets, I’ll try these ideas. Thanks for your time and help @Volts

8

Hah! Well, nice.

When you watch something from the previously-problematic network … what appears on the Plex dashboard? Do you see the correct client IP?

9

Yep, sure do.
If it’s some cached DNS thing that breaks again in a week (or whatever its TTL is), there may be bad language.

Next I’ll double check my NAT settings, because at this point any remote session appears to originate from the inside of the firewall. There may not be anything much I can do about that, as you know, it’s being translated.

Most of IT is systems lying to each other to make it all look correct lol

1 Like
10

Yep. Tweaked my NAT rule and remote sessions report that client’s public IP. Everything seems to be working as intended.

1 Like
11

Hahahahaahahah ohhhh that’s painful.

12

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