on
19-Nov-2019
08:27
- edited on
05-Jun-2023
23:06
by
JimmyPackets
I recently had a scenario that required me to do some testing and I thought it would be a good opportunity to share. A user told me that he wants to put BIG-IP in Azure, but he has a few requirements:
Quick side note: Why would we use ALB's when deploying BIG-IP? Isn't that like putting a load balancer in front of a load balancer? In this case we're using the ALB as a basic, Layer 3/4 traffic disaggregator to simply send traffic to multiple BIG-IP appliances and provide failover in the case of a VM-level failure. However we want our traffic to traverse BIG-IP's when we need advanced app services: TLS handling, authentication, advanced health monitoring, sophisticated load balancing methods, etc.
Firstly, I put together a quick demo to easily show him how to deploy BIG-IP behind an ALB. My demo uses an external (internet-facing) ALB and an internal ALB. It is based on the official template provided by F5, but additionally deploys an app server and configures the BIG-IP's with a route and an AS3 declaration. If it wasn't for the internal-only part, we would have met his requirements with this set up:
However, this user's case requires no internet-facing BIG-IP. And now we hit 2 problems:
NetworkInterfacesInAvailabilitySetUseMultipleLoadBalancersOfSameType
. So the diagram above cannot be re-created with 2x Internal Azure LB's.should only have one inbound rule if that rule loadbalances across all ports and protocols.
” Since we want at least 1 rule for all ports (for outbound traffic from server), we cannot also have individual LB rules for our apps. Trying to do so will fail with the error message in quotes.This leaves us with a few options. We can meet most of his requirements but one that I have not been able to overcome is this: if your cluster of BIG-IP's is Active/Active, you will need to SourceNAT traffic to ensure the response traffic traverses the same BIG-IP. I'll discuss three options and how they meet the requirements.
Personally, I'd recommend in this case to proceed with Option C below. I'd also point out:
There are multiple ways to deploy BIG-IP when your requirements dictate an architecture that is not deployed by default. By keeping in mind my priorities of application services, operational support and high availability, you can decide on the best architecture for a given scenario.
Thanks for reading, and let me know if you have any questions.
Hoping this article and the diagrams can help out those looking to use Azure internal load balancer. Please leave a comment if you have any questions or feedback on this article.
Hi this article is useful for understanding. Can you please share the ARM template for Option B and Option A ? waiting for your kind response.
I have the same scenerio. I dont want to expose F5 WAF directly to the Internet. my WAF will be behind Perimeter firewall. Kindly advise
sajid.khan@qdsnet.com
I would like to share some points related to our scenario.
In Our case, we have an Internet-facing firewall that will proxy inbound traffic to BIGIP (in our case, there is no need to expose BIG-IP to the Internet).
We would like to run BIG IP pair Active/Active but could also run Active/Standby based on your suggestion
we do not want to automate the update of Azure routes at the time of failover
We want to use an Azure Load Balancer (ALB) to ensure HA for our BIG-IP pair. This makes failover times faster in Azure as compared to other options like API. (Please correct me if I am wrong)
Also, we would like to access both F5 pair separately using out of band management.
Based on our use case can you please share the custom ARM template that would help us to deploy BIG IP as per our scenario
Hi Sajid,
Here's a template that will deploy a perimeter firewall and F5 WAF behind it. There's a diagram in the ReadMe that shows the architecture of what will be deployed.
https://github.com/mikeoleary/azure-f5-palo
Here is a devcentral article that explains the demo too.
https://devcentral.f5.com/s/articles/Deploy-F5-and-PaloAlto-in-Azure-with-this-demo
Can you let me know if this helps you? -Mike.
Hi Micheal,
First of All I am really thankful to you for such a nice informative article and second thanks for the reply.
let me check this template and will update you asap.
if I use this same template and after the deployment if i delete the Palo Alto VMs i think this will work for me as well please correct me if i am wrong
Also I have tested just now In this template how Can I assign Existing Vnets and subnets as per our environment ?
Hi Sajid,
If you have an existing VNET, I recommend you start with a template from F5 Networks' official repo. This does deploy an External Azure Load Balancer, but you could edit the template to deploy an internal load balancer. Assuming you want an HA pair of 3-NIC devices licensed via BYOL into an existing VNET, this is the template I recommend starting with:
You might deploy this template and then delete the external Load Balancer and deploy an internal Load Balancer instead, if you are uncomfortable with editing a template yourself. I am unable to customize a template specifically for your individual situation.
Does that make sense? You could also ask your F5 account about professional services if you need.
Dear Micheal,
Thanks alot for your such a kind support. I will try this and will update you in accordingly
Dear Micheal,
I have test the Template and it is deployed successfully in my lab environment. Currently for testing purpose I have use PayAG template. Also I have deleted the External Load-Balancer, After deleting the external load balancer I was still able to access both BIGIPs via management Public IP.
As I have deleted the external Load-Balancer now it will look Like an option A right ?
for Option A you have mentioned source Nat is required I have confusion in which LB i have to Source NAT on F5 BIG or Azure LB ?
Hi Sajid,
Fair qu. Now that you've deleted the external LB, you'll want to replace it with an internal LB. Also, if this is in your existing network, you may want to remove the public IP addresses from the mgmt interfaces. You'll have to SourceNAT on the F5 BIG-IP if you don't want to dynamically update routes on failover.
Hey Michael,
How did you get the alien range to work as you mentioned in the "Advanced Use Cases (Not Pictured)" - bullet 2?
My current setup:
2x F5 active/active - 2 nics (Mgmt and Dataplane)
1x ILB with HA Ports LB Rule and Floating IP Enabled (to avoid the destination NAT performed by ILB as you mentioned)
Route Table on Web Subnet with route default all traffic to the FEIP of the ILB (for symetric routing)
Route Table on Client Subnet with route to alien range and next hop as FEIP of the ILB (as above)
VIP on F5 within the alien range (and the range does not exist within Azure)
My reasoning for wanting to get this to work is without it I can have an Active/Active setup without SNAT but only with 1 Web Server or performing destination port nat (via VIPs) on the same secondary IPs of the F5's due to the HA Ports rule on the ILB. However, if I can get the alien range to work then I can have Active/Active F5's without SNAT for multiple web applications behind the same pair of F5's without having to perform destination port nat.
Unfortunately, all my stats are 0 when trying the alien range which tells me Azure isn't even sending my packets to the F5. My assumption is that a firewall would have to be used in the scanario to perform destination NAT of the alien range to the front end ip of the LB.
Thanks for your help