BeyondTrust Privileged Remote Access's peer-to-peer technology is compatible with Atlas deployments.
For more information 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 Privileged Remote Access can be configured to use either the BeyondTrust public STUN server, or the Secure Remote Access Appliance (master node) can act as a STUN server for connections.
What impact will the availability of the STUN server have on the deployment?
If the Secure Remote Access Appliance (master node) is used as the STUN server, the clients reach out to the master 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 Secure Remote Access Appliance 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 master node acts as the STUN server when the Secure Remote Access Appliance is configured for this role.