Deploying BIG-IP F5 Appliances in Azure

F5 network appliances are very versatile, with load balancing, DNS, Firewall, URL filtering and SSL VPN modules available they can be the core of any service. This has been the case for quite some time now in for on premise and vmware focussed estates but in the world of public cloud there are native alternatives that take over these roles. So why would you continue to use an F5 if that was the case:

1. Single device management — if you are only using F5 then you only need to know the intricacies of how an F5 works and not multiple PaaS services.
2. Control — you can control the data flow and manipulate it however you feel fit which would require more than one PaaS service to do. F5 iRules allow very granular control of the traffic and caching and accceleration all within one device is a an attractive option.

This isn’t about F5 vs PaaS though, imagine you’ve already chosen F5 and now you need to implement it. In my case it was going to be my all in one load balancing solution for multiple internal and external web services. Sounds easy enough except I need to have a single IP:Port combination per service and I dont want to add a NIC for each service to the F5 device because that is both messy and not very scalable. So how do I route my traffic and listen for traffic on different IPs when I’m using a single NIC F5?

Internal F5 routing

Internal routing with an F5 may seem like overkill but it does provide benefits over traditional Azure Load Balancers; SSL offloading, caching, redirection and traffic manipulation are all useful additions when managing multiple services in large organisations. Implementing this within Azure requires a few additional resources to provide the functionality the F5 offers.

Azure Routing and Load balancing

So I know I am using an F5 but I need to have a Highly Available service as well, which means I’m going to load balance the load balancer… Using Azure level load balancers I can manage the “hardware” of the F5, i.e. the VM, and let the F5 manage applications.

The Azure LB now gives me a single IP that I can forward traffic to but I still have the same problem as before, a single IP. This is where *HA Ports** come in, a special feature of Azure LB that removes the need to specify a particular port to listen on. Instead the LB will listen for ALL traffic that is routed to the Load Balancer and forward it to the backend servers. This one feature is what makes using a Network Virtual Appliance in Azure so much easier and its the key to how I setup my F5.

This feature is available only for internal load balancers

Now that I have my F5 and Azure LB setup for HA, I need to get user traffic to it. Azure Route tables do exactly what they say and by making use of User Defined Routes I can manage my traffic flow and ensure it reaches the F5 via the Azure LB, nothing fancy or special just a route table assigned to my subnets and a single UDR that will route traffic were I want it to go.

F5 Virtual Servers

So I have all my services but I still need multiple IPs, one for each service I want to load balance. F5 Virtual Servers are how I define the individual services I want to manage and this is where I also define the IP:Port combination I want to listen on.

If I use the IP supplied by Azure then I can only have one Virtual Server, on as many ports as I like but web services use 80 and 443 so that gives me two Virtual Servers max without messing with ports elsewhere which gets complicated. The funny thing about an F5 Virtual Server, it doesnt care what IP you give it… by that I mean, just stick a valid IP address in and it will be happy except you still need to get traffic to it.

So lets say I have a Virtual Network with a range of 10.20.0.0/20, my F5 and Azure LB will have IPs within this range but I don’t want to use any of these IPs for my F5 Virtual Servers, using a range from the Virtual Network will cause an eventual conflict. Azure has no knowledge of the F5 Virtual Servers so it would attempt to use the IPs within the Virtual Network range as they aren’t in use by other Azure resources.

That being the case, I want to use a range outside this and something like 10.21.0.0/24 will work just fine. If I keep all of the Virtual Server IPs within this range I will have zero conflicts with Azure and I now have a huge numner of IPs I can use on the F5.

Now I need to be able to route traffic for those IPs to the F5 and this is where it all comes together. The following is a list of the requirements to make this work:

• DNS Entries
• DNS entries for the applications that point to IPs in the F5 range
• User Defined Route
• A UDR on a custom route table that routes traffic for the new IP range to the Azure Load Balancer IP
• Azure Load Balancer
• The Azure Load Balancer is setup with:
• Frontend IP
• Backend Servers
• LB Rule with HA Ports enabled
• F5 Appliance
• The F5 appliance(s) configured with the Virtual Servers and IP:Port combinations required.

Putting it all together

Starting with DNS entries, all services should point to an F5 Virtual Server so the DNS entry is going to use an IP within my new 10.21.0.0/24 range. Users accessing these services will get back an IP in this range and they need to be routed to the Azure Load Balancer.

Depending on how the users access the services this step will differ but in my case the users are accessing the service over a Site to Site VPN in Azure. The on premise environment will forward all traffic for my ranges via this VPN so I just need to manage the routing in Azure. To do this I can create a custom route table and apply it to the Gateway Subnet which is where the VPN is located.

NOTE: Be careful when using custom routes on the Gateway Subnet, you need to ensure that the Gateway Subnet range can communicate with other items within the subnet i.e. other VPNs or ExpressRoute. If user-defined routes (UDRs) are being associated with the Gateway Subnet, a UDR for the gateway subnet range and a next hop of Virtual network is necessary: Github issue

With a route table in place I can now apply a User Defined Route that forwards all traffic to my Azure Load Balancer, this is very easy and should result in 10.21.0.0/24 having a next hop address of the Azure Load Balancer Frontend IP e.g. 10.20.0.5/32

Now all traffic coming over the VPN with an destination IP of 10.21.0.n will be forwarded to the Azure Load Balancer which in turn will forward everything to the F5 appliance(s).

With all of this in place the range could be expanded beyond the original /24 as it is not bound by anything Azure based and will not conflict with my Azure resources.

Now of course this is all based on using the F5 as an internal routing device, if you want to use the F5 as an edge device then the user defined routing isn’t going to be possible.

Internet facing

Whilst F5 appliances are very useful internally, they are very well suited to external traffic management. Using an F5 as the edge device in the network makes sense for multiple web facing services each with its own requirements.

Implementing this in Azure is actually not as difficult as implementing an F5 for internal use but does of course have the caveat that as an Internet facing device it needs to be very secure and setup correctly before going into production use.

Azure Load Balancers and Multiple Frontends

I could easily place my F5 at the edge of my network, give it a public IP (or a few) and point my DNS to those IPs except this is quickly becoming a single point of failure so I need the Azure Load Balancer again. However, it will now be a public load balancer and a such I cannot use the HA Ports option used previously but I can make use of ALB Rules and port translation.

Putting this together with multiple frontend public IPs I can have as many external IPs and services as I need (Azure resource limits apply).

To get this setup each frontend IP will have two rules, HTTP and HTTPS which both translate the port to something higher up the available ports range, for instance:

• 80 -> 8080
• 443 -> 8443

On my F5 this translated port becomes the listening port of the Virtual Server. The IP will always be the default IP supplied to the F5 by Azure, I no longer need to have a seperate IP range because I am now using different ports and the range of available ports is more than enough to manage even the heaviest workloads.

The important thing to remember is the communication between Azure Load Balancer and F5 can be any port but the communication betweent the F5 and the application servers is unchanged so application changes are not necessary at any stage.

With all of this in place, external users can access my web services without ever knowing the port translation is taking place and I have a highly available service with as many F5 appliances as I need.. as long as configuration sync between them has been enabled.

Useful Links:

• BIG-IP VE in Microsoft Azure
• Microsoft Azure: Single NIC config sync
• How I did It #2 — “Assigning Multiple Public IPs to an Azure-hosted BIG-IP” DevCentral