In order for the senso.cloud client to operate correctly it might be necessary to add some rules to your firewall and or proxy.
Detecting Proxy Settings
- If you are using unauthenticated transparent filtering (i.e. no client proxy setting). The Senso client will work as expected. Please continue to Firewall section below.
- If you are not using a transparent proxy then the senso.cloud client will detect the proxy setting for the logged on user from Internet Explorer. It will then populate the SensoClient.exe.config file with these details under the section <system.net>. If you do not have a SYSTEM proxy set then the clients won't appear in the senso portal until a user logs on. In this scenario, if the user logs off you will still see the device at the Ctrl-Alt-Del (SYSTEM user) window until the device is restarted then it will no longer appear in the senso console unless a user logs on again.
- To override the above scenario please see How to Fix the Proxy Settings.
- If you use User Based Filtering ie. If you authenticate the user either via a captive portal or via NTLM. In theory this should work once the user has authenticated as the senso client tries to make a secure connect to the senso servers at random intervals.
Please allow Unauthenticated traffic for the following addresses. ie. No Packet Inspection.
These addresses are to allow the client application to communicate with the senso.cloud server.
This is required so that the modules can be downloaded and updated.
senso-sturn-northeu.cloudapp.net ports 3478 / 443 (UDP, STUN, TURN, HTTPS)
North American Customer Only
senso-sturn-centralusa.cloudapp.net ports 3478 / 443 ( UDP, STUN, TURN, HTTPS)
This address helps build connections for Live Thumbnails and module feedback
Note: It is actually STUN/TURN over UDP but some proxies may see it as HTTPS traffic.
To view your clients from outside of your network the following port is required allowed through your firewall.
How Does the senso client route traffic?
The senso client uses 3 methods for making a secure connection between the client and the console.
Where possible WebRTC will attempt to connect using host candidates, which will keep traffic local to the network. In scenarios where this is not possible; restrictive VLANs, guest networks, over the Internet, etc... then it will attempt to connect using server reflexive candidates. To do this WebRTC makes use of UDP hole punching as a method of establishing connections between clients and as such outbound UDP ports are required to be accessible, if they are not then server reflexive candidates will fail to connect and relay candidates will be attempted. However, as these are routed through the TURN server (Method 3) they will be much slower.
Please see RFC 5389 for a detailed explanation of the STUN protocol - https://tools.ietf.org/html/rfc5389. This protocol is used with SIP as well, so if you have an VoIP system, you may already have exclusions in place for other STUN servers.
Destination: (ANY) to limit the destinations, please specify the IP address, network (host) or Internet (srflx).
The senso client tries to establish a connection by using the senso relay servers.
Destination: senso-sturn-centralusa.cloudapp.net (North American Customer Only)