navicon
close

The Benefits of Self-Hosted SASE

What is Secure Access Service Edge (SASE)? The main premise behind SASE is to provide security that follows the user no matter where they are, whether they are in the office, at home, in a coffee shop or relaxing by the beach.

With SASE comes a wave of solutions from known and unknown providers. However, do you need to add one more vendor to your vendor list to achieve the always-on security promised by SASE? Good question–this blog explores creating your own SASE.

Firewall in the Cloud

SASE offers firewall as a service as well as remote access VPN as a service hosted in the cloud. It is usually sold by vendor and priced based on the number of users in the organization or bandwidth capacity provisioned. Here we will focus on the remote access application of SASE.

To ensure a user is protected all the time, the VPN solution needs to be configured for always-on VPN where the user would be always tethered to the firewall whether they are in the office or not. This is not new; pretty much all VPN remote access solutions offers an always-on VPN option. However, the question is why do you need a cloud firewall?

The reason is the issue of pinning the user traffic to the on-site firewall–this would require the user traffic to traverse the firewall for inbound and outbound traffic. Traffic from users will consume a chunk of bandwidth from your existing on-premises firewall. This might not be an issue if you have a large Internet connection. The solution is to get a larger Internet pipe. So, we solved the bandwidth issue–what about the round-trip time delays? If the user is connected to the Internet in close vicinity to the firewall there are no issues; however, if the user is located across the country, performance would suffer.

 

 

 

 

 

 

 

 

 

 

Assuming that the user is in Los Angeles and the firewall is in New York, the traffic would suffer a round trip time delay of 72 ms. In this example, the user is reaching a web resource that is CDN optimized; in that case the web site would be served by the server closest to the firewall in New York. Throughput of a connection math is bandwidth times delay. If the user has a 20 Mbps connection at home, the throughput would be 20000000 * 0.072 =  1.4 Mbps. Might not be a big issue; however, if the web server is not CDN optimized and is in Los Angeles, we would need to add another 72 ms; now the throughput drops to 700 Kbps.

So the best approach is to provide remote access to users using a firewall closer to their location. This can be achieved by running firewalls in the cloud. Pretty much all cloud providers can fulfill this gap. We will focus on fulfilling this requirement using AWS.

The AWS solution is depicted in this diagram:

 

 

 

 

 

 

 

 

 

The components are firewalls hosted in multiple regions in AWS. This would be the same firewall that you use on-premises facilitating policy management and reducing the number of consoles the security admin needs to manage. Examples of single point of management for firewalls are Cisco Firepower Management Center, Palo Alto Panorama and Fortinet Forti manager. Pretty much all firewall vendors offer a central management solution for the firewalls.

One of the nice features that AWS offers is a Global Accelerator. The AWS Global Accelerator offers an anycast IP address front ending your firewall. This Anycast address relies on Internet routing to get the user an on-ramp edge closest to where they are located. AWS offers 80+ global edge locations that would ensure your users connect to the firewalls that are closest to where they are. So, this would solve the issue of delay in traffic where the user would connect to the N. Virginia firewall if they are on the east coast, the Oregon firewall if they are in the web coast, etc.

Using this approach, the user internet traffic gets fully tunneled to a firewall that is closer to their location minimizing delays, improving performance.

In the last diagram, there is another component–this is the transit gateway. AWS transit gateway is a high throughput router. AWS offers a transit gateway peering connectivity that utilizes the AWS backbone to connect regions together. This allows a short path connectivity to either AWS hosted services or customer on-premises services.

In the above example, there is an on-prem service that is hosted by a firewall close to the U.S east region. The user is located in the west coast–in this case, the user traffic would avoid congested Internet connections and gets routed through the AWS backbone.

Auto scaling of firewalls based on bandwidth is also another benefit that can be leveraged using AWS. A load balancer can be utilized to front end the firewall. This load balancer can auto scale the number of firewall instances serving user traffic. During peak time, you can scale to 4 firewalls for example and during off-peak hours you can scale back to a single firewall.

Advantages:

  • Minimizes delay
  • Enforces network security using the same solution protecting on-premises locations
    • Single pane of glass management
    • Single pane of glass traffic visibility
  • Unlimited scaling

Disadvantages:

  • Cost of bandwidth
    • User traffic reaching the Internet would be charged based on AWS outbound bandwidth rates which includes costs for the Global Accelerator, internet gateway egress
      • This would require weighing cost with benefits to see if this makes financial sense

With numerous firewall vendors solutions, in the next installment of this blog series, we will explore using Palo Alto Networks firewalls in the cloud to fulfill expanding remote access needs.

Mike Wissa is a Senior Solutions Architect at Groupware Technology