14 min to read.
Abstract
I have been part of many Azure Landing Zone
implementations in last 1.5 years. Many organizations are already invested on
below security devices –
1. F5
WAF – Web Application Firewall
2. F5
DDoS – Distributed Denial of Service
3. PaloAlto
NGFW – Next-Generation Firewalls
Enterprises have inclination to use same devices on
Azure as well. Not only because they are invested in licenses costs but also on
skillset cost. There are dedicated [paid] teams managing these devices and
logging, monitoring, SOC, incident management, dashboards everything is already
streamlined for them.
This article talks about Azure Architecture
patterns I have seen across many organizations Azure Deployment using F5 WAF,
DDoS and PaloAlto NGFW.
Note - Below I am
considering incoming traffic from internet and outgoing to internet. I am not
talking about Azure-OnPremises connectivity scenario in below architecture
patterns.
Also recommendations as per my experience; deploy the
security devices in dedicated VNET and configure all applications in separate
VNET [Hub-Spoke!].
Azure Architecture Pattern 1
Refer to first pattern on deploying F5, PaloAlto devices
in combination on Azure – [Click on image to get better view].
Pattern 1 Description
1. The
traffic from internet lands on public IP attached to External Standard Load
Balancer [Layer 4] of Azure in front of F5 DDoS VMs.
2. On
External Azure Standard load balancer you can configure inbound public Ips.
These public Ips can be added as per number of applications sitting behind your
internet DMZ.
3. DDoS
Azure VMs are configured as Active-Passive or Active-Standby. At any given
point only single Azure VM of F5 DDoS is serving the incoming requests from
internet.
4. PaloAlto
NGFW VM-Series Azure VMs are configured as active-passive. It has an Azure
Standard internal load balancer in front of it for load balancing and HA
achievement. For monitoring purpose it is required to know incoming source IP
at firewall; therefore we did not perform SNAT on DDoS. However at PaloAlto
VM-Series firewall on Azure we can perform SNAT [if need be].
5. F5
WAF VMs are present behind the PaloAlto NGFW. F5 WAF is also configured in
Active-Active configuration. It has an internal load balancer in front of it
for load balancing and HA achievement.
6. F5
WAF machines do not have any public IP assigned.
Where do we perform SSL Offload?
To inspect incoming traffic; SSL offload is mandatory.
Without SSL Offload packet can’t be inspected/ verified if it is valid traffic
or malicious traffic. Therefore in above Azure Architecture pattern we should
perform SSL Offload on F5 DDoS VMs. Post which you can inspect traffic on
PaloAlto NGFW and F5 WAF.
What if I want to achieve end to end SSL on incoming traffic?
Perform SSL Offload on F5 DDoS Azure VMs. Then let
traffic be inspected on F5 DDoS, PaloAlto NGFW and F5 WAF Azure VMs. On F5 WAF
itself post inspection you re-configure the leaving traffic with new SSL
certificate. So after F5 WAF when traffic goes to application VMs then it will
be accessed over internal private IP communication; over HTTPS. This is end to
end SSL.
How my outbound traffic “generated within my Azure environment” will flow?
In above diagram we have configured/ assigned public IP
directly to one of the Azure PaloAlto VM. So traffic initiated from Application
VMs directly goes to Azure PaloAlto VM and then it goes out to internet. In
this traffic flow, F5 WAF and F5 DDoS Azure VMs do not come in to picture.
Make sure you attach separate public IP to one of NIC of
each PaloAlto Azure VMs.
In case you want to ask 3rd party company to
whitelist your outgoing IP in their firewall; then both Ips of firewall will be
required to whitelisted.
Note - If you fear of
exhausting SNAT ports for Azure PaloAlto VM then you can also configure Azure
NAT gateway in same subnet of PaloAlto NGFW external/ internet interface and
use it for all outbound traffic. I have not tried this but should be pretty
straight forward.
Azure Architecture Pattern 2
Many times customers prefer to use separate public Ips
for inbound and outbound traffic. Separate outbound traffic public IP helps in
whitelisting at their customers end. Example, WoodGrove org has api which will
be called from Azure environment of Contoso company. So WoodGroove will ask
Contoso to provide public IP range from which the api will be called. In this
case Contoso will share the public IP to WoodGroove, specifically attached for
outbound traffic “generated within Azure”.
In above pattern #1, we have public IP attached at the
F5 DDoS Azure LB and also to the PaloAlto NGFW VM-Series. Sometimes customer
do not want any public to be attached other than entry point. This can be
addressed using below pattern. [Click on image to get better view].
Pattern 2 Description
1. The
traffic from internet lands on public IP attached to External Azure Standard
Load Balancer [Layer 4] of Azure in front of F5 DDoS Azure VMs.
2. On
External Azure Standard load balancer you can configure inbound public Ips.
These public Ips can be added as per number of applications sitting behind your
internet DMZ.
3. DDoS
Azure VMs are configured as Active-Passive or Active-Standby. At any given
point only single Azure VM of F5 DDoS is serving the incoming requests from
internet.
4. PaloAlto
NGFW Azure VMs are configured as active-passive. It has an Azure Standard
internal load balancer in front of it for load balancing and HA achievement.
5. F5
WAF VMs are present behind the PaloAlto NGFW. F5 WAF is also configured in
Active-Active / Active-passive configuration. It has an internal load balancer
in front of it for load balancing and HA achievement.
6. F5
WAF and PaloAlto NGFW VMs do not have any public IP assigned.
7. Standard
Azure load balancer attached in front of F5 DDoS also has outbound rules
configured. To know more refer - https://docs.microsoft.com/en-us/azure/load-balancer/outbound-rules#scale.
8. SSL
Offload still happens at F5 DDoS Azure VMs.
9. There
is no SNAT performed for incoming traffic at DDoS therefore source IP is
visible in PaloAlto NGFW Azure VMs.
How my outbound traffic “generated within my Azure environment” will flow?
In above diagram we have configured/ assigned public IP to
External Azure Standard Load Balancer; present in front of F5 DDoS Azure VMs.
Therefore we will need to configure UDR [Azure Route Tables] to make outbound
traffic flow in below sequence –
App VM -> F5 WAF -> PaloAlto NGFW -> F5 DDoS
-> Azure Standard LB -> Internet
In this case, outbound traffic flowing
through F5 WAF and DDoS do not add any value. However as customer requirement
is not to allow any public IP other than entry point; we will have to make
traffic flow through each of the device. Here F5 WAF and DDoS will act only as
pass through for traffic and adding extra hops.
Azure Architecture Pattern 3
When I implemented Azure Landing Zones at financial
organizations many of them asked a variation in above patterns with Proxy
deployment on Azure for Outbound traffic. So for outbound traffic
below can be another architecture pattern where traffic flows as - >
App VMs-> Proxy VMs -> PaloAlto NGFW VMs ->
Internet.
Same approach can also be used for pattern #2 above.
Below is architecture for Pattern # 1 with Proxy – [Click on image to get
better view].
Azure Architecture Pattern 4
While we can have entry point on Azure Internet DMZ Zone
through F5 DDoS BIG IP on Azure VMs; we can achieve the high availability WITHOUT
USING Azure Standard Load Balancer as well.
Refer to below diagram for the same - [Click on image to
get better view].
In above diagram assuming we want to retain Source IP to
Firewall level; we can configure DDoS F5 Azure VMs in Active-Passive.
In the diagram, for F5, in the event of a failover, the
IP configuration is deleted from active device and recreated on that standby device’s
network interface. So your public IP [virtual IP] on which traffic lands remain
same irrespective of which VM is serving the requests.
This failover is API call based failover and well
explained here - Azure(f5.com).
Same API based failover can also be achieved for F5 WAF
device. Also you can keep adding secondary public IP addresses per application
being onboarded behind this DMZ zone.
Azure Architecture Pattern 5
I have many organization using PaloAlto Azure VMs
Firewall for outbound and inbound combined had to use bigger size VMs. There
is another deployment pattern I have seen where separate Azure PaloAlto
Firewalls are used for inbound and outbound.
In this pattern we will need to perform mandatory SNAT at
F5 WAF level to allow return traffic reach to correct destination of F5 WAF and
outbound traffic generated within app layer to reach to outbound PaloAlto Azure
VM. Refer to below diagram for details - [Click on image to get better view].
Here we are having two public Ips attached to one of the
NIC of each of outbound PaloAlto NGFW. So that based on current active VM the
outbound traffic flow outside to internet.
Remember you will need UDR configured in app layer in
such a way that traffic destined to internet will flow to PaloAlto NGFW Azure
VMs and rest of the traffic should flow to F5 WAF.
Is there a way to run F5 BIG-IP DDoS on Azure on entry point in
Active-Active with No SNAT?
If you want to preserve incoming source IP till
firewall/ app layer then SNAT should not be used. If we plan to deploy F5 DDoS
in Active-Active then SNAT is required. Otherwise return traffic does not
understand which was VM devices to be used for return/ response traffic. In
this case source IP of incoming traffic will not be visible to firewall. In
such case many customers take below approach –
1. Configure
SSL Offload on F5 DDoS
2. Configure
F5 DDoS in Active-Active with SNAT.
3. Add
incoming Source IP in X-Forwarded-For [XFF] header.
This is fine if you firewall devices are able to block
incoming malicious IP present in XFF. If not, then Active-Passive will make
more sense.
Should I always have F5 DDoS on front irrespective of order of devices?
DDoS is for protection of traffic coming from internet.
So for internet facing applications, you should always have DDoS in front of
everything.
I see PaloAlto NGFW VM-Series on Azure is mentioned as Active-Standby /
Active-Passive only? Can it work in Active-Active mode?
As of today PaloAlto VM-Series firewall on Azure can not
work in Active-Active mode. Refer to the document for more information - VM-Series
in High Availability (paloaltonetworks.com)
Do we need to perform SNAT on PaloAlto VM-Series Firewall?
If you don’t want to retain source IP forwarded from
DDoS devices beyond PaloAlto NGFW Azure VMs then you can certainly perform SNAT
on PaloAlto VM-Series Firewall Azure VMs. IF you want to retain source incoming
IP till application layer then “Do not” perform SNAT on PaloAlto firewall device.
How to preserve Incoming Source IP of internet till Azure application layer
VMs?
Many organizations require incoming source IP to be
preserved till application layer/ firewall layer for monitoring/ business
requirement/ logging/ audit purpose. If this is the case then you will need to
configure the F5 DDoS Azure VMs in Active-Passive or Active-Standby mode.
This way Source IP of internet is not NATted on F5 DDoS
Azure VMs and it is visible in PaloAlto NGFW layer. If SNAT is configured on
DDoS then PaloAlto NGFW will never see real incoming source IP from internet.
Similarly to preserve the source IP beyond PaloAlto
Azure firewall; you will need to avoid SNAT on PaloAlto Azure VM-Series and F5
WAF devices.
Refer to Pattern 5 which stated how can you have
incoming source IP taken to App layer in XFF header through F5 WAF device. Or
you can simply avoid SNAT n F5 WAF Azure VMs also and you will get source IP as
internet IP in application layer..
Conclusion
There can be many combinations of the security devices
of F5 and PaloAlto on Azure. The above mentioned architecture patterns I have
seen at most of the places on Azure. Hope this article helped to design combination
of F5, PaloAlto on Azure.
If you have any recommendations to make article better,
reach out to me. I will be more than happy to update the article.
Happy NVAs on Azure!
A humble request!
Internet is creating
a lot of digital garbage. If you feel this a quality blog and someone will
definitely get benefited, don't hesitate to hit share button present below.
Your one share will save many precious hours of a developer. Thank you.
Next
Related Posts
Restrict
Azure Firewall access from Owner and Contributors of Azure Portal
Azure
Virtual Machines – real world frequently asked questions – not easily answered.
Acomplex design – Site to Site VPN, VNET Peering and 4 VNETs – how to solve using Azure Firewall?
Azure
VM disk encryption, what should be my approach!
Bypass
onpremises firewall to RDP or SSH into Azure VM
