
Configuring Firewalls & VPNs for Adobe Connect
General Network Requirements for Adobe Connect
Regardless of the firewall or VPN product in use, two universal rules apply to every deployment. Review these requirements as the product-specific sections that follow below in this article will build on them.
Note: Domain-names and IP examples used throughout this article reference the Adobe Connect Hosted network infrastructure. Adjust accordingly for on-premise or Manged ISP.
Exclude SSL/TLS Inspection:
Adobe Connect uses end-to-end encrypted WebRTC and RTMP(S) streams. Any security product that performs SSL/TLS interception (man-in-the-middle decryption) on Adobe Connect traffic may have a negative affect on audio, video, and screen sharing it if it applies the wrong rules to the traffic such as trying to validate it as HTTPS. You must add Adobe Connect domains to the SSL inspection bypass or “Do Not Decrypt” list in your security platform.
Note: Above applies to: Secure Web Gateways, SSL Inspection proxies, DLP appliances
Exclude Adobe Connect from the VPN Tunnel:
If a VPN client is installed on end-user devices, Adobe Connect traffic must be excluded from the VPN tunnel so it routes directly to the internet. Routing Adobe Connect media through a VPN significantly degrades audio and video quality due to added latency and packet loss. Use whichever exclusion mechanism fits your existing VPN design — split-include (tunnel only private sub-nets) or split-exclude (tunnel everything except Adobe Connect). The mechanism varies by product; what matters is that Adobe Connect domains and IP ranges do not traverse the tunnel.
Note: Above applies to: Cisco ASA VPN, Cisco VPNaaS, GlobalProtect, Zscaler ZPA, Netskope NPA
Endpoints and Ports to Allow:
When a user joins an Adobe Connect Meeting room, two complementary network paths are used together — one for Meeting management and one for real-time media. Both must be allowed in any firewall or VPN product for the full meeting experience to work correctly.
Meeting Management & Room Access
Controls login, room loading, and meeting signaling
Allow standard HTTPS and WSS traffic to the following domain. This handles signing in, launching meeting rooms, and participant management.
| Domain | Protocol / Port | Purpose |
|---|---|---|
*.adobeconnect.com | HTTPS, WSS — TCP 443 | Meeting management and room access |
Audio, Video & Screen Sharing (WebRTC)
Works alongside — both are active in every room session
Once a user is inside a Meeting room, Adobe Connect uses WebRTC to deliver real-time audio, video, and screen sharing. This runs in parallel with the Meeting management connection above — both paths are active simultaneously during a meeting.
| Domain | Protocol / Port | Purpose |
|---|---|---|
*.webrtc.adobeconnect.com | TURN-S (TURN over TLS/TCP 443) | WebRTC signaling (load balancer) and media relay fallback |
IP Ranges for Adobe Connect Hosted Servers
Add only the range for the region in which your account is hosted unless you have accounts in both regions.
| IP Range | Region |
|---|---|
35.92.28.0/23 | North America |
3.252.48.0/23 | EMEA / APAC |
You may contact Adobe Connect Support to confirm which cluster your account is hosted on before applying IP-based rules. Adobe Connect cloud media IP ranges may change over time — periodically re-validate ranges with Adobe Connect Support or the official network requirements documentation.
Why both domain and IP rules are required: Adobe Connect WebRTC sessions attempt three connection paths during ICE negotiation, in order of preference:
- Direct Host UDP — peer-to-peer UDP connection on any port in the 30000–65535 range, directly to Adobe Connect media server IPs. This is the highest-quality path.
- UDP Relay (TURN UDP) — UDP relay through Adobe Connect TURN servers using direct server IPs, exclusively on port 3478. Used when Direct Host UDP fails.
- TLS Relay (TURNS) — TLS-encrypted relay over TCP 443 through the load balancer FQDN
*.webrtc.adobeconnect.com. Fallback path when UDP is blocked.
Note: The wide UDP port range is very effective for robust streaming; it is the highest quality option, but TURN/UDP will provide substantial performance where the wide UDP port range presents concerns.
Meeting room signaling and the TURNS fallback path are addressable via domain rules through *.adobeconnect.com and *.webrtc.adobeconnect.com. However, both UDP paths (Direct Host UDP and TURN UDP) connect to Adobe Connect Media server IP addresses directly, not via a load-balanced FQDN. These UDP streams bypass FQDN-based bypass mechanisms entirely. If you implement only FQDN exclusions, the firewall or VPN will intercept or block this direct UDP traffic, preventing both higher-quality paths and forcing the session onto the lower-quality TCP fallback. Both FQDN and IP-based exclusions are required to enable optimal, native UDP media delivery.
| Port | Protocol | Purpose |
|---|---|---|
3478 | UDP | UDP Relay (TURN UDP) — used exclusively for relay when Direct Host UDP fails |
30000–65535 | UDP | Direct Host UDP — peer-to-peer media on any port in this range (highest-quality path) |
443 | TCP | TLS Relay (TURNS) — fallback when UDP is blocked |
UDP is the preferred transport for media
Adobe Connect WebRTC performs best over UDP. UDP handles high-latency and packet-loss conditions better than TCP, resulting in higher quality audio and video. If UDP traffic on port 3478 and the 30000–65535 range is available, WebRTC will use either Direct Host UDP (the highest-quality path) or UDP Relay (TURN UDP) depending on network conditions. The full UDP ephemeral range is recommended for both paths to operate reliably. If organizational policy prevents opening UDP, WebRTC will automatically fall back to TLS Relay (TURNS) over TCP port 443. TURNS works well and carries approximately 20% of production WebRTC traffic, though audio and video quality may be reduced compared to native UDP. Where possible, allow UDP rather than relying solely on the TURNS fallback.
Before You Begin:
The product-specific sections below provide configuration steps to apply these requirements in each security platform. Each section references the domains, IP ranges, and ports listed here. The product list and steps are not comprehensive — they serve as an indicator of the changes required. You may need to perform additional steps based on the specific services enabled and any custom requirements in your environment. These steps should be performed by a qualified network or security administrator.
Steps to configure popular network appliances for use with Adobe Connect:
- Cisco Umbrella (DNS Security Only)
- Cisco Secure Access (Secure Web Gateway)
- Cisco VPN (VPNaaS)
- Cisco VPN (ASA Remote Access)
- Palo Alto Prisma Access(GlobalProtect)
- Zscaler (ZIA / ZPA)
- Netskope (NIA / NPA)
Cisco Umbrella (DNS Security Only)
Cisco Umbrella may be deployed for DNS security and optionally Secure Web Gateway (SWG). Adobe Connect domains and IP ranges must be added to Umbrella’s destination lists and web policy bypass list so that DNS resolution, web inspection, and media traffic are not intercepted.
Step 1 — Bypass Adobe Connect Domains in DNS Policy
- Sign in to the Cisco Umbrella portal.
- Go to Policies > Policy Components > Destination Lists.
- Create a new destination list named
AdobeConnect-Allowwith the destination list type set to Allow. Add the following entries:*.adobeconnect.com*.webrtc.adobeconnect.com
- Go to Policies > Management > DNS Policies, open the policy applied to your end-user identities, and attach the
AdobeConnect-Allowdestination list. - Select Save.
Note: Allow ≠ Bypass – An Allow destination list on a DNS policy only ensures the domains are not DNS-blocked — traffic can still be steered into the Secure Web Gateway proxy and decrypted. If SWG is in use, you must also complete Step 2 below (Web Policy > Selective Decryption List) to fully bypass inspection.
Step 2 — Bypass Adobe Connect in Web Policy (if SWG is enabled)
If your Umbrella deployment includes the Secure Web Gateway module, Adobe Connect must additionally be excluded from web inspection. If SWG is not in use, skip this step.
- Go to Policies > Management > Web Policies and open the policy applied to your end-user identities.
- Under HTTPS Inspection, add the
AdobeConnect-Allowdestination list to the Selective Decryption List as a bypass (Do Not Decrypt). - Under File Inspection and File Type Control, confirm Adobe Connect domains are not subject to inspection.
- Save the policy.
Step 3 — Restart the Cisco Umbrella Client
Restart the Cisco Umbrella roaming client service on end-user devices, or restart the machines, to apply the updated policy. Policy changes typically propagate within 30 minutes.
Step 4 — Validate Adobe Connect
- On a device with the Umbrella client active, join an Adobe Connect meeting room.
- Enable Enhanced Audio/Video Experience in room settings.
- Publish your camera and verify it is visible from a second device or session.
- Confirm no certificate inspection warnings appear for
*.adobeconnect.com*.webrtc.adobeconnect.com
- In the Cisco Umbrella portal, go to Reporting > Core Reports > Activity Search and verify Adobe Connect DNS queries are allowed and not blocked or redirected.
Cisco Secure Access (Secure Web Gateway)
Cisco Secure Access provides a Secure Web Gateway (SWG) and optionally Secure Private Access. Adobe Connect traffic must be explicitly excluded from SWG traffic steering so that media and signaling are not proxied or inspected.
Step 1 — Add Adobe Connect Bypass in Traffic Steering
- Sign in to the Cisco Secure Access portal.
- Go to Connect > End User Connectivity > Internet Security.
- In the Traffic Steering section, for Adobe Connect Hosted Servers select Add Destination > Bypass Secure Access. Add:
*.adobeconnect.com*.webrtc.adobeconnect.com
- Select Add Destination > Bypass web proxy only and add the IP range for your hosted cluster region:
35.92.28.0/23— if hosted in North America3.252.48.0/23— if hosted in EMEA or APAC
- Select Save
Step 2 — Allow Required Ports in Internet Security Policy
- In the Cisco Secure Access portal, go to Secure > Internet Security > Policies.
- Ensure the following are permitted for
*.adobeconnect.com*.webrtc.adobeconnect.com- TCP 443
- UDP 3478
- UDP 30000–65535
- Save the policy.
Step 3 — Restart the Cisco Secure Client
Restart the Cisco Secure Client on end-user devices to apply the updated policy.
Step 4 — Validate Adobe Connect
- Confirm the Cisco Secure Client is running and the Internet Security profile shows as Active.
- Join an Adobe Connect meeting room and enable Enhanced Audio/Video Experience.
- Publish a camera and verify it is visible from a second session.
- In the Cisco Secure Access portal, go to Monitor > Activity Search and confirm traffic to
*.adobeconnect.comshows as bypassed.
Cisco VPN (VPNaaS)
This section covers Cisco VPN deployments where Adobe Connect traffic must be kept outside the VPN tunnel and routed directly to the internet. Depending on your existing VPN design, exclusion can be done via split-include (tunnel only private sub-nets) or split-exclude (tunnel everything except Adobe Connect). The ASA section below covers both approaches.
Step 1 — Configure VPN Traffic Steering to Exclude Adobe Connect
- Sign in to the Cisco Secure Access portal.
- Go to Connect > End User Connectivity > Virtual Private Network.
- Select your VPN profile, then select Traffic Steering.
- Configure split-tunnel routing so that only your private enterprise subnets are included in the VPN tunnel. Adobe Connect traffic must bypass both VPN tunneling and Secure Access web proxy inspection.
- Confirm the tunnel routes do not include the Adobe Connect IP range for your region:
35.92.28.0/23— North America3.252.48.0/23— EMEA or APAC
- Under DNS Mode, select Split DNS and enter only your private application DNS suffixes. Do not include
- adobeconnect.com
- webrtc.adobeconnect.com.
- Save the profile.
Note: In Cisco Secure Access VPNaaS, configure Traffic Steering so that only private enterprise sub-nets are tunneled. Adobe Connect must remain outside the VPN tunnel and outside Secure Access web proxy inspection at all times.
Step 2 — Validate Adobe Connect
- Connect to the Cisco Secure Access VPN using Cisco Secure Client.
- Join an Adobe Connect meeting, enable Enhanced Audio/Video Experience, and publish a camera.
- Verify the camera is visible from a second session.
- In Monitor > Activity Search, confirm Adobe Connect traffic is categorized as bypassed/direct, not routed through the VPN tunnel or SSL-inspected by the SWG.
Cisco VPN (ASA Remote Access)
Cisco ASA supports two primary split-tunnel policies for excluding Adobe Connect from the VPN tunnel: Option A (Split Include) or Option B (Split Exclude), depending on your existing deployment. Option C (Dynamic Split Tunneling) is supplemental — it can be added on top of Option A or B for FQDN-based handling of signaling traffic, but it does not cover WebRTC media traffic on its own, since media connects to Adobe Connect IPs directly.
Option A — Split Include (Tunnel Specified) If you tunnel only private sub-nets
- Open Cisco ASDM and go to Configuration > Remote Access VPN > Network (Client) Access > Secure Client Connection Profiles.
- Select the relevant connection profile and select Edit.
- Under Group Policy, set the DNS server to your private application DNS server only.
- Expand Advanced > Split Tunneling and set:
- DNS Names: Inherit
- Send All DNS Lookups Through Tunnel: No
- Policy:
Tunnel Network List Below - Network List: Select the ACL containing only your private application IP ranges
- Confirm the ACL does not include the Adobe Connect IP range for your region (
35.92.28.0/23for North America,3.252.48.0/23for EMEA or APAC).Select - Save and apply.
Option B — Split Exclude (Tunnel All Except) If you currently tunnel all traffic
- Under Advanced > Split Tunneling, set Policy to
Exclude Network List Below. - Create or edit an ACL containing the Adobe Connect IP range for your hosted cluster region:
35.92.28.0/23— North America3.252.48.0/23— EMEA or APAC
- Attach the ACL to the Network List field.Select
- Save and apply.
Option C — Dynamic Split Tunneling (FQDN-Based) Supplemental — use alongside Option A or B
Dynamic Split Tunneling complements (but does not replace) IP-based split tunneling. Use it in addition to Option A or B if you want FQDN-based exclusion of signaling traffic. Requires Cisco Secure Client (AnyConnect) 4.6 or later.
- In Cisco ASDM, go to Configuration > Remote Access VPN > Network (Client) Access > Group Policies. Select your group policy and choose Edit.
- Navigate to Advanced > Secure Client (or AnyConnect) Client > Dynamic Split Tunneling.
- In the Exclude Domains field, add the Adobe Connect domains as a comma-separated list:
adobeconnect.com, webrtc.adobeconnect.com - Leave Include Domains empty unless required by other policies.Select
- OK, save the group policy, and apply.
Note: Dynamic Split Tunneling resolves the listed FQDNs in real time and excludes the resolved IPs from the tunnel automatically. This handles signaling traffic routed through *.adobeconnect.com and *.webrtc.adobeconnect.com. However, WebRTC media traffic connects directly to dedicated Adobe Connect EIP addresses by IP, not by domain, so Option C alone is not sufficient — you must also configure Option A or Option B for the Adobe Connect IP range. The exact menu labels and domain syntax may vary slightly between ASA/FTD releases and Cisco Secure Client (AnyConnect) versions; validate against your specific release before deploying broadly.
Validate Adobe Connect
- Connect to the Cisco ASA VPN using Cisco Secure Client or AnyConnect.
- Join an Adobe Connect meeting, enable Enhanced Audio/Video Experience, and publish a camera.
- Verify the camera is visible from a second session.
- On the client, run
route print(Windows) ornetstat -rn(macOS/Linux) to confirm the Adobe Connect IP range appears in non-tunneled routes. - Confirm in ASA logs that Adobe Connect traffic is excluded from the VPN tunnel — that is, the action shows traffic was not encapsulated through the tunnel, regardless of any related session metadata.
Palo Alto Prisma Access(GlobalProtect)
Palo Alto Prisma Access uses the GlobalProtect client to handle private application and internet traffic. Adobe Connect domains and IP ranges must be added to GlobalProtect’s split-tunnel exclusion list so they route directly to the internet and are not tunneled or inspected through Prisma Access.
Step 1 — Add Adobe Connect to GlobalProtect Split Tunnel Exclusions
- Sign in to the Palo Alto Strata Cloud Manager portal.
- Go to Workflows > Prisma Access Setup > GlobalProtect > GlobalProtect App > Tunnel Settings.
- In the Split Tunneling section, under Exclude, add the following domains:
*.adobeconnect.com*.webrtc.adobeconnect.com
- Add the IP route for your hosted cluster region:
35.92.28.0/23— if hosted in North America3.252.48.0/23— if hosted in EMEA or APAC
- Select Save.
Step 2 — DNS Behavior (Conditional)
Palo Alto’s supported split-tunnel guidance is to configure exclusions by domain (completed in Step 1). The DNS option below should only be adjusted if Step 1 alone does not produce the expected behavior — for example, if Adobe Connect domains resolve to internal IPs because tunnel-assigned DNS is intercepting them. Do not change this setting if domain-based split-tunnel exclusions are working as expected.
- In Strata Cloud Manager, go to Workflows > Prisma Access Setup > GlobalProtect > GlobalProtect App > App Settings.
- Scroll to App Configuration > Show Advanced Options > DNS.
- If split-tunnel exclusions are not resolving as expected, consider unchecking the box for Resolve All FQDNs Using DNS Servers Assigned by the Tunnel (Windows Only). Validate the impact on other internal applications before applying broadly.
- If a change is made, select Push Config, then select Push in the top right.
- Verify the push completes successfully in the Push Configuration dialog before closing it.
Note: Changing this setting alters DNS resolution behavior for all FQDNs handled by the client, not just Adobe Connect. Coordinate with your network/DNS team before making this change in production.
Step 3 — Validate Adobe Connect
- Connect to GlobalProtect and confirm the client shows a Connected state.
- Join an Adobe Connect meeting and enable Enhanced Audio/Video Experience.
- Publish a camera and verify it is visible from a second session.
- In Strata Cloud Manager, go to Incidents & Alerts > Log Viewer and confirm that Adobe Connect traffic is categorized as excluded from the tunnel and is not being inspected by Prisma Access. Excluded flows may still appear in logs — the criterion is the action recorded, not the absence of entries.
Zscaler (ZIA / ZPA)
Zscaler Internet Access (ZIA) provides web security and traffic inspection. Zscaler Private Access (ZPA) handles private application connectivity. Adobe Connect domains and IP ranges must be added to the Zscaler Client Connector app profile bypass list so that Zscaler does not proxy or inspect Adobe Connect traffic.
Step 1 — Add Adobe Connect to the App Profile Bypass
- Sign in to the Zscaler Client Connector admin portal.
- Go to App Profiles > Windows (or macOS) and open or create the relevant app profile.
- Scroll down to the HOSTNAME OR IP ADDRESS BYPASS FOR VPN GATEWAY field.
- Add the following domains:
*.adobeconnect.com*.webrtc.adobeconnect.com
- Add the IP range for your hosted cluster region:
35.92.28.0/23— if hosted in North America3.252.48.0/23— if hosted in EMEA or APAC
- Select Save.
Step 2 — Verify the Forwarding Profile and Z-Tunnel Mode
Bypass behavior in Zscaler depends on which Z-Tunnel mode your forwarding profile uses. Confirm the mode first, then validate bypasses are configured in the correct location.
- In the Zscaler Client Connector admin portal, go to Administration > Forwarding Profile.
- Open the forwarding profile assigned to the app profile above and identify the Tunnel Driver Type:
- Z-Tunnel 2.0 (Packet Filter-Based or Route-Based): Adobe Connect bypasses must be configured as VPN gateway bypasses or destination exclusions in the App Profile (as done in Step 1). Do not add bypasses to the PAC file.
- Z-Tunnel 1.0: In addition to Step 1, update the App Profile PAC file to return
DIRECTfor*.adobeconnect.comand*.webrtc.adobeconnect.com.
- Confirm ZIA and ZPA forwarding actions are set correctly for your deployment.
- Select Save.
Step 3 — Verify ZIA SSL Inspection Policy
- In the ZIA admin portal, go to Policy > SSL Inspection.
- Confirm
*.adobeconnect.comand*.webrtc.adobeconnect.comare in the SSL inspection bypass (Do Not Inspect) list. - If not present, add them and select Save, then Activate the change.
Step 4 — Validate Zscaler Client Configuration
- On the end-user device, right-click Zscaler Client > Open Zscaler > More.
- Verify the App Policy reflects the profile configured above. Select Update if outdated.
- Check Internet Security and verify Service Status matches your expected state.
Step 5 — Validate Adobe Connect
- Join an Adobe Connect meeting room and enable Enhanced Audio/Video Experience.
- Publish a camera and verify it is visible from a second session.
- In the ZIA admin portal, go to Analytics > Web Insights > Logs and confirm Adobe Connect traffic is categorized as bypassed/direct and is not SSL-inspected or tunneled through ZIA. Bypassed flows may still generate telemetry — the criterion is the inspection action, not the absence of entries.
- Verify UDP 3478 and the 30000–65535 range are not blocked by any ZIA firewall policy.
Netskope Internet Access (NIA) steers web traffic through Netskope’s cloud for inspection. Netskope Private Access (NPA) handles private application connectivity. Adobe Connect IP ranges must be added to a Netskope Network Location Profile and configured as a bypass exception in the Steering Configuration so Adobe Connect traffic is not inspected or tunneled.
Step 1 — Create a Network Location Profile for Adobe Connect
- Sign in to the Netskope portal.
- Go to Policies > Profiles > Network Location.Select New Network Location > Single Object.
- Name the profile
AdobeConnect. - Add the IP range for your hosted cluster region:
35.92.28.0/23— if hosted in North America3.252.48.0/23— if hosted in EMEA or APAC
- Select Save.
Step 2 — Add Adobe Connect Bypass to the Steering Configuration
- In the Netskope portal, go to Settings > Security Cloud Platform > Steering Configuration.
- Open the steering configuration that applies to your end-user devices.Select Exceptions > New Exception > Destination Locations.
- Select the
AdobeConnectprofile created in Step 1. - Set the action to Bypass. If the option Treat it like a private app (in newer builds) or Treat it like local IP address (in older builds) is presented, enable it. Select Add.Select New Exception > Domains and add:
*.adobeconnect.com*.webrtc.adobeconnect.com
- Select Save.
- Confirm the steering configuration is at the top of the configuration list and is Enabled.
Step 3 — Verify SSL Inspection Bypass for Adobe Connect
- In the Netskope portal, go to Policies > SSL Decryption.
- Confirm
*.adobeconnect.comand*.webrtc.adobeconnect.comare in the Do Not Decrypt list. - If not present, add a new policy with these domains and the Do Not Decrypt action, then save.
- Click Apply Changes at the top of the SSL Decryption page. Netskope policies require this commit step to activate — without it, the bypass will not take effect.
Step 4 — Validate the Netskope Client
- On the end-user device, right-click Netskope Client > Configuration.
- Verify the Steering Configuration name matches the configuration updated above. Select Update if it does not match.
Step 5 — Validate Adobe Connect
- Join an Adobe Connect meeting room and enable Enhanced Audio/Video Experience.
- Publish a camera and verify it is visible from a second session.
- In the Netskope portal, go to Skope IT > Page Events (or Application Events) and confirm Adobe Connect traffic is marked as bypassed and is not decrypted, inspected, or routed through NIA/NPA inspection paths. Bypassed flows may still generate telemetry — the criterion is the action recorded, not the absence of entries.
- Verify UDP 3478 and the 30000–65535 range are not subject to any Netskope firewall policy.
Validation Checklist — All Configurations
Use this checklist after completing configuration for any of the products above.
| Test | Expected Result |
|---|---|
| Join Adobe Connect meeting room | Room loads without errors |
| Enable Enhanced Audio/Video Experience | Setting applies successfully |
| Publish camera | Camera stream is visible in the room |
| View camera from a second device or session | Stream renders without buffering or dropping |
| Share screen | Screen share starts and is visible to others |
Firewall/VPN logs for *.adobeconnect.com | Traffic is categorized as bypassed/excluded and is not SSL-inspected or tunneled (telemetry may still appear) |
Firewall/VPN logs for *.webrtc.adobeconnect.com | Traffic is categorized as bypassed/excluded and is not SSL-inspected or tunneled (telemetry may still appear) |
| SSL/TLS inspection check | No inspection warnings for Adobe Connect domains |
| UDP 3478 connectivity | STUN/TURN handshake succeeds if UDP is allowed |
| UDP 30000–65535 | If UDP is allowed, media establishes over UDP; if UDP is blocked, media falls back successfully to TURN-S over TCP 443 |
Advanced troubleshooting: For deeper validation of ICE candidate selection, UDP vs TCP path, TURN relay state, packet loss, and jitter, open chrome://webrtc-internals in Chrome or edge://webrtc-internals in Edge during an active Adobe Connect meeting. The active candidate pair, selected transport, and live media statistics are visible there.