Streaming Gateway Appliance (SGA) with Frame Remoting Protocol (FRP) 8

In my previous blog posts I have outlined how the Frame™ Bring Your Own (BYO) Networking capability in Amazon Web Services (AWS) could be used to deploy a Frame account in a manner that would allow Frame-managed workload VMs to be connected to an existing private network. Recent addition of Frame Remoting Protocol (FRP) 8 has adjusted some of the ports and protocols used for workload connectivity. In this blog, I will update how the Frame Streaming Gateway Appliance (SGA) interacts with the new FRP8 networking environment.

Frame Remoting Protocol (FRP) 8

FRP8 is a new streaming protocol for how the end user’s browser connects to the Frame workload VM. The protocol leverages the WebRTC standard and UDP protocol to provide enhanced connectivity and additional capabilities and features. At the time of this writing, FRP8 is in Early Access and the enhancements and features are documented here. Since FRP8 is a pretty major switch from WebSockets (TCP) to WebRTC (UDP, by default), it has some networking implications that we will outline below.

Streaming Gateway Appliance (SGA)

The Streaming Gateway Appliance (SGA) is a reverse proxy, based on NGINX® software, that customers can deploy to allow Internet-based users to connect to Frame workload virtual machines (VMs) in a private networks. To support the new FRP8 protocol, the SGA was upgraded from SGA 2.X to SGA 3.X. Some of the differences in the two SGA versions are highlighted here.

For this blog, I will use a feature (Frame networking, private network with SGA) that automates the deployment of an SGA in order to explore the set of resources created. A generalized architecture of what is created is shown below.

Figure 1. Generalized SGA Deployment Architecture

Creating a Frame account

To create a SGA-based private account, a Frame administrator needs to select the “Frame Managed Networking” and the “Private network with SGA” radio buttons on the account creation page. Other information like cloud provider, data center, and network information is entered to create a private environment consistent with the rest of the enterprise network.

In the example below, I chose:

• AWS Montreal for my demo environment
• Two SGAs to show how load balancing will work
• A CIDR block for my workstation network that would not overlap with the rest of my private network (10.100.0.0/18)
• A smaller non-overlapping CIDR block for my SGA network (10.254.254.0/24) since the number of machines in this VPC would be much smaller.

Figure 2. Create Frame account with SGA

Enable FRP8

Since FRP8 is an Early Access feature, it is not enabled by default on new Frame accounts. To enable FRP8, go to the account Dashboard > Settings > Session Settings and enable FRP8.

Figure 3. Enable FRP8

Successful FRP8 enablement can be verified by starting a session in the Sandbox and enabling "Session stats" which should show UDP and FRP8 as being in use.

Figure 4. Verify FRP8 in Session Statistics

What’s under the hood

Now that I have created a Frame-managed SGA/Private network account running FRP8, we can explore what was created inside my AWS account.

VPCs

The first thing that was created was a couple of Virtual Private Clouds (VPCs) with the requested network CIDR blocks.

Figure 5. VPCs Created

The workload VPC is named with the Frame Vendor ID (in this case 48082) which is a unique ID within Frame Platform and the SGA VPC is named with the SGA ID (in this case, 1906) which identifies the SGA implementation inside Frame Platform. These two VPC’s are peered within AWS to allow for the free flow of private network traffic between them.

Figure 6. Peering connection created

Subnets

Next, Frame creates subnets inside the VPCs. In this case, Frame creates three subnets per VPC to provide the flexibility and availability within the VPC.

Figure 7.

NAT and Load balancer

The two VPCs will both need internet access:

1. The SGA will need inbound traffic from the Frame end users.
2. The Workload VPC needs outbound connections to Frame Platform.

Consequently, Internet Gateways are attached to both VPCs and a NAT GW will be attached to the Workload VPC.

Figure 8. NAT Gateway Configuration

For the SGAs, an AWS Load Balancer is provisioned to create a high availability SGA service.

Figure 9. AWS Load Balancer for SGA

Routing

The final steps are to route the traffic appropriately and assign security groups to the SGA and workload VMs.

In the workload VPC, the workload VMs are on “private networks” with outbound Internet traffic routed through the NAT Gateway while the traffic to the SGA VMs go out over the peering connection.

Figure 10. Private Network Routing

The NAT Gateway subnet will go directly to the Internet Gateway.

Figure 11. NAT Subnet Routing

And the SGA subnet will have a route to the Internet via the NAT Gateway and a route to the workloads in the Workload VPC via the peering connection.

Figure 12. SGA Subnet Routing

Security Groups

Security groups are set on the workload VMs to allow all traffic using specific TCP and UDP ports from the SGA subnet.

Figure 13. Workload VPC Inbound Security Group

The SGA security group allows TCP port 8888 traffic from specific Frame Platform IP addresses; all traffic from the workload VPC subnets; and specific TCP and UDP ports from the Internet.

Figure 14. SGA VPC Inbound Security Group

Conclusion

Automating the deployment of SGAs with FRP8 provides Frame administrators with the ability to quickly set up public access to private IP address spaces that utilizes the FRP8, based on the industry-standard streaming collaboration protocol WebRTC. As long as non-overlapping IP space is used, this configuration can be quickly integrated into the corporate private network via the installation of traditional VPN/private route tables.

Author

David Horvath

Senior Solutions Architect

More content created by

David Horvath

David Horvath is a senior solutions architect with Frame. He has been a part of the Frame team for almost five years and prior to that spent 20 years consulting on various information technology projects with the U.S. intelligence community.

© 2024 Dizzion, Inc. All rights reserved. Frame, the Frame logo and all Dizzio product, feature and service names mentioned herein are registered trademarks of Dizzion, Inc. in the United States and other countries. All other brand names mentioned herein are for identification purposes only and may be the trademarks of their respective holder(s). This post may contain links to external websites that are not part of Dizzion. Dizzion does not control these sites and disclaims all responsibility for the content or accuracy of any external site. Our decision to link to an external site should not be considered an endorsement of any content on such a site. Certain information contained in this post may relate to or be based on studies, publications, surveys and other data obtained from third-party sources and our own internal estimates and research. While we believe these third-party studies, publications, surveys and other data are reliable as of the date of this post, they have not independently verified, and we make no representation as to the adequacy, fairness, accuracy, or completeness of any information obtained from third-party sources.