Routing both External and Internal Traffic to an Internal On-premise Adobe Connect Cluster
In some cases Adobe Connect on-premise server deployments include integration with high-end load-balancing devices that, even if not balancing load often serve as SSL accelerators and may also serve as proxy servers. F5 BigIP LTM, based on a modified version of Apache, is an example of one load-balancing device among others that can proxy Adobe Connect meeting traffic and I will use it as an example here.
Proxy options with consideration for the additional variables commensurate with an Adobe Connect on-premise deployment can include the Adobe Connect Transmuxing Server (ACTS) proxy for Adobe Connect Meetings in Standard View in the browser. For details about ACTS proxy deployments see: https://blogs.connectusers.com/connectsupport/adobe-connect-server-installations-with-the-adobe-transmuxing-server/
What follows in this article is by no means the only way to facilitate split traffic to an Adobe Connect cluster. There are other routing and security options. The following option presents an example model of what might be done; it uses a DMZ-based F5 BigIP LTM to route traffic to/through or around an internal F5 BigIP LTM to the server cluster/pools. It uses split DNS (external and internal using the same names with different IPs) and a set of VIPs on the DMZ-based F5 BigIP LTM to channel the traffic from the DMZ F5 BigIP LTM to an internal server cluster/pools.
The routing challenge with Adobe Connect Meeting is with the connection of the RTMPS stream between the Adobe Connect meeting server and the Adobe Connect Meeting client. For that to succeed in absence of external VIPs, the internal firewall would need to allow 443 for Meeting/AMS and client data streaming. Many customers prudently will not allow the same port open on the external side of the DMZ and on the internal side.
One workaround is to allow the external ACTS bound traffic in through the DMZ so that only the HTML5 Standard View in the browser is supported for external clients but not those using the Adobe Connect Meeting Application. The caveats with this approach include the need for the internal ACTS server to resolve the external AMS/Meeting FQDN. The ACTS server is installed alongside the Adobe Connect cluster internally rather than in the DMZ. ACTS is a proxy for Meeting/AMS with a unique configuration. By putting the ACTS server into the DMZ, the server to server communication requires what some may disallow.
In the attached diagram, I have laid out a way to do split traffic using F5 BigIP LTM Edge VIPs; the routing is a bit complex because of the combination of both HTTPS and RTMPS traffic. The requirement for the same FQDNs externally and internally may require some exceptions. An F5 BigIP LTM Edge VIP is a means of routing external RTMPS traffic into an Adobe Connect cluster through the highly modified Apache proxy server on which the LTM is based.
With that said, in the diagram below, I should probably add a third-party proxy into the DMZ. We have a proxy flag for Adobe Connect Meeting Classic View traffic that has some success in helping with routing around proxy servers. And in Standard View, the Adobe Connect Meeting Application beginning with version 2021.6.27.64h, has logic that makes it by far the most proxy friendly version of the Adobe Connect Meeting Application to date. The new application and the proxy flag nevertheless are more helpful for Adobe Connect hosted clients routing out from withing their networks to a cloud connection through their proxy servers rather than for facilitating an on-premise reverse proxy model.
I defer to F5 consulting if there is a more efficient means of routing from an Edge VIP to the internal Adobe Connect servers or cluster, although I am convinced this will work.
The key is the two separate FQDN’s, one for RTMPS that is invisible to end users to drive the Meeting and one in the URL for HTTPS to the application server.
Following the diagram example:
The Adobe Connect Meeting Pass-thru external Traffic from the DMZ on RTMPS must have direct access to the RTMPS LTM VIP FQDN:
connectmeeting.company.com – to 192.167.21.75:443 (invisible FQDN)
This may be done through an F5 LTM Edge VIP. Meeting traffic must bypass the proxy after initial and continuing https connection through the proxy depicted next.
Adobe Connect Application Server External Traffic from the DMZ using HTTPS may be channeled through a third-party proxy:
connect.company.com – to 192.167.21.74:443 (visible FQDN in URL)
This may be done through an F5 LTM Edge VIP
Note: Do not malform the FQDN/URL for HTTPS traffic to the Connect Application
Other examples of internal VIPs depicted above in the diagram may also be viewed here in a cluster configuration:
https://blogs.connectusers.com/connectsupport/adobe-connect-clusters/
An Adobe Connect cluster installed in a cloud configuration eliminates the challenges of supporting split traffic to internal resources and may be desirable. Various hosting options include Adobe Connect Hosted Services, Adobe Connect Managed Services or a Managed Adobe Connect ISP.