This simplified network diagram shows that the system can work with complex networks using multiple VLANs.  The system however does not demand such complexity as it will work in open and flat networks as well.

It is important to understand that the users need to be able to reach the weConnect cloud with their devices as they will have to run the application interface in the Chrome browser.

Users also need to be able to address the Display Nodes, i.e. the devices generating the image on the displays in the classrooms. Every time a user mirrors a BYOD device to a display, a connection gets set up between the BYOD and the Display Node.  This can be a direct connection, through VLAN routing or via the more secure method of using a HA Proxy service which weConnect supports.  We suggest to create a virtual IP address for each Display Node which the HA Proxy translates to the real IP address on the Infrastructure LAN. This way, users have no direct access to the Display Nodes. See [KB7719]: Device configuration for details on how this works.

The Display Nodes need to be able to contact the weConnect cloud for normal operation and the weConnect update cloud for updates. This can be done through direct internet connections or via a proxy (represented by the SQUID element in the drawing above). weConnect supports proxies with passwords per location level.  This means that you can have different proxy servers per campus, building and floor level.

Firewall verification chart:

Connect Display Nodes that need to function together in a lecture context (for instance in a collaboration room) as much as possible on the same switch. In that case the unicast network traffic between Display Nodes has no impact on the network. Media streams over the local network are not encrypted except for webRTC streams which are always encrypted, even for local peer to peer connections.