Firewall and Proxy Server Configuration for Adobe Connect 12

Overview

The core of Adobe Connect 12 contains an upgrade of the underlying audio/video/screen-sharing technology from RTMP to WebRTC. 

WebRTC was designed from the outset to work across a wide range of networks, so for most customers, it will "just work." However, some customers with restrictive firewalls or web proxies may need to update their network configurations.

Any issues will manifest themselves after the meeting has been launched when a user tries to publish or view audio, video, or screen sharing.

This whitepaper will describe the minimum required network configuration and the recommended network configuration for optimal performance.

Minimum required network configuration for Enhanced Meetings based on WebRTC

The minimum configurations are divided into:

• Configuration for web traffic
• Configuration for WebRTC traffic

Minimum configuration for web traffic

Users must allow standard https:// and wss:// web traffic to *.adobeconnect.com.

Very few customers will need to change anything to meet this requirement, as this is standard HTTPS traffic.

In addition, users must allow certificate validation for (also something very few customers will need to do explicitly) the following:

• crl3.digicert.com
• crl4.digicert.com
• ocsp.digicert.com

Minimum configuration for WebRTC traffic

When all other communication methods are blocked, WebRTC falls back to tunneling over TLS (TURN-S). This is similar to how RTMP falls back to tunneling over HTTPS.

TURN-S performs very well. Approximately twenty percent of our production WebRTC traffic occurs over TURN-S, and those users have a great experience.

However, some proxies and firewalls block TURN-S traffic because it isn't the same as HTTPS traffic on deep inspection. This is especially true for customers with firewall or proxy devices that perform man-in-the-middle inspections.

The minimum requirement is:

• Allow TURN-S traffic (or simply all encrypted traffic) over port 443 to *.webrtc.adobeconnect.com

On August 23, 2022, we will have transitioned to static IP blocks in North America and EMEA. This will allow customers to allow by IPs rather than by wildcard domain.

Customers hosted in North America can allow the IPs in CIDR 35.92.28.0/23 and customers hosted in EMEA and APAC can allow the IPs in 3.252.48.0/23.

Additional static IP blocks will be added in the future, so customers who choose to allow static IPs will need to update their allowed IP blocks at that time. For this reason, we recommend that customers allow the IPs by domain name if possible.

Recommended network configuration

One of the most significant advantages of WebRTC is that it prefers UDP traffic. UDP better handles poor network conditions (high latency, high packet loss) 
than TCP.

Accordingly, we recommend that customers allow the following UDP and TCP ports:   

These ports should be allowed for the following destinations:

For customers hosted in NA to 35.92.28.0/23
For customers in EMEA and APAC to 3.252.48.0/23

Note: if using a proxy server, you may need to turn off SSL inspection of TLS/TURNS traffic on 443.

Testing the network configuration

For testing the network configuration post changes requested above, please do the following

• Enable 'Enhanced Audio/Video Experience' for one of the existing rooms or a new room
• Join the room as a host and start sharing your camera in the room
• Join the same room again (either from the same device or from a different device)
• If the shared camera is visible in the room from the second device, then the changed network configuration is working as expected.