Plex 1.15 on Synology only listens on IPv6

Server Version#: 1.15.1.710

Not sure from which version I updated, but I updated to the current PlexPass version on my Synology last night.

Now the PMS Web interface is no longer reachable at the IPv4 address of the DS (i.e. 192.178.1.75:32400/web just gives a connection timeout)

At first I thought it didn’t properly start the web daemon and just restarted both Plex and the DS to no avail.

I know my way around on a linux machine, so I did the usual diagnosis:
Check ps and htop for the Plex processes, everything looks fine.
Then I wanted to find out if for some reason the web port was blocked maybe by the old version still running or some other strange situation.

So I called my good friend netstat to the rescue:
netstat -tulpn

And there I found something strange:

tcp        0      0 127.0.0.1:32600         0.0.0.0:*               LISTEN      5106/Plex Tuner Ser
tcp        0      0 127.0.0.1:32401         0.0.0.0:*               LISTEN      4351/Plex Media Ser
tcp        0      0 127.0.0.1:50006         0.0.0.0:*               LISTEN      4539/Plex Plug-in [
tcp6       0      0 :::32400                :::*                    LISTEN      4351/Plex Media Ser
udp        0      0 172.17.0.1:47974        0.0.0.0:*                           4351/Plex Media Ser
udp        0      0 172.17.0.1:41996        0.0.0.0:*                           4351/Plex Media Ser
udp        0      0 192.168.178.17:36019    0.0.0.0:*                           4351/Plex Media Ser
udp        0      0 0.0.0.0:32410           0.0.0.0:*                           4351/Plex Media Ser
udp        0      0 0.0.0.0:32412           0.0.0.0:*                           4351/Plex Media Ser
udp        0      0 0.0.0.0:32413           0.0.0.0:*                           4351/Plex Media Ser
udp        0      0 0.0.0.0:32414           0.0.0.0:*                           4351/Plex Media Ser
udp        0      0 127.0.0.1:42806         0.0.0.0:*                           4351/Plex Media Ser
udp        0      0 0.0.0.0:1901            0.0.0.0:*                           4351/Plex Media Ser
udp        0      0 127.0.0.1:36902         0.0.0.0:*                           4351/Plex Media Ser
udp        0      0 192.168.178.17:47147    0.0.0.0:*                           4351/Plex Media Ser
udp        0      0 192.168.178.17:43055    0.0.0.0:*                           4351/Plex Media Ser
udp        0      0 172.17.0.1:59908        0.0.0.0:*                           4351/Plex Media Ser

As you will no doubt notice: Plex only listens on tcp6 for port 32400, but not on tcp.
I know, depending on netstat and the kernel version this would be perfectly normal to only show tcp6 and listen on bothe IPv4 and IPv6, but DSM is different here: It still lists IPv4 and IPv6 sockets seperately.

And oh wonder: connecting to the IPv6 address on port 32400 reveals the well-known Plex webinterface.

Why does it do that and how can I set Plex to listen on IPv4 as well? Listening on IPv4 only would be fine as well. I don’t need IPv6 on my LAN yet.

Tried, but doesn’t seem to have any effect at all.

That doesn’t work for me.
The NAS must be able to talk IPv6 for other unrelated services. (And no using NAT for that isn’t an option)
Again: I’m fine with Plex being IPv4-only. Don’t use it remotely anyways and both my LAN and the Internet connection are full-blown dual-stack.

That’s not gonna help if Plex doesn’t listen on IPv4.

Plex listens and primarily operates on IPv4.
To be specific, none of the metadata is IPv6

Is your default set as V4 or V6?

Plex SHOULD listen and primarily operate on IPv4.
In this case it primarily listens on IPv6 for so far unknown reasons. (The previous version was fine)

My default what?
Plex only binds to bond0 / 192.168.178
grafik

and I disabled the IPv6 support in Plex.
grafik

Still netstat only gives a tcp6 link for PMS:

(19:49 admin@bene-ds713 ~) > sudo netstat -tulpn | grep 32400
Password:
tcp6       0      0 :::32400                :::*                    LISTEN      4351/Plex Media Ser

What you show makes no sense to me.

I have those versions here on my Synology. I do not see what you do.

[~] # netstat -an | grep 32400
tcp        0      0 0.0.0.0:32400           0.0.0.0:*               LISTEN      
tcp        0      0 192.168.0.21:34620      192.168.0.71:32400      ESTABLISHED 
tcp        0      0 192.168.0.21:40940      192.168.0.98:32400      ESTABLISHED 
[~] # 

Thanks, I know it doesn’t make sense.
The question is what might cause it to bind to IPv6 only despite explicitly disabling the IPv6 feature :man_shrugging:

The only thing which would cause it to bind to IPv6 is if 32400/tcp4 is already bound. Such a binding would happen at the DSM level.

That would be very strange, but I’ll try restarting the DS once more and will try to watch the 32400 port while it boots up this time.

Can you afford to stop the other services long enough to diagnose this properly?

I tried accessing IPv4 and port 32400 on different machines in the LAN to no avail.
When accessing the NAS IPv6 address everything is fine, though. (Library is browseable, I can edit stuff, play stuff)
That shouldn’t work if the connection to the Plex servers was broken or the client couldn’t find the server at all, right?

Yeah, no problem. The NAS only needs to serve public stuff during work hours / when I’m not at home. It’s 9pm over here now and I’m obviously at home, so noone needs to use the VPN or access any file services from outside.

whoooops.

VPN?

PMS runs along side a VPN on the Syno?

Yeah, and it did so for the last 6 months without any problems.
The IPv6 problem only appeared after the last Plex update I installed. (And I believe this wasn’t a minor update in the 1.15 series, but I only yesterday did the jump from 1.14 to 1.15)
I’m only a software developer by trade, but I had lots of training in network setups in university, so I know how to set these things up and find problems if I got enough time…

Yeah, adding a second gateway is an easy option, but adjusting the routing table grants you a lot finer control over things.
For example, the problems with app.plex.tv mentioned in the addendum are caused by that second gateway and not having set up distinct routes for the VPN traffic.

The VPN in use here isn’t supposed to handle all Internet traffic, but only grant access to a limited subnet in both directions. (i.e. I need access to company server in the office, and my office needs access to the DS for offsite backup)
Running a small IT company here, so I have at least some background to help with that stuff.

I’ll turn everything off and then start it up again one by one to see if Plex decides at some point to only use IPv6 right from the start or if it’s forced to switch there for some reason.

I don’t think the IPv6-only problem is related to the VPN. That would be way too strange a problem even for VPN messups.

The biggest problem anyone using a VPN faces is “Plex isn’t surgical”. It sets itself up as if it owns the LAN. We’ve asked for it to be, only sending from one specific IP address (the selected one) but it doesn’t work that way. The only thing which got ‘moved’ is the HTTP server. That doesn’t buy anything really. The HTTP listens on that port but responds on INADDR_ANY

Just a thought: are you using the “Application Portal” option in DSM to reverse proxy the connection to PMS using the Synology’s SSL cert? That could potentially stop PMS from binding to 32400 :thinking:

Failing that, try turning it off and on again :joy:
Seriously, though: uninstall PMS and reinstall it. Your libraries and configuration will be preserved. I’ve done it a few times on a Synology as it’s the only way to regress from a beta build to a production one if the beta’s badly broken. A reinstall may fix things.

(Also, fwiw, I run a VPN server on my Syno with dual-stack IPv4/IPv6 and PMS runs fine)

1 Like

@gary_parker

Synology’s app will do it? Interesting. I need to try that and learn more (then keep good notes)
PS: Glad I don’t remove the Plex share? :wink:

2 Likes

I certainly am glad! I got to a point with a beta where I had so much trouble with it I thought I’d bite the bullet and reinstall from scratch as Syno app manager won’t let you install older versions (a helpful “feature” on QNAP!) and was very pleasantly surprised when I found everything still in place upon reinstalling PMS :clap:t2::clap:t2::clap:t2:

I tried restarting / reinstalling Plex without any difference.
Since it’s nearing the end of the day and I won’t be around over the weekend, I thought I might just as well try the brutal method and power-cycled the DS. And there you go: everything works as expected (somewhat, read on to see why I’m now more puzzled than I was when things didn’t work)

Now this is really strange: The netstat output looks just the same, but it works on IPv4.
This isn’t strange per se: It’s actually the way you would expect things on a “normal” linux server as IPv6-enabled services should be able to handle IPv4 just the same and linux will only create a TCP6 socket mapping all the IPv4 stuff internally to the same socket.

What’s strange though is why this has puzzled me from the beginning:
Most, if not all, other DSM services like Apache for the WebStation, nginx for the internal port 5000/5001 webserver and even the docker daemon have separate tcp and tcp6 listings in netstat.
I was 100% sure that I’d need a tcp and a tcp6 listing for it to work.

Strange enough: As far as diagnosing this with netstat goes, it’s looking the same now vs a few hours ago. Back then I can 100% confirm I couldn’t connect from my Desktop or my Laptop computer to the IPv4 address and the 32400 port of Plex, while I could perfectly see the webif on the IPv6 address.

I’m now more puzzled than before, but at least my services seem to be healthy again.

If anyone can come up with a reason or something I might’ve accidentally changed that required a full restart of the whole machine, I’d be glad to hear about it.

I’d like to thank you all for the suggestions and pointing me at various locations to look through.
Even though, I’m not sure if any of that helped or if it’s just magic, thanks for the effort.

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