GWLB Sub-Interface

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

GWLB Sub-Interface

L3 Networker



Question about GWLB and sub-interface mapping.  If I have 2 VPCs (VPC-Shared and VPC-Production) and I associate VPC-Shared with a GWLB Endpoint to sub-interface e1/1.100 on a zone also named VPC-Shared and VPC-Production with an endpoint to e1/1.200 on zone called VPC-Production. 


When I send traffic from the VPC-Production to VPC-Shared, in the security log, shouldn't the source zone show as VPC-Production and destination zone should be VPC-Shared?




Hi @securehops ,

Unfortunately this is not the way that GWLB works...When you enable GWLB inspection on the firewall it will always use the GENEVE protocol information to send the traffic back to the GWLBe it received the traffic and will never make route lookup to route traffic to different interface.

In addition the sub interfaces are not even used for routing, they are only used for zone mapping.


So if you associate VPCs with different GWLBe and have those mapped with different zones, traffic will still be intra-zone from firewall point of view. Because with GENEVE encapsulation inspection firewall will always return the packet to the GWLBe it received it.

I also don't think that in this case you will have inter-vpc traffic working... Because the return traffic will go to the second GWLBe, which is associated with different zone and probably FW will not match this traffic as return traffic for the original request.

Hi @aleksandar.astardzhiev 


Thank you for the reply, I get what you're saying but I have some questions.  I understood that GWLB will send data back to the endpoint it came from and that the sub-interfaces are not used for routing. 100% agree there.  The routing is all handled through the AWS subnet route tables and TGW route tables.  However, you mentioned "In addition the sub interfaces are not even used for routing, they are only used for zone mapping"  This is exactly what I need it for.  I was only trying to use the sub-interfaces to help create firewall policy rules.


In this Palo Alto doc, shows exactly what I'm trying to do.  It does mention east/west.  So in this design, I'd like to create specific fw rules for traffic between APP VPC 1 and APP VPC 2.  I'm not trying to make routing decisions, I'm only trying to make policies based on this traffic.   How would I accomplish this?

Hey @securehops ,

Document explain that you can have different GWLBe for Outbound and East-West traffic, for the same reason - more control over the rules and easier to create different rules for outbound and east-west. But this is only to differenciated between outbound and east-west (any east-west).


They key element is that both (outbound and east-west) are stil intra-zone traffic, once the firewall receive packet from one of the GWLBe it will return it back to the exact same GWLBe it came from. But in this case both VPC are associated with same East-West GWLBe, which means the rule for traffic between the two VPC will still be intra-zone traffic with source and destination the east-west zone (associated with east-west GWLBe).


Lets breakdown the architecture from the document:

- The decision which GWLBe to be used is dictated by the routing table of the TGW attachment in the security hub vpc. Based on the destination IP address traffic will be routed to one of the GWLBe, let say VPC-Prod GWLBe (if we use your idea).

- Once the traffic is forwarded to that specific GWLBe it encapsulate the packet with GENEVE protocol and send it to the firewall. There FW will decapsulate it and use that information to map the traffic with given zone. Let say it will use zone "VPC-Prod" for source zone

- Because traffic is received by GENEVE protocol FW will not perform route lookup to determine the destination zone, but instead will automatically use the source zone for destination as well. After it inspect the packet it will encapsulate it again and return it to the exact same GWLBe in this case VPC-Prod

- Once the GWLBe "VPC-Prod" receive the traffic back it will remove the GENEVE again and use its own routing tabel to further forward the traffic. 

- Traffic will be forwarded to TGW and more specifically the TGW route table associated with the attachment in security hub vpc. From there it should be clear how the traffic will reach the target.


Let say the traffic have reached the destination and it has generated reply

- This reply will be forwarded to TGW and using the TGW route table will be forwarded to that attachment in the security hub vpc

- There it again will look the routing table to decide which GWLBe to use. And if you decide to point it to different endpoint, let say VPC-Shared, as you can imagine this will be forwarded to the firewall under different source zone, which will not match the session created by the original request and it will treat it as new session.

- But even if somehow the firewall to allow this traffic (if it is TCP will drop it, but probably ICMP and UDP may still pass through as those are stateless protocols), this traffic will still be treated as intra-zone traffic and destination zone will be the same as the source.


I hope this make it more clear...

You can separate East-West from Outbound traffic, following the design from the link, but you still need to create intra-zone rules for allowing this traffic. And in addition it is hard for me to imagine a way you can further separate east-west traffic based on the VPCs. All VPCs (and vpn to on-prem) needs to be routed/associated with the same GWLBe in order to have symmetric routing.





Thank you again for response.  It's getting clearer.  If I'm understanding correctly,  if I have 5 VPCs  (workloads) + 1 Security VPC(FWs),  each of the 5 VPCs will have their own GWLBe,  and the security VPC will have two GWLBe (one for outbound and one for east/west).

All 5 VPCs should map to the same sub-interface and I should probably call that firewall zone "east-west"


For firewall policy rule creation for things I need to limit/inspect,  I should do source zone east-west, source address x.x.x.x,  destination zone east-west, destination address x.x.x.x


Continuing with that logic, if I understand correct, then I should assume if an EC2 instance in VPC-A is going to the internet,  I should expect to see on the firewall logs source zone outbound, destination zone outbound?


I just want to mention that in my security VPC, I was not creating multiple GWLBe, for each zone.  In case that wasn't clear.  



Hi @securehops 

As you can see from the document earlier one design it to use TGW for sending traffic between VPCs. In this case outbound and east-west traffic will require GWLBe (east-west and outbound) only in the Security VPC. GWLBe in each workload VPC is required only for inbound traffic (which I think we don't discuss at the moment).


The GWLBe in the workload VPCs are used only for inbound traffic and if you want you can associate each one with different zone. Those zones you will use for intra-zone rules for inbound traffic (or you can associated all inbound GWLBe with single zone)


About the rule examples you are absolutely right:

- Any traffic between VPCs should be intra-zone rule with "east-west" zone specifing source and destination addresses

- Any Outbound traffic to internet should be intra-zone rule with "outbound" zone and specifing source and destination addresses. In this case you also don't configure NAT on the firewall, it is done by AWS with NAT GW.



Not sure if you already have check this, but I would suggest you to go over these documents -

Check first AWS Reference Architecture Guide - Palo Alto Networks which describe the possible architectures based on your requirements

After that you can check the specific deployment guide which again give some explanation about the design and then give detailed deployment steps.








Appreciate your help on this.  This makes a lot more sense now.   I'm clear on the east/west functionality.


I did go through the architecture guide but I suppose I missed some details.  I will revisit, as one item still doesn't make sense.  If I have a workload in VPC-A that has a public elastic IP assigned to it, I'm not seeing how I can inspect it with the firewalls in the security VPC before it goes outbound to internet.  I'm thinking outbound would only work if all instances are private and rely on NAT-GW in security VPC to go to internet


Hi @securehops ,

I am fairly new to the public cloud world and still learning. I can only share my personal experiance from the proof of concept that we currently deployed.


Hm it is interesting use case that you mentioned, I haven't though about that...But one way I could imagine (I could be missing something), is to move the public elastic IP away from the EC2 instance and probably associate it with dedicated GWLBe.

- Move the EC2 instance to dedicated subnet.

- Create GWLBe in the VPC-A which will be dedicated outbound for this EC2

- Create route table with default route poining to the GWLBe and associate the EC2 subnet with it

- Create route table with default route pointing to IGW and associate the GWLBe subnet with it

- Associate the public Elastic IP with the GWLBe interface -----> I am not 100% if this step is possible as I haven't try it yet.


In the EC2 instance route table you can still put route for intrer-VPC traffic pointing to TGW attachment and have East-West traffic inspected as well. But if you need to use dedicated public IP for that instance I believe you need to at least put it in separate subnet.


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!