weConnect in different network environments

(please also consult document TDE11298, available under section Downloads at the bottom of this article.

When designing or validating an existing network in view of weConnect deployment the following design criteria have to be taken into account.

The weConnect solution supports the use of a network architecture consisting of securely separated BYOD, services and infrastructure segments.

1. The mobile devices of the end-user are connected to the BYOD parts of the network    
2. The Barco NRC and NCN endpoints are located in the infrastructure segment and are proxied on the services network segment. They have both a private IP (internal infrastructure) and a public IP (services segment) address.
3. The services network houses the proxy services required to secure the access between the different segments.

Barco validates weConnect against the following boilerplate network setup

BYOD network

Example network: 192.168.10.0/24

Characteristics

• Offers Wi-Fi
• Direct internet access
• Routing towards services network
• No routing towards infrastructure network
• MirrorOp sharing from BYOD mobile devices
• Airplay mirroring from BYOD mobile devices to devices in the same BYOD network segment (VLAN).

Infrastructure network

Example network: 192.168.40.0/24

Characteristics

• No direct internet access
• Internet access through http proxy on services network
• Routing towards services network
• No routing towards BYOD network
• NRC/NCN, Sharepod, encoders, ip camera’s

Services network

Example network: 192.168.20.0/24

Characteristics

• 2 services :
  • Haproxy
    http://www.haproxy.org/
    reverse proxy for MirrorOp and thumbnails
  • Squid
    http://www.squid-cache.org/
    forward http proxy for devices to retrieve web content in CEF sources
• Cloud connection for NRC/NCN (Purple)
• Direct internet access
• Routing possible to BYOD and infrastructure network

 There is, however, no necessity to follow this approach or to use the Barco boilerplate setup: the weConnect solution can be configured to fit different common network setups.

General recommendations for a trouble free install and configuration experience

1. The IP address of an NRC/NCN should never change once the unit is paired with the Barco weConnect services. If the address is changed, the unit will have to be removed from the cloud and paired again or at least reconfigured. This can be achieved by either:
   1. Using DHCP MAC address based static IP address assignment for NRC/NCN units (highly recommended).
   2. Switching the NRC/NCN units to use static IP address assignment instead of the default DHCP based assignment. Note: this functionality may be deprecated in future releases. As such we strongly advise against using fixed IP setups.
      
      
2. The BYOD network must have a Fully Qualified Domain Name for the public address of each NRC/NCN. This FQDN will be used to select the NRC or NCN display device to share information with.
   
   Remark that users might have to type the FQDN on mobile phones, we suggest to make them easy to type and as short as possible.  
   
   
3. Communication from the BYOD network segment to the NRC/NCN endpoints on the infrastructure network segment requires service network proxy communication on the following ports:
   1. TCP 3268 :MirrorOp command communication
   2. TCP 8080: MirrorOp data(mirroring) communication
   3. TCP 1688: MirrorOp audio communication
   4. TCP 8082: weConnect thumbnail communication
             
      See the weConnect Security whitepaper for a full list of ports used.
      Remark that as the standard use of Airplay is currently limited to the BYOD network segment there are no demands for Airplay related ports to be open at this moment in time.
      
      
4. The network should provide for reliable non-blocking TCP and UDP communication.
   
   
5. weConnect supports the use of mobile devices using Airplay and Chromecast. Apple Bonjour / DNS-SD/ mDNS multicast type of traffic is bound to a single VLAN. If required weConnect partners may provide solutions or work together with the IT group of the end-user to overcome this limitation.   
   
   
6. The NRC/NCN devices produce and consume RTSP H.264 encoded video streams that are delivered point-to-point. The actual use case/setup of the classroom and lecture will determine the total number of streams that will be used on the network and as such the network load.    
   
   
7. The bandwidth required for each RTSP H.264 stream depends heavily on the type and resolution of the content being transferred. Barco advises to use at least 4Mbit/s for 1080p30 and 10Mbit/s for a 4K@30 stream for the design of the network and the provisioning of network bandwidth.  
   
   
8. The NRC and NCN devices can only be hooked up to a wired network.     
   
   
9. The network must support the use of multicast (mDNS)/Apple Bonjour messages for the discovery of the NRC and NCN devices. This must at least be the case for the infrastructure network during initial setup of the devices and is no longer needed once the devices have been paired with the cloud service.   
        
10. The weConnect solution on the NRC and NCN devices makes use of at least the following mDNS announcements :
    
    
    1. _airplay._tcp     Barconrc-<mac_address>       refers to <nrc_IP:7000 and 7100>
    2. _http._tcp.        Barco nrc-<mac_address>       refers to <nrc_IP:80>
    3. _https._tcp.      Barco nrc-<mac_address>       refers to <nrc_IP:443>
    4. _rtsp._tcp.        Barco nrc-<mac_address>       refers to <nrc_IP:554>
    5. _sftp-ssh._tcp   Barco nrc-<mac_address>       refers to <nrc_IP:22>
    6. _ssh._tcp          Barco nrc-<mac_address>       refers to <nrc_IP:22>
    7. _workstation._tcp        Barc nrc-<mac_address>         refers to <nrc_IP:9>
       
       
11. Wired Ethernet speed should at least be 100Mb/s and preferably 1Gb/s.     
    
    
12. Wireless networks should have sufficient coverage and isolation. They should trigger mobile devices to switch as fast as possible to the access point that can provide for the most effective communication.        
    
    
13. Handover between wireless access points must happen with minimal impact on the communication.       
    
    
14. Wireless networks should be designed for minimal latency by switching information from BYOD devices as fast/locally as possible towards weConnect NRC and NCN endpoints.       
    
    
15. Sending packets to a wireless controller in another campus should be avoided because this builds up unwanted latency and network jitter.
    
    Solutions such as Cisco FlexConnect allow to route packets directly to the NRC/NCN controllers, reducing bandwidth on the connection to the Wireless Lan Controller as well as latency and jitter.
         
16. Barco advises to configure and enable support for QoS, at least in larger and more complex network environments.  Traffic should be handled as CS5/DSCP40 class of traffic. Marking has to be done on network access port level. The NRC/NCN devices do not mark the traffic at present.

Firewall considerations

weConnect uses a standard Linux mechanism to provide partial updates to the display node firmware.  This results in the devices making similar connections over the internet as a regular Debian or Ubuntu Linux machine would do.  Some institutions prevent users from upgrading (a sometimes daily occurrence with Linux systems) by blocking this in the firewall.  It can be hard to detect because it may look like the display nodes can access the proper destination which is the Barco repository URL.  The firewalls which still block the upgrades do this through packet inspection, stopping packets which indicate a device wants to upgrade.

One example of such firewall settings which are enabled by recent FortiOS updates when using Fortinet (Fortigate) solutions results in the following HTML sent back to the display nodes:

<h3>Application Blocked!</h3>
<div class="notice">You have attempted to use an application which is in violation of your internet usage policy.</div>
<div class="app-title">Ubuntu.Update</div>
<div class="app-info">Category: Update</div>
<div class="app-info">URL: http://repository-tst01.edu.barco.cloud/repository/aws-test/BarcoNRC-1.5.0-b64/dists/stretch/InRelease</div>
<div class="app-info">Client IP: 10.5.20.10</div>
<div class="app-info">Server IP: 54.194.230.10</div>
<div class="app-info">User name: </div>
<div class="app-info">Group name: </div>
<div class="app-info">Policy: 5fddd2aa-a1d3-51e7-1a52-c9c88030b862</div>
<div class="app-info">FortiGate Hostname: FGT201E-PRI</div>    </div>
</body>

<h3>Application Blocked!</h3>
<div class="notice">You have attempted to use an application which is in violation of your internet usage policy.</div>
<div class="app-title">Apt-Get</div>
<div class="app-info">Category: Update</div>
<div class="app-info">URL: http://barco-tstone-weconnect-repository.s3-eu-west-1.amazonaws.com:80/BarcoNRC-1.5.0-b64/pool/main/b/barco-meta-packages/barco-vimeti_684%2bpallas47_all.deb?Expires=1518277495&amp;AWSAccessKeyId=AKIAJWE45ESVDOPFB4LQ&amp;Signature=SFXwIUSUp3Yi8t04zS9YkuPcJ8I=</div>
<div class="app-info">Client IP: 10.5.20.19</div>
<div class="app-info">Server IP: 52.218.20.147</div>
<div class="app-info">User name: </div>
<div class="app-info">Group name: </div>
<div class="app-info">Policy: 5fddd2aa-a1d3-51e7-1a52-c9c88030b862</div>
<div class="app-info">FortiGate Hostname: FGT201E-PRI</div>    </div>
</body>

It suffices to disable Ubuntu.update and Apt-get rules in the firewall for the display nodes on the network to allow the units to upgrade.