In order for the 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 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  <>.  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.   

Proxy Exceptions

Please allow Unauthenticated traffic for the following addresses.  ie. No Packet Inspection. (if using Chromebooks)

These addresses are to allow the client application to communicate with the server.
This is required so that the modules can be downloaded and updated.     ports 3478 / 443 (UDP, STUN, TURN, HTTPS)

North American Customers Only 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.

Firewall Rules: 

To view your clients from outside of your network the following port is required allowed through your firewall.

Port: 3478

Direction: Outbound

Protocol: UDP

How Does the senso client route traffic?

The senso client uses 3 methods for making a secure connection between the client and the console. 


The senso client tries to establish a direct peer to peer connection internally on your network.  This allows your network traffic to stay local and only use your broadband line to establish the initial connection between client and the console. In theory this method should always work if you are on the same VLAN, Switch, Access Point.  If the senso client is unable to make a direct peer connection then it tries Method 2. 


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 - 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.

Port: 0-65535

Direction: Outbound

Destination: (ANY)  to limit the destinations, please specify the IP address, network (host) or Internet (srflx).  

Protocol: UDP


The senso client tries to establish a connection by using the senso relay servers.    

Port: 49152-65535

Direction: Outbound


Destination: (North American Customers Only)

Protocol: UDP