- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
08-10-2020 01:38 PM
Quick question for the community. I have setup and configured the Palo Alto VM series in Azure. Along with the management interface, the VM has “trust” and “untrust” interfaces. I have basically copied the rules over from our office Palo Alto devices, and my test VM is working great through the Palo Alto VM. However, I’m having a problem that I was wondering if you could help me out with. Here are the details:
* The test VM is on a new subnet, but part of the same VNET.
* I have a static route in the test subnet (in Azure) that basically forces all traffic destined for 0.0.0.0/0 to the trust interface on the Palo Alto VM.
* The idea is for the Palo Alto VM to make all the traffic and routing decisions for IP addresses outside of the Azure VNETs. Addresses within the Azure VNET are handled automatically by Azure VNET routing.
* No issues at all with websites and web services from the test VM. The Palo Alto VM is processing rules correctly from Trust to Untrust zones.
* The issue is connecting back to resources on our corporate campus.
* We have ExpressRoute between our office and Azure, and routes are advertised back to the office via BGP.
* For other VMs and subnets in Azure (that are not going through the Palo Alto Azure VM), I have no problem connecting back to manage the office firewall or other services hosted out of the office.
* I’ve setup a static route in the Palo Alto VM to route traffic intended for the office Palo Alto management IP addresses back through the Trust interface.
* This should send the traffic back through Trust and through the VNET’s routing, which includes the route back to the office via ExpressRoute.
* When I try to manage the NYC firewall, the connection times out. The office firewall log shows "incomplete" for application type. So, the traffic appears to be flowing from the Azure Palo Alto VM to the office Palo Alto, but I can't use it.
* However, I can ping and traceroute back to the office firewall management interface.
* I can also successfully ping and traceroute the test VM in Azure using the office's trust interface via the CLI.
* I’m having the same problem with a service provider’s system that terminates out of our office. I can ping their services’ IP addresses, but I cannot connect to them using the web browser or application.
I must be missing something relatively simple, but I’m not sure what it is. Since I’m routing from Palo Alto (VM) to physical Palo Alto (NYC), do I need some kind of rule on the PA in Azure to allow traffic back in?
Any ideas?
Thanks!
08-10-2020 04:46 PM
Sounds like maybe you have route asymmetry. The path from your test VM subnet to the on-prem networks is routed through the VM-series in Azure but what about the return traffic?
Typically you need to have UDRs in the gateway subnet route table that routes traffic from on-prem networks to protected VNET resources via the VM-series trust interface.
It is also common to explicitly route the on-prem networks in your protected resource subnets and not rely on the default.
Lastly, when you are using a dynamic routing protocol between on-prem and the VNG you need to be mindful of potentially unwanted route propagation to the various VNET subnets that would allow flows that should be inspected to unintentionally bypass the VM-series.
Hope this helps.
08-10-2020 04:46 PM
Sounds like maybe you have route asymmetry. The path from your test VM subnet to the on-prem networks is routed through the VM-series in Azure but what about the return traffic?
Typically you need to have UDRs in the gateway subnet route table that routes traffic from on-prem networks to protected VNET resources via the VM-series trust interface.
It is also common to explicitly route the on-prem networks in your protected resource subnets and not rely on the default.
Lastly, when you are using a dynamic routing protocol between on-prem and the VNG you need to be mindful of potentially unwanted route propagation to the various VNET subnets that would allow flows that should be inspected to unintentionally bypass the VM-series.
Hope this helps.
08-10-2020 07:40 PM
@claudec, bingo!
Indeed, I did have asymmetric routing back to the VM host. Even though the traffic destined for the NYC campus went out the trust interface and traversed the ExpressRoute connection, return traffic was not routing back through the trust interface of the firewall, causing the applications to break. As you mentioned, the solution is to create a route on the GatewaySubnet. The idea that ping tests and traceroutes were both working - even from the trust interface of the campus firewall - was driving me nuts!
Anyway, I created a route table, associated it with the GatewaySubnet, and I created a rule that basically forced all traffic destined for my test server subnet to route back through the trust interface of the firewall. Once I added that, everything worked.
Thanks for the tip!
Rich
11-23-2021 01:57 PM
We are going to have ExpressRoute setup soon and we do want to use Express Route as primary connection back to our On-Prem resources and VPN connection betwen the VM-Series Firewall and our On-Prem Palo Firewalls.
I am thinking about adding a fourth interface on the VM Series Firewall and use that to route traffic to ExpressRoute Gateway.
Will that work?
Thanks
12-01-2021 06:27 AM
I haven't looked at this in a little while, but I don't think a VPN between on-prem PA to Azure virtual PA is a supported or recommended solution due to internal Azure routing practices. The supported solution is to setup an always on VPN between your on-prem PA and a virtual network gateway in Azure. I have that setup, and it's been solid for me.
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!