Global protect and HA3 with session owner as primary device.

Reply
Highlighted
L1 Bithead

Global protect and HA3 with session owner as primary device.

I have an active/active global protect configuration with the session owner set as primary-device.

1 portal

2 gateways

 

I can connect to either PA with the client but traffic will not route outside of the secondary PA. I can ping every interface on the secondary from a connected client. I get a bunch of hits for ha_aa_pktfwd_err_decap on the primary so I know the secondary is encapsulating them but the primary device is not able to de-encapsulate them.

I can set the device to session owner first packet and session setup first packet and everything works. Anything that involves primary-device causes the secondary to not be able to route traffic.


Is this how it is supposed to work with primary-device for session owner or session setup configured?

Highlighted
L7 Applicator

i think that the intended use-case for 'primary-device' for session owner is if all traffic is flowing through the primary by default, and the secondary is there purely to pick up asymmetrically routed packets

 

ipsec doesn't sync flawlessly between devices (upon failover ipsec needs to be reestablished) so this probably causes the primary to have decap issues (because the tunnel is set up on the secondary's SA)

Tom Piens - PANgurus.com
Find my book at amazon.com/dp/1789956374
Highlighted
L1 Bithead

The question is. Is this by design or a limitation of the HA3 interface when running global protect? If want to have both the primary and secondary operating as functional SSL VPN gateways do I have to choose first packet/first packet. Is this literally a requirement that I cannot find in any documentation?

 

Failover works and both gateways work if I run first packet/first packet. When suspending any firewall the VPN switches to the other gateways tunnel and the floating ip moves to the other firewall with only a single ping dropped. If I bring the other firewall back up, the tunnel and floating IP switch back, with only a single ping dropped.

 

If it is setup as primary-device then I have the problem.

Highlighted
L7 Applicator

It's not going to be the ha3 interface, but rather how 2 members of a panw cluster handle ipsec

 

Have you tried forcing ssl instead of using ipsec?

 

If you need a definitive "this is by design" answer, you'll need to reach out to support

 

 

Tom Piens - PANgurus.com
Find my book at amazon.com/dp/1789956374
Highlighted
L1 Bithead

Now it is running SSL VPN with ipsec disabled on the gateway agent/tunnel settings.

From an order of operations perspective I would assume that If I can ping every address on the firewall that I have landed the VPN on then encryption/decryption is happening on that firewall. After encryption/decryption is completed routing which would require session establishment, isn't making it over the HA3 link. Every packet is a packet de encapsulation error for the HA counters. If I send 1000 pings I get 1000 decap errors.

Highlighted
L1 Bithead

I think I verified HA3 as the problem.. The pings I send from the client do traverse the HA3 link. Wireshark shows the packets as 0x7261 protocol which is HA3 communication; furthermore, I can see the packet body of the Microsoft pings (abc...w repeating pattern) so decryption and encryption is being performed by the secondary and is not punted to the primary.

I would be willing to say palo alto does not support any form of active/active encryption on both firewalls where the HA3 link session owner or setup is set as the primary device. At best you can setup a hot standby for encrypted sessions.

Highlighted
L7 Applicator

Yes, I think that's the case

Tom Piens - PANgurus.com
Find my book at amazon.com/dp/1789956374
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!