Azure Palo Alto VM to campus network via ExpressRoute

Reply
Highlighted
L1 Bithead

Azure Palo Alto VM to campus network via ExpressRoute

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!


Accepted Solutions
Highlighted
L2 Linker

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.

View solution in original post


All Replies
Highlighted
L2 Linker

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.

View solution in original post

Highlighted
L1 Bithead

@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

 

 

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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 Live Community as a whole!

The Live Community thanks you for your participation!