Connecting EOS board to the internet

I've heard a variety of anecdotes around here, but never really an official sentiment - is it safe to connect EOS boards to the internet? As far as I can tell, it really shouldn't have an effect on anything, since the board shouldn't be trying to connect to the internet to begin with, but I'm not sure if this is actually the case. Also, I'm purely asking about giving the board internet access - I understand the importance of (properly configured) firewalls and flow control and whatnot on networks, and we should be able to handle setting all that up correctly.

Parents
  • Just to add, that beyond the "internet" is basically the question of what all should a lighting console be connected to. For most of us, it is going to be an isolated network just for lighting, but of course, as of the last 6 years or so there has been 2 network ports available on even the consoles. So for that, often what I think people do is they've got an isolated lighting control network (sACN, Net2/Net3, ArtNet, etc) for control over production rig equipment -- that should never actually route or connect with any other network (e.g. no network gateway)... And then on the other hand, there might be a second network that is used a bit more broadly for console controls to other production equipment (OSC, RFR, focus apps, etc), but again, that generally should be an isolated network.

    Here is the thing to remember, almost all production lighting equipment carries no authentication or security measures. If you're connected to that network then you can control said systems. For example, if the console and sACN is on the same building network (that provides internet access), but some music director (non-tech) downloads some music software that can output sACN, they can unknowingly start contributing to the output to the rig. When I go into other venues, you'd be surprised how often on the guest wireless network I can use iRFR and now control the lighting console. 

    The last point about isolation is network congestion -- we want to avoid co-mingling of different real-time network protocols on the same logical (or sometimes even logical -- vlan) networks. For example, everything is going well, and then al of the sudden, without your knowledge, a security contractor comes and installs a bunch of streaming video cameras, that are all nice 4k NDI based cameras, on the same network as your lighting network. Regardless of the "internet" itself question, that can have a meaningful impact on your ability to control your lighting rig if you used network DMX like sACN or ArtNet -- where a 10/100 wired network was just fine for your two universes, the video cameras will crush the network and you'll just walk in one day to a rig that has random control issues.

    All that to say, beyond the question of actual connecting to the internet itself, there is also a network stability & security question of even within the 4-walls of the building. 

  • Yeah, those are all good points. Currently, we're using a VLAN for our audio and streaming, which is isolated from the rest of the network (only a few approved MAC addresses on the student and faculty VLANs here are able to access the production VLAN, and none of those rules apply to the guest VLAN so a theoretical bad actor would have to do more than just spoof the MAC), and we're basically just debating over how to connect our lighting console to that, the idea being that, with everything connected to the same network, accessing things for remote control will be easier (with the way its set up now, I can just whip out my phone and connect right to the mixer without having to switch networks, and it would be nice to have that same capability for lighting). Also, having everything connected together like that would allow for us to do things like trigger lighting cues in sync with sound cues by sending OSC from the sound person's QLab, or doing some TouchDesigner shenanigans to sync up lights with projections (this is where the internet really starts to come into play - we use the same computer for projections as we do for streaming, and having to switch this between networks is pretty inconvenient). We also don't use sACN at the moment, but if we switched to that I think we'd either just run a dedicated network for it with the board's second port like you suggested, or route that traffic through a separate VLAN which only the lighting board can access (and which has some minimum amount of bandwidth allocated to it probably).

    The main question that's left is just what should the board be able to access. If needed, we can probably just put a firewall rule in place to block it from accessing the internet, but if that isn't needed (which I'd imagine it's not), it would be nice to just keep our network configuration a little bit simpler.

Reply
  • Yeah, those are all good points. Currently, we're using a VLAN for our audio and streaming, which is isolated from the rest of the network (only a few approved MAC addresses on the student and faculty VLANs here are able to access the production VLAN, and none of those rules apply to the guest VLAN so a theoretical bad actor would have to do more than just spoof the MAC), and we're basically just debating over how to connect our lighting console to that, the idea being that, with everything connected to the same network, accessing things for remote control will be easier (with the way its set up now, I can just whip out my phone and connect right to the mixer without having to switch networks, and it would be nice to have that same capability for lighting). Also, having everything connected together like that would allow for us to do things like trigger lighting cues in sync with sound cues by sending OSC from the sound person's QLab, or doing some TouchDesigner shenanigans to sync up lights with projections (this is where the internet really starts to come into play - we use the same computer for projections as we do for streaming, and having to switch this between networks is pretty inconvenient). We also don't use sACN at the moment, but if we switched to that I think we'd either just run a dedicated network for it with the board's second port like you suggested, or route that traffic through a separate VLAN which only the lighting board can access (and which has some minimum amount of bandwidth allocated to it probably).

    The main question that's left is just what should the board be able to access. If needed, we can probably just put a firewall rule in place to block it from accessing the internet, but if that isn't needed (which I'd imagine it's not), it would be nice to just keep our network configuration a little bit simpler.

Children
No Data
Related