- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
08-10-2017 05:53 AM
Hi Team,
I am new to Paloalto and have some queries with regards to deployment of Paloalto on VM series Firewall on Azure.
Upon search we found
> The VM-Series firewall in Azure does not support native VM Monitoring capabilities for virtual machines that are hosted in Azure.
> VM-Series high availability configuration is not supported to avoid downtime during plannned/unplanned maintainance.
The way of solution is to have Azure application gateway in front of the VM series firewall
Queries that i had in mind:
1. If HA cannot be configured between the VM's( that might be 2 or 3) that are deployed in the VM Series firewall, how the configurations gets replicated between the firewall running on separate VM's?
2. How is the session state maintained when a connection is initiated from App gateway?
3. We want user defined routing between subnets and next hop should pass through Paloalto firewall (internal subnet- Trusted). What is the next hop address that we put if each VM in the VM series firewall with Paloalto holds a different IP address?
Refer to the subnet example in the link below
Thanks in advance
08-10-2017 04:34 PM
There are several options for high availability in Azure. Check out our cloud integration page and expand the Azure section for some examples: https://live.paloaltonetworks.com/t5/Public-Cloud-Integration/ct-p/Cloud_Templates
Firewall configurations can by synchronized accross multiple firewalls using:
We don't maintain session state in the public cloud as most cloud applications are designed to handle state and the infrastructure is stateless. This is true of other services as well like load balancers in Azure.
If you want to have redundant firewalls for security between subnets, you will need to either:
Follow the link above for examples.
08-10-2017 10:29 PM
Hi Warby, thanks for the prompt response.
======================================
Firewall configurations can by synchronized accross multiple firewalls using:
======================================
I do need some clarity on the above. Following is what I have understood:
Is my understanding correct. Also, please share any configuration guide for the same, if available.
08-26-2017 03:05 PM - edited 08-26-2017 03:06 PM
Either Ansible (using our API) or Panorama can keep the configs in synch post deployment (while the firewall is running.)
03-08-2018 06:28 AM
Hi Warby,
The subnet requirements for VM series as mentioned below
CIDR block 192.168.0.0/16, and allocates five subnets (192.168.1.0/24 - 192.168.5.0/24) for deploying the Azure Application Gateway, the VM-Series firewalls, the Azure load balancer and the web servers.
Question:
Is it a mandate to have 19.168.x.x/24 (subnet ./24) or we can use (/30) subnet as it will consume 1 IP for external NIC, internal nic, management nic?
03-08-2018 07:26 AM
Azure reserves the first 3 IP addresses for Azure services and /29 is the smallest allowed mask leaving only 3 usable in the subnet, 2 of which will be assigned to the firewalls. There are times where you may wish to bring up a new pair of firewalls in parallel and you will not have enough IPs to do so.
https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-faq
05-17-2018 01:53 PM
We actually used 2 pairs of firewalls for our Azure deployment. One pair is North-South and the other is East-West monitoring. We used Standard SKU load balancers to make a "HA" solution. It is important to note that you have to have a LB on the trust and untrus side for this configuration. With the Standard SKU vs Basic SKU, you are able to select "HA Ports" meaning you don't have to specifcally call out the ports for the load balancers to forward traffic to the Firewalls. For routing, all on-prem traffic went to one pair of firewalls and Internet went to the other.
Our UDR looks like this:
Trust vNets:
From Any to 172.x.x.x/x goes to EW Trusted Load balancer (one for each vNet)
0.0.0.0/0 goes to NS Trusted Load balancer.
Untrust vNet:
From 172.x.x.x/x To 192.168.x.x/x goes to EW Untrust Load Balancer
06-25-2018 01:30 PM
Hi ebrookman,
are you using the basic sku load balancer to handle east-west monitoring?
If you dont mind how did you configure the "basic sku" load balancer to handle all the ports that might be required for east-west monitoring? Say all the dynamic high level ports for instance?
Thanks,
R
06-25-2018 01:37 PM
We started using the basic load balancers, but found out that you would have to declare all ports that will be used. By using the Standard Load Balancers, you can use what they call "HA Ports" which is just dynamic port mapping.
06-25-2018 05:32 PM
Thank you.
In our instance the, since we are in Azure Gov, the standard load balancer is not available as of yet so we have to lived with the limitations of the basic load balancers for the time being. I'm wondering how other users handles the requirements for example for Active Directory dynamic ports like a range of 49152 - 65535 TCP? How do you define that in the basic load balancer? Is there a need to?
06-25-2018 06:12 PM
Hi,
How did you able to set backend pool on Azure Gov? I heard that there is no availability set on Azure Gov.
I build a basic LB but not able to select both firewalls since I'm not able to build both firewalls on an availabilty set.
Then I have same questions, how to set a rule with dynamic ports on basic LB.
07-26-2018 10:47 AM
On the dynamic ports, you have to use the standard sku LB. The firewalls are set up in the backend pool, but aren't in an av set with each other. As the last post here states, there are a lot of restrictions based on Azure not PA.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!