Axence Cloud Relay lets you securely connect Axence ConnectPro components (the server, Agents installed on monitored workstations, and remote management consoles) with no maintenance required. The only requirement is internet access.
First connection
On first launch after installation (except for offline installation without network access), the ConnectPro server connects to Axence Account to verify that the license/subscription is valid. This also happens when the server is updated to a version that includes Axence Cloud Relay.
Each server instance has a unique identifier. It is used to verify credentials, distribute Agents and set up connections within the virtual network. The server sends this identifier to Axence Account. In response, it receives a signed certificate (used for authentication) and the DNS address of the cloud servers. Axence Account stores the link between the license/subscription and the identifier.
Certificates
The organization, the server instance, and each Agent and console all hold signed certificates. These certificates are linked to one another and form a chain of trust, which allows precise access control at every level. Revoking a certificate at any level prevents the entire chain of trust from connecting to the cloud services.
Connection
With Axence Cloud Relay, you no longer need to specify in ConnectPro the address of the server you are connecting to. The Agent application either uses a list of available local addresses or sets up a suitable connection based on the credentials it has received. The console works the same way. It uses a local connection if the management console is installed on the same computer as the server. Otherwise, it uses a local network address when one is available. If neither is possible, it connects through Axence Cloud Relay.
Direct connection, STUN and TURN
Axence Cloud Relay prefers local and direct connections, but it can establish a connection in almost any situation.
- If the console connects to a local server, the connection never leaves that computer (a TCP connection to localhost is used).
- If an Agent or console connects to the server through a local address, or through a publicly accessible address specified in the server configuration, the connection to that address is established over TCP.
- If an Agent, console or server is reachable only on a private network, the system first tries to negotiate a peer-to-peer connection. It does this by obtaining a transport address through the firewall (STUN, Session Traversal Utilities for NAT). If this connection can be established, it is used. Traffic between the Agent or console and the server then runs over it using WebRTC (Web Real-Time Communication) and UDP (User Datagram Protocol).
- If this method fails, the system falls back to the last option. It sets up a communication tunnel through an additional node that relays traffic between the Agent or console and the server (TURN, Traversal Using Relays around NAT). This option is subject to transfer speed limits and data usage caps. Communication uses WebRTC and UDP. As long as Agents, consoles and servers have network access, this option is reliable and always available.
Authentication
To launch the management console, you must enter the password for the server you are connecting to. The organization name and the license/subscription ID appear in the first login window.
Authentication takes place over a communication channel that the system selects automatically from those available in the current network configuration.
Agents do not require password authentication. They appear in the configuration once a connection to the server has been successfully established.
Data exchange between the console, Agents and the server
After authentication, you can use the management console to manage the server and its resources, including Agents installed on monitored computers.
Data always passes through the server, whatever type of connection each component uses. For example, the management console can send data directly over local TCP while an Agent uses a connection set up through WebRTC and the TURN service.
Connection speed depends on the connection type and the network configuration. For direct connections to the server, and for peer-to-peer connections set up with STUN, speed is limited only by the maximum bandwidth available in each direction. Connections through relay nodes have a maximum throughput of approx. 40 Mb/s. It may be lower if the network configuration cannot support that speed. Relay node usage is also subject to a monthly data transfer limit. If you exceed it, the bandwidth available on relay nodes is reduced. The limit depends on your license/subscription and its parameters. It does not affect direct connections.
Connection strategy: priorities
Connection mode | Description | Performance | Use case |
|---|---|---|---|
Local TCP | Traffic stays within the host/network | Highest | LAN |
TCP (known address) | Standard connection | High | Explicitly configured setups |
WebRTC P2P (STUN) | Direct UDP | Very high | NAT traversal |
WebRTC Relay (TURN) | Through Axence node | Limited (~40 Mb/s) | Fallback mechanism |