Many organizations have relied on Virtual Private Network (VPN) software to extend their enterprise networks out to remote workers. This is a time‑honored strategy, but it comes with some significant caveats:
And, perhaps most importantly,
To be clear here, F5 is not saying to throw away a traditional VPN, but we have realized for ourselves is that with most applications being web enabled and using encryption for transport, some of the downfalls of a full VPN can be avoided with a web based portal system. Yes, you will have cases where you want a full VPN tunnel, but if we could minimize this, could we improve the user experience as well as security, while also reducing some of the overhead of VPN technologies?
A VPN tunnel is indiscriminate in the traffic it allows to pass; without granular access control lists (and the maintenance they require) or split tunneling enabled, a compromised client could send any traffic it wants into your network, not just traffic for the applications you intend to expose. A hastily configured VPN creates a hole in your perimeter with a sledgehammer, when what you really want is a scalpel.
Fortunately, there is another option. The Identity‑Aware Proxy, which is a function of F5 Access Policy Manager (APM), allows secure, contextual, per‑application access into the enterprise without the overhead of managing a full VPN tunnel. No client‑side software other than a web browser is needed, and because it’s built on the full‑proxy architecture of F5 BIG‑IP, it’s not dependent on a particular network topology and can be rapidly deployed in the public cloud for immediate scale. This article will take you through the combined F5 and public cloud solution, and how you can use the flexibility and scalability of the cloud to quickly get up and running.
A traditional VPN relies on tunneling traffic from a remote client through your network perimeter into your network:
Figure 1: A traditional Layer 3 VPN
Modern VPNs use public‑key cryptography over protocols like TLS or DTLS to provide confidentiality, and integrate with your corporate directory—and, ideally, a multi‑factor authentication system—to authenticate the user attempting to connect. Once authentication is completed, however, a simple layer 3 connection is established, with little to no inspection or visibility into what is traversing that connection.
The Identity‑Aware Proxy, by comparison, works at layer 7, sitting in the middle of the HTTPS conversation between your users and your applications, validating each request against the access policy you define:
Figure 2: BIG‑IP Access Policy Manager as an Identity‑Aware Proxy
Much like a traditional VPN, the Identity‑Aware Proxy uses strong, modern TLS encryption and supports a broad array of multi‑factor authentication solutions. Unlike a traditional VPN, there is no layer 3 tunnel created, and only valid HTTPS requests are forwarded. No client‑side software is required.
The biggest difference compared to a traditional VPN is that—instead of making an allow or deny decision at the beginning of a session—each request is validated against the access policy you define. Throughout the lifetime of an access session, the proxy continually examines and assesses the requests being made by the client for authorization and context, including:
* Requires the F5 APM Helper App, included with APM
This is a core tenet of zero‑trust: never trust, always verify. Just because we let a user connect to our environment once doesn’t mean that any subsequent requests they make should be allowed. Per‑request policy enforcement enables this continuous and ongoing validation.
Figure 3: BIG‑IP APM Deployed in the public cloud
For this example, we’re using the public cloud to quickly spin up a proxy that will allow users to connect to our applications inside the network without needing to deploy any additional hardware or software within our on‑premises environment. We’re using an IPSEC VPN from the cloud to our on‑prem firewall for backend communication as it’s quick to configure and widely supported by existing firewalls and routers. You could just as easily use other hybrid connectivity options like ExpressRoute or Direct Connect, or interconnect services through your ISP or a connectivity provider like Equinix.
We’re also using ADFS to provide federated login between your on‑prem directory and BIG‑IP in the cloud, but this isn’t the only option. Active Directory, Azure AD, LDAP, Okta, SAML and oAuth/OIDC, amongst others, are all supported as user identity sources, as well as most multi‑factor authentication systems like Azure MFA, Duo, SafeNet, and more.
The F5 BIG‑IP software that powers the Identity‑Aware Proxy is available natively in all major public clouds. Multiple deployment and licensing options are available, but for the purposes of this example, we’ll be using the cloud providers’ own marketplaces to rapidly deploy BIG‑IP with hourly billing and no up‑front costs.
If you’re looking to get started with BIG‑IP quickly, hourly billing is a great option; however, if you’re planning on running this environment for an extended period of time, or if you want more flexibility and more control over costs than the utility model provides, F5 offers several other consumption models.
While we provide tools to generate your own BIG‑IP images for deployment in public cloud, the cloud marketplaces are the simplest and quickest way to get BIG‑IP into your cloud environment. With just a few clicks and answering a few questions about your deployment, you can go from zero to deployed within minutes. This is the method we used in our example environment to get the proxy up and running as quickly as possible.
Of course, that’s not the only way to do it. If you want a more programmatic approach, we offer supported templates for major cloud providers, as well as the F5 Automation Toolchain for declarative, repeatable deployments using tools like Terraform or Ansible.
For more details on running BIG‑IP in the cloud, refer to F5 CloudDocs for guides, examples, templates, and more.
There are many underlying configuration objects, policies, and profiles that need to be created to enable a granular, contextual access policy, but BIG‑IP’s Guided Configuration makes the configuration easy and intuitive. Guided Configuration provides a simple, wizard‑like interface that walks you through the steps to:
With Guided Configuration, the underlying complexity of building a granular, per‑request access policy is abstracted away. You don’t need to be an F5 guru to securely deploy applications through the proxy.
Now that you’ve deployed your proxy, you want to make sure that it’s scalable and resilient. Guided Configuration, templates, and the Automation Toolchain make deploying multiple instances across cloud environments easy, but directing traffic to those instances and getting users to the best proxy is another matter.
If you’ve been working with F5 for a while, you’re probably familiar with F5 DNS Services, which provides intelligent, dynamic DNS resolution for globally‑available applications. Amongst other features, F5 DNS provides Global Server Load Balancing (GSLB), which allows you to direct users to any one of several globally‑distributed endpoints for a particular service. In our environment we use GSLB to make our proxy redundant and globally‑available. Users are, by default, routed to the closest proxy to serve their request. If one instance fails, reaches capacity, or if that cloud region otherwise has a bad day, then that failure is automatically detected and users are moved to an alternate site.
Figure 4: Global Availability with F5 Cloud Services DNS Load Balancing
If you don’t already have F5 DNS in your environment, you don’t need to run out and buy a bunch of BIG‑IPs just to enable GSLB. F5 Cloud Services DNS Load Balancer provides GSLB from an on‑demand, usage‑based SaaS platform. There’s even a free tier that offers a load balancing configuration with up to 3 million DNS queries per month, making it easy to get started. In our environment, we use CNAME records to direct multiple applications through the same DNS Load Balancer, so depending on your usage requirements, you can add global availability to your proxy.
Hopefully this article has shown you how quick and easy it is to get going with F5 in the cloud. Between Infrastructure‑as‑a‑Service from your cloud vendor, hourly billing through the cloud marketplace for BIG‑IP, and F5 Cloud Services for global availability, you can deploy this entire solution on utility billing without needing to go through cumbersome procurement processes. Please let me know in the comments below how you’re using cloud and infrastructure‑on‑demand to respond quickly to the changing needs of a workforce in these trying times. Stay safe, stay healthy, and wash your hands!