Peer-to-Peer Functionality

BeyondTrust Remote Support's peer-to-peer technology is compatible with Atlas deployments.

To learn more about peer-to-peer functionality, please see Options: Manage Session Queuing Options, Record Sessions, Set Up Text Messaging , and Appliance Administration: Restrict Accounts, Networks, and Ports, Set Up Syslog, Enable Login Agreement, Reset Admin Account .

However, there are a few considerations when attempting to use peer-to-peer with an Atlas architecture.

How can BeyondTrust's peer-to-peer functionality be used in an Atlas-configured environment?

For Atlas deployments, BeyondTrust Remote Support can be configured to use either the BeyondTrust public STUN server, or the BeyondTrust Appliance B Series (primary node) can act as a STUN server for connections.

What impact will the availability of the STUN server have on the deployment?

If the BeyondTrust Appliance B Series (primary node) is used as the STUN server, the clients reach out to the primary node for session initiation. If the public BeyondTrust STUN server is used, the clients reach out to the public BeyondTrust STUN server for session initiation. Peer-to-peer connections are attempted like any non-Atlas deployment; however, the main difference is the connection falls back to a selected traffic node at session start if the connection attempt to the STUN server is unsuccessful.

Are there any special considerations for using the BeyondTrust Appliance B Series as a STUN Server in an Atlas environment?

The same firewall considerations apply for peer-to-peer in an Atlas deployment as in a non-Atlas deployment. The clients need to reach out to a STUN server, and in this case, the primary node acts as the STUN server when the BeyondTrust Appliance B Series is configured for this role.