GWLB and Palo Alto Zones

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

GWLB and Palo Alto Zones

L1 Bithead

I am building some PA VM's behind GWLB.

 

i would like to do traffic between VPC's to flow through this GWLB and TGW which appears to be possible however i can not find any documentation on how to seperate these into different Zones within the palo. I would like the Traffic from VPC A and VPC B to be mapped to different Palo Alto Zones. I was told this is possible but can't find any reference.

1 accepted solution

Accepted Solutions

L2 Linker

The zoning capabilities is dependant on the traffic direction. 

 

Inbound, we have the ability to map GWLBe's from the various inbound VPCs to a subInterface.  This traffic will still be Intrazone, but you can have each VPC in its own zone.

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

 

Outbound, we added the ability to route traffic outbound out of an Untrust interface using Overlay routing in 10.0.5.  This allows for the creation of the traditional Trust->Untrust style policy. 

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

 

East-West, VPC to VPC communication through a TGW deployment cannot be broken into zones.  This traffic must hairpin back to the GWLB for routing.  This traffic will continue to be Intrazone and your policies will need to be DAG or Subnet based.

View solution in original post

4 REPLIES 4

L2 Linker

The zoning capabilities is dependant on the traffic direction. 

 

Inbound, we have the ability to map GWLBe's from the various inbound VPCs to a subInterface.  This traffic will still be Intrazone, but you can have each VPC in its own zone.

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

 

Outbound, we added the ability to route traffic outbound out of an Untrust interface using Overlay routing in 10.0.5.  This allows for the creation of the traditional Trust->Untrust style policy. 

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

 

East-West, VPC to VPC communication through a TGW deployment cannot be broken into zones.  This traffic must hairpin back to the GWLB for routing.  This traffic will continue to be Intrazone and your policies will need to be DAG or Subnet based.

Is there any reason to map the VPC's to zones for inbound then if i can't create zone based policies?

 

are you stating that if VPC A is sending traffic to VPC B the palo will recognize the inbound as coming from Zone A but will send it out "Zone A" because it hairpins. so i just couldnt define destination zones but i could still utilize source zone?

 

The purpose for the Zones in an inbound flow is to handle the possibility of overlapping IP schemes when not using TGW.  Diagrams for this flow are here.  https://live.paloaltonetworks.com/t5/vm-series-in-the-public-cloud/aws-vm-series-gateway-load-balanc...

 

In VPC to VPC communication the traffic is as follows.  This traffic flow hairpins back to the GWLBe before routing back to the TGW.  This traffic must stay within the GENEVE encapsulation tunnel to maintain the 5-tuple perisistence that the GWLB performs.

VPCa -> TGW -> Firewall VPC -> GWLBe -> firewalls -> GWLBe -> tgw -> VPCb

Awesome!! Thank you so much for your help that put a light on a lot of things.

  • 1 accepted solution
  • 5218 Views
  • 4 replies
  • 0 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!