Security Alert when adding Plex as a music service in Sonos S1

Server Version#: 1.19.5.3112
Player Version#: SONOS 11.2.1 OS: S1

Hi! A newbie here as of 7/23. I set up PMS on a DS218+ NAS. I do not have a PLEXPASS. For the time being (until I understand better what I am opening up to the outside world) I have set Remote Access to OFF (or NO?). My thinking was, as my use will (for now) be totally within my home network (my side of the router), I shouldn’t need Remote Access enabled.

When I tried to add PLEX as a music service inside the SONOS app (in this case, running on an Android phone), I received the security alert message which was the subject of a lot of questions back in March of 2018, which drove a PMS update I believe. The message says “{ip address} (Ashburn, Virginia, United States) would like to log in to your Plex account”. At this point being security conscience, I stopped, and began researching forum entries on this subject which i found, back in 2018).

So, my questions are:

  1. is this occurring due to my unwillingness to allow Remote Access?
  2. if it is not due to my Remote Access setting, what might be the cause, since a fix was deployed long ago?
  3. forgive my inexperience in networking, but, from a security standpoint, what risk(s) am I taking by enabling Remote Access? Is this access limited to the Plex/Sonos resources necessary to make the system work? or does it make my complete network (home side of the router) visible to others that may have other than good intentions?

Thanks in advance for your help.
Jeff

Hi Jeff,

You’re seeing that connection from Virgina due to the way the Sonos integration works. My understanding is that your Plex server communicates with Sonos via Sonos’ cloud-based API (which causes the Virginia location being reported when you first set up the integration).

It uses this API to send status updates (e.g. where your track is up to, when you’re playing/paused) to Sonos so that it can be displayed in the Sonos app accurately. The actual streaming though, assuming your network is configured correctly, should always be over the LAN, not the WAN.

TL;DR the Virginia connection is normal and expected, and is separate to Remote Access.

Regarding Remote Access security, that’s a very different question. Whenever you’re poking holes in your network to open services up to the outside world, you’re making security vs. convenience tradeoffs. I can’t answer for you whether it’s appropriate for your situation or not. In my case, I’ve got a port-forwarding rule at my router to direct traffic on port 443 to my Plex server on port 32400, and this is fine for my use-case and security requirements.

If you’re worried, you could look at using a VPN for remote access, or consider separating your network out with VLANs, putting the Plex server in a DMZ for example.

Thanks for the response Simon. A couple of follow-up questions.

  1. It sounds like from your statement “when you first set up the integration” that this is a one-time message and won’t be something I have to see every time I go to use the system. is that correct?
  2. One thing I didn’t put in the original message was I did call in to SONOS first, but the tech support person disavowed any responsibility for that message and suggested contacting PLEX. It sounds like she’s wrong. Your explanation sounds completely plausible to me. So I will roll with it.
  3. As far as remote access goes, I’m aware of port-forwarding but have never had to use it.
    I’ll need to spend some time figuring it out to better understand how you benefit from it. In your specific case I’m not sure who or what is generating the traffic towards your port 443 that gets forwarded. In general it sounds like in lieu of turning on Remote Access, you are only opening up one port to forward to PMS. Or do you need to have Remote Access allowed as well?
  4. The VPN scheme is a technique that’s above my head. I haven’t heard of a DMZ with regard to networking, only war!! Ha! I will have to investigate that and see how it protects, and how much more “trouble” it will cause my IT admin (me). Do you have a high-level diagram or a web source that could help me on using this technique?

Your answers have provided food for thought and I appreciate that. It will take me a bit to investigate and understand your approaches to remote access, and I will get back you if I have further questions or issues with a setup should I choose to move forward with PLEX

Thanks
Jeff

Hi Jeff,

Glad I could help. Let me answer your questions point by point!

  1. That’s correct. The only exception is in the Plex Web dashboard, where you may see Virginia as the location when you’re listening via Sonos, for the same reasons I mentioned previously.

  2. When it comes to 3rd party integrations, in my experience Sonos’ position is generally that support is the responsibility of the 3rd party, not Sonos, so I’m not surprised by that response.

  3. Port forwarding is where your router recognises inbound network traffic on a specific port, and based on your defined rules, sends that traffic somewhere internal on your network; in this case your Plex server. By default, Plex listens for traffic on port 32400, so all you need to do is forward inbound traffic on port 32400 to your server’s IP address. If your router supports UPNP (universal plug and play, effectively “auto-negotiated” port forwarding), you may not even need to set up a forward manually. Most consumer modem/routers support this. I use an external port of 443 because my company’s firewall doesn’t allow outbound traffic on port 32400, but it does allow port 443, so I’ve set a custom public port via the Plex settings to allow me to access my music library from the office (using Plexamp on my work PC. There’s no better player for music lovers). Networking gets very complicated, very quickly, so I hope I’ve given you enough of an overview to at least have somewhere to start.

  4. I think, based on what it sounds like you need, setting up a VPN or network segregation in a DMZ is probably overkill. That kind of setup usually requires more “pro” grade networking equipment (read: expensive), and a decent amount of experience and networking know-how. For the sake of answering your question though, the accepted answer on this post gives a very good high-level overview of what a DMZ is and why it can be a useful technique for securing a network that hosts public-facing services: https://security.stackexchange.com/questions/3667/what-is-the-real-function-and-use-of-a-dmz-on-a-network.

For further reading, the official Plex support docs are always a good starting point. This one should help with further understanding how remote access works, and how to configure it:

Let me know how you get on!
Simon

Thanks again Simon. I haven’t had time to look at the article yet but will later today or tomorrow.
I did realize that i forgot one question that may make 3. and 4. moot. My desired use case is totally within my home network behind my router. It sounds like, in the case of a normal non-integrated Plex system, remote access would not be required at all. So, do I even need to worry about remote access? Or, does the fact that I am trying to integrate with SONOS drive a need for remote access. I looked at a lot of posts last week before posting, and I came away with the thought that, once I solved the security message issue, I would be faced with the remote access issue because some other function was not working, and the posts I read may, or may not, have been SONOS related issues, I just don’t recall right now.

So in short, does the SONOS integration drive a need for remote access to be enabled, even though my usage is completely inside my home network?Or can i just forget about remote access?

Jeff

Hi Jeff,

According to the official documentation, remote access is required for Sonos integration:

While the Sonos devices themselves may be on the same network as the server, the actual service that controls the system is in Plex’s cloud infrastructure.

Simon

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