- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
05-07-2024 10:37 PM - edited 05-08-2024 08:54 AM
Hi,
I’m using 2 active VM series firewalls for outbound sessions with overlay routing, with GWLB and Transit Gateway (TGW) between the Application VPC and the Security (firewall) VPC. This is working as expected.
Inbound connections fail to establish.
The need for overlay routing is for managing NAT and VPNs on the firewall.
An external (3rd party SAAS) load balancer is used for inbound sessions.
Just one GWLBe is being used inside the Security VPC, for GENEVE encapsulation into the firewall.
I can verify the inbound session attempt mapped to the trusted application subinterface. This is the first (Syn) packet.
I also have pcaps in the application server showing syn-ack (reply) towards the firewall’s trusted IP (the fw is using snat for inbound sessions).
The firewall receives the syn-ack and drops it with “no matching session” reason.
Did anyone have luck with this setup?
Does Overlay routing support inbound and outbound sessions?
06-25-2024 02:35 AM - edited 06-25-2024 02:36 AM
Hey guys, I've been reading this post with interest as I have pretty much the same issue. Slight difference is that traffic I need to NAT comes into the TGW via a site to site vpn before hitting the GWLBe then onto the 2 act/act firewalls. What I can't get my head around at the moment is how this works without removing the load balancing between the 2 firewalls. Any pointers would be much appreciated.
08-24-2024 04:27 PM
I finally did it!
The trick is to have a full mesh of Private Link Geneve sessions. Just register both gateway load balancer endpoints in each firewall and make sure the GWLB has Cross zone LB enabled.
I think the documentation from PAN has 1:1 GWLBe-fw mappings within each Availability Zone and that’s why I was receiving unecapsulated packets over the major interface (not subif) due to the lack of the inter zone Geneve sessions.
Now it works fine and I have full AZ + Firewall fault tolerance.
• Geneve Session 1: GWLBe1 (AZ1) <–> FW1 (AZ1)
• Geneve Session 2: GWLBe1 (AZ1) <–> FW2 (AZ2)
• Geneve Session 3: GWLBe2 (AZ2) <–> FW1 (AZ1)
• Geneve Session 4: GWLBe2 (AZ2) <–> FW2 (AZ2)
Let me know if this helps anyone!
10-22-2024 08:02 AM
VPNs terminate on my public interfaces. I only have 2 NICs: management, private, and public. That's why I wanted to use overlay routing. I also use BGP towards the TGW to manage VPN failover.
10-31-2024 01:04 PM
No, I haven't.
But my inbound sessions don't go through the GWLBe. The firewall just routes through the major interface.
Geneve encapsulation is for outbound sessions only. I don't have a GWLB on the untrusted side.
11-07-2024 03:01 AM - edited 11-07-2024 03:01 AM
@patoil wrote:VR are not needed. You can just use a single VR to be able to share the public interface. Otherwise you'll need an additional interface.
Using a 2 CPU firewall license on a 4 CPU VM might serve as a workaround to enable the use of additional interfaces and address the architectural challenges with GWLB.
It's frustrating when AWS platform constraints result in increased operational costs.
Enhanced Security: The VM Series can inspect all inbound and outbound traffic, providing robust security measures.
Improved Performance: By distributing traffic across multiple instances, GWLB can improve application performance and scalability.
Simplified Network Configuration: Overlay routing simplifies network configuration and reduces the need for complex routing protocols.
Flexible Deployment Options: You can deploy the VM Series in various configurations, such as high availability or failover, to meet your specific needs. gomeet
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!