What risks, been doing it for 6/7 years. Done correctly nothing wrong with it. Your more likely to get hacked via a dodgy email than an open port for ARC or Plex.
Well, there’s the whole Lastpass compromise. Plex was the vector, however it hadn’t been updated and secured properly in the first place. This came as a result of enabling remote access. So while I generally agree with you, it does happen and the consequences are extreme.
Reference LastPass Hack: Engineer's Failure to Update Plex Software Led to Massive Data Breach
I like the reference to the LastPass attack. At the same time, that was an outside-in attack targeted at high-value individuals. There’s another category of attack related to the devices we willingly bring into our home networks where we vulnerable to malicious firmware. I don’t consider this paranoia.
I do open the ARC port. I use ARC and it’s worth it for me to open it. It’s actually the only port I open. It’s mapped directly to my Roon box, which is on a dedicated vlan. That vlan is pretty well protected by firewall rules. You can’t get out of it, and you can’t do anything administrative on my UniFi UDM Pro. It’s not perfect, but it’s a lot better than not having segmentation and isolation.
Personally, I’d rather live with the issues introduced by the use of the vlan than live without it. This is, by the way, one of the reasons that I walked away from the dual-homed Ubuntu box. Setting it up that way meant that if that box got owned, it could act as a bridge to my primary network, and I didn’t want that to be possible.
1 Like
@JohnSmith_roon I think as other have said, put your entertainment devices on the same vlan, then allow your phone to talk into that vlan but not the other way.
This is how I currently have my setup: all roku’s, my Roon, AVR’s, wifi speakers, last remaining OPPO I have, etc, are all on an ENTertainment vlan that cannot talk to any other subnets - controlled by pfsense firewall. However, my vlan for my phones can talk to my ENT vlan.
So Roon can find everything it needs in its own little world, while I can control it and not have to be on that vlan - I can even play to my phone when on or off that vlan.
hope this helps.
1 Like
Good stuff in there. I would like to see 2FA with ARC like Plex does for starters. Then, if I were to get my druthers, I would ask Roon to give out 2 licenses for Roon when running ARC so that I could mirror my core network Roon DB onto a “dirty” Roon that would be DNATed (port forwarded) from the Internet.
I have a good deal of engineering to do before I’ll expose my Roon setup to the Internet just yet.
That’s the part that I can’t get to work reliably, with Roon. (It works with Roon ARC).
I have to put my phone in the Roon VLAN (ENT for you) to get the server to make the phone available as an audio endpoint. Once that happens, I can switch the phone back to my regular VLAN, and the Roon server will still play to the phone. But if I stop playing for a while, I have to switch back to the Roon VLAN to get the server to enable the phone again.
You can activate 2fa on you Roon account now. This is then required by ARC as it all uses the SSO. For some reason this was never announced but was found by someone on their account into page.
2 Likes
Great to know. This thread has been the most informative I’ve been in for a while. Not sure why they didn’t announce 2FA. Maybe they did and we missed it?
I don’t think they did, it was spotted in early access during SSO testing.
@David_Rothenberger - David, so how is your firewall setup. I am using pfsense and I allow my LAN to talk to my ENT vlan but on my ENT vlan I block any traffic trying to initiate to the other vlans.
My wired devices are on the vlan because the switch they plug into only allows ENT vlan traffic - they implicitly can only get ENT vlan dhcp or dhcp reservations.
My unifi has a network setup as ENT vlan and its associated with a wifi network. of course the unifi access points plug into the switch and that port is open to whichever vlans the AP supports.
In this setup I can use my Roon Client iOS app, my DENON iOS app, my MARANTZ app and my HEOS app while on the main LAN network.
The first thing I would test via a pc is if you can even ping anything on the ENT vlan while on your main LAN network. Start with seeing if you can talk to the static IP you assigned on the firewall for that network interface.
The two vlans in question are set up the same as yours. I have connectivity from my main vlan to the Roon vlan. I can contact the Roon server from the main vlan without any issues.
The only problem I have is with my Android phone on the main VLAN being recognized as an endpoint. And now that I think about it, my PC on the main VLAN does not have that problem, so maybe this is a problem with my Unifi AP configuration or something.
It’s not your Wi-Fi. The pc remotes seem to do something different that does allow them to be seen across vlans. But this isn’t all the time, mine seem to pop up after a while and these are all wired and sometimes they don’t show at all. But I tried them on wireless too and they still showed up. Roon Ready or phones don’t and won’t show up unless on same vlan wired or wireless. This makes me think these use something different for discovery of the audio zones. UDP multicasts which are also used for DNLA/UPnP renderers also wont pass over vlans without configuring a UDP proxy of some sort, UniFi do not have this ability in their own firewall/software.
hey, remind me (if I may ask) how many vlans/wireless networks is too many from a performance perspective… is this a function of UDM-Pro / USG / UDM processor, or is it related to switch processor? RIght now I have an iOT, guest, and “main (corporate)” vLAN and a corresponding WiFi for each.
I’ve never bothered (yet) to follow your lead on this one, but it seems to me that this might be worth doing since I don’t listen on any of my controllers as endpoints. A few questions:
- Do you have a “per-controller” inbound firewall rule for each device? Or do you have a blanket “anything on my corporate can go inbound to my Roon/Sonos network on all ports” or is it more nuanced than that?
- When you were trying to get UDP multicast to traverse vLANs using Aaron’s brilliant udp-proxy-2020 did this approach make things any more difficult within your network (I’m guessing you didn’t bother, because you used your smart dual-NIC approach)? Wondering if it’s going to make my ultimate project of getting site-to-site VPN’ed single-core more complex, but only because I’m so network unclever. (for your reading pleasure, I’m getting closer and closer to just buckling and purchasing a used UDM-Pro for my second home because I know how to get udp-proxy-2020 going on a UDM-Pro, I just can’t get it going on my USG-Pro3).
- Are there any other downsides to separate “sound VLAN” for your use case? Do I have to put my AppleTVs etc on that VLAN too if I want to play over them (assume so) and does that start causing other issues with interoperability between your apple ecosystem stuff (or are you all Chromecast etc)?
Many thanks. Last time we discussed I got a ways down this road and then chickened and got distracted by trying to get two-home going. Now I know how I have to solve it (I have UDP multicast working in one direction “from the UDM Pro end” and just need to get another UDM Pro in order to get it going in the other direction. Totally possible I go down this path and have a separate vlan in each home for audio and that makes the 2-home 1-core solution more complicated and then I get frustrated so need to revert. Discretion, valor and all that. Thanks.
My semi-informed answer to this is that we are using enterprise gear for our homes. I seriously doubt any of us will hit an inflection point where the number of subnets and firewall rules we have will stress the capabilities of this infrastructure. I think we all know that UDMs run out of gas on fast internet connections with all of the intrusion detection/malware stuff enabled, but I don’t the same will be true of anything we do related to inter-vlan traffic management.
I sort of vaguely recall that your primary switch is an L3 switch. Mine is L2. In my setup, everything is cabled to my switch and my switch is connected to my UDM-Pro with a gigabit connection (fiber but I don’t think there’s a real benefit to that) because that’s what my switch supports. This means that all cross-vlan traffic is making it up to my UDM-Pro. This is aesthetically irritating but, frankly, I don’t think there’s any real-world impact to this. We’re just home users.
I don’t bother with bonding ports and other performance-oriented tricks. I’ve been doing this stuff for decades and I sometimes opt for staying on the “simple” side of the point of diminishing returns. I may buy an L3 switch at some point but that would to increase the number of ports I have as well as to increase the PoE budget of the switch since I’m actually exceeding its stated max (cameras, in-wall access points, a couple of small switches that are powered from PoE ports on in-wall access points).
I actually never tried it - we talked about it for multi-home use but I didn’t go very far down that path. I’m down to a single home now, so don’t need it for that. But…I did just move my core back to a Docker container on my NAS. Some folks on this forum figured out how to run Roon on a separate subnet in a Docker container on Synology. So I powered down my NUC/ROCK and went back to the dark side of running on a NAS. And that got me wondering if there might be some clever way of actually running some sort of UDP proxy inside of a container on Synology. (or on any multi-homed linux device). Seems like this might be possible and would solve the issues @Simon_Arnold3, me, and others have with some clients not showing up when Roon is on a vlan.
Our personal devices are all Apple. Apple stuff works fine across vlans as long as you have the mDNS stuff enabled and you create the specific firewall rules you need. I decided to trust the Apple stuff and all of it, including the Apple TVs, are on my primary network. I poke some specific holes in the firewall to make all of this work. It’s not hard to do.
I like the approach I have in place and I live with the tradeoffs. Most stuff just works. I have sketchy stuff on my IoT network and while the setup isn’t perfect, it’s definitely better than just allowing everything to talk to everything.
Question back for you - Am I right about you being on an L3 switch? Was that turnkey for you? Do you see benefits from it?
Oh and can you share a link to the UDP proxy you’re using?
Never made it to L3. Talked about it ad nauseum, then didn’t pull the trigger. Rationale for doing it was to get the full 2GB I have at home through to endpoints. And the reason I didn’t bother was that I realized that even my home office has some funky cabling that while usually capable of 1gb occasionally gets stuck at 100MB for a week at a time, so the backplane didn’t really matter. And that I was chasing my tail for a stupid reason, and didn’t care enough to repull cable so I couldn’t be bothered with an L3 switch.
This is the massive thread where Aaron Turner explains his project, what he did, and then lots of n00■■ like me ask him for help. Actually he’s even more helpful once you get into it if you go to his github page for the project udp-proxy-2020.
Interesting! He’s got a Docker container version available. Might work on a dual-homed NAS like mine. I may play with it.
I believe the max number of SSIDs that UI recommends is 4 but the actual limit is 8 on most APs. I don’t believe I’ve ever seen a VLAN limit mentioned.
Thanks. I asked ChatGPT and it suggested several reasons why speed could suffer with lots of SSIDs, and pointed out that I might not need an extra SSID for my iot but might achieve the same goal by putting my wireless iot devices on my guest network with a separate VLAN. Thanks to you and the borg.
The problem with that is the whole point of a guest network is to completely isolate it from not only other VLANs/subnets but other devices on the guest SSID. That’s not really an option with IoT since you need to be able to setup and manage devices with mfg apps and then need them discoverable and accessible by other devices (like Home Assistant) on your network.
UI is close to releasing a network app update that will allow VLANs to be set based on SSID password entered so you might be able to reduce your number of SSIDs that way. I won’t be able to because I also use the block broadcast/multicast feature on each of my SSIDs with a list of devices unique to each SSID that are allowed to send such traffic.
In my case I have 4 SSIDs per AP. 3 are global (guest on 5Ghz only, 5Ghz only and 6Ghz only). The other is unique to the AP (2.4Ghz only). I found I had to do it this way because there just aren’t enough devices (especially IoT devices) that roam properly. Even now I have 2 or 3 IoT devices on my 5Ghz only SSID that sometimes need help finding the best/closest AP. I can’t combine the 5Ghz only SSID with the 6Ghz only SSID because I have devices on the 5Ghz only SSID that don’t like WPA3.
The Network release with this feature went to “Official” today. I haven’t played with it yet but I plan to use it to eliminate one or more wireless networks.
@glc650 - I assume you’re aware of the “Lock to Access Point” feature but in case you aren’t:
I use this feature for devices that are in a fixed location but make poor choices about access point connectivity.