Palo Alto Azure - second trust interface routing issue

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Palo Alto Azure - second trust interface routing issue

L2 Linker

Hello to all,

 

I am doing a lab in Azure with a VM-300. I have the three interfaces - trust, management, and untrust. I have this model working  to protect 2 additional subnets that have VMs, I achieved east-west and north south protection, including microsegmentation. However, I was wondering if I can add a new interface to control security policies by zones (currently I will ahve to specify the sunet address). I added a NIC on a new subnet and after reboot the PA has a third interface (trust2), and with other subnet that have VMs in in and emulated what I did with the trust interface.

 

Problem is that I am seeing traffic going through the firewall, but is not returning back (no reply).. I think it might be a routing issue in Azure UDR however they seem fine to me.. See below for my Azure UDRs and PAN VR. Can someone tell me if they have achieved this configuration and possiblity where my issue is? Let me know if you need a network diagram, iI can do one

and add it. From below, I am trying RDP connection from LAN2 to LAN3 subnet:

 

10.1.2.4 - trust interface ip on Palo Alto VM

10.1.6.4 - trust2 interface ip on Palo Alto VM

 

Azure trust subnet (FW trust interface):

route FW trust interface.png

 

Azure LAN subnet (first subnet to be protected by trust):

LAN routes.png

 

Azure LAN2 subnet (second subnet to be protected by trust):

LAN2 routes comm with LAN3.png

 

Trust2 subnet (FW trust2 interface):

trust 2 route.png

 

Azure LAN3 subnet (subnet to be protected by trust 2 FW interface):

LAN3 route.png

 

Palo Alto VR:

Palo Alto VR.png

 

Log:

log traffic.png

 

@reaper - (I really like your posts! 🙂 ) Please take a look.

@jdelio  your posts too!

 

Thanks in advance!

 

 

1 accepted solution

Accepted Solutions

L4 Transporter

While it is possible, I would not recommend going this route.

 

To make it work, you need to be diligent in ensuring your UDRs point to the correct firewall IP for the bidirectional traffic. One thing that jumps out at me is that your VR is utilizing E1/3 interface for the Trust 2 routes but you do not have E1/2 specified for the Trust 1 routes.

 

Another common issue is that manually added Azure Interfaces typically do not have IP Forwarding Enabled in the IP config.  Check this on your E1/3 and E1/2 interfaces.

 

With that said, this model does not hold true when you introduce the Internal LB with HA Ports for Fault Tolerance and Scalability.  In order to introduce this model, a single LB Front End IP and single Interface per Firewall needs to be used for all East/West/Hybrid routes to ensure symmetric routing and persistence due to Azure's hashing algorythm.  This results in Security Policies that are subnet based and not zone based.

 

You can use the Transit VNET template as an example.

https://github.com/PaloAltoNetworks/Azure-Transit-VNet/tree/master/Azure-Transit-VNET-1.0

 

View solution in original post

5 REPLIES 5

L4 Transporter

While it is possible, I would not recommend going this route.

 

To make it work, you need to be diligent in ensuring your UDRs point to the correct firewall IP for the bidirectional traffic. One thing that jumps out at me is that your VR is utilizing E1/3 interface for the Trust 2 routes but you do not have E1/2 specified for the Trust 1 routes.

 

Another common issue is that manually added Azure Interfaces typically do not have IP Forwarding Enabled in the IP config.  Check this on your E1/3 and E1/2 interfaces.

 

With that said, this model does not hold true when you introduce the Internal LB with HA Ports for Fault Tolerance and Scalability.  In order to introduce this model, a single LB Front End IP and single Interface per Firewall needs to be used for all East/West/Hybrid routes to ensure symmetric routing and persistence due to Azure's hashing algorythm.  This results in Security Policies that are subnet based and not zone based.

 

You can use the Transit VNET template as an example.

https://github.com/PaloAltoNetworks/Azure-Transit-VNet/tree/master/Azure-Transit-VNET-1.0

 

Hello @jmeurer,

 

Thank you so much for your help!! Looks like the issue was that I did not enabled IP forwarding when I created the Azure NIC for the Palo Alto second trust interface. I also added the interface name for th estatic routes on the Palo Alto VR for better reading.

 

Regarding the model that you are telling me, what will be the recommended arquitecture if I only have one firewall?? All models that I have found on Palo alto documentation seems to be for HA.. Also, is there a use case where I have one firewall that I will want to have load balancers and/or other Azure resource? 

 

Is the model that you told me for HA, or it can be applied to a single firewall? Just want to know possible deployments. I only have one subnet with aroudn 20 servers that I want to protect with a single firewall.

 

Thanks again!

Your model works for single firewall.  My point was more so if you want to consider Fault Tolerance in the design when adding a second firewall.  No need for the added complexity of the load balancers in a single firewall use case.

Thanks for the prompt reply. I see, I will stick with the one interface approach to have the versatility to change to an HA model if needed in the future.

 

Thanks again!

We are running into same issue where in palo alto VM ( NVA)  is deployed in HA on azure using design mentioned below.

https://docs.paloaltonetworks.com/vm-series/9-0/vm-series-deployment/set-up-the-vm-series-firewall-o...

Looks like Palo Alto interface is not routing packet .

I checked routing is fine with azure UDR and on Palo Alto VR ,  issue is only when traffic hits palo alto floating IP interfaces.

Anyone faced same issue ? Basically issue we are facing with HA deployment .

 

 

SD-WAN | Cloud Networking | PCNSE | ICSI CNSS | MCNA | | CCNP | CCSA | SPSP | SPSX | F5-101 |
  • 1 accepted solution
  • 13842 Views
  • 5 replies
  • 1 Likes
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 LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!