- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
08-21-2020 05:01 PM
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?
08-25-2020 06:41 AM
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)
08-25-2020 11:13 AM
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.
08-25-2020 11:19 AM
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
08-25-2020 11:49 AM
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.
08-25-2020 04:49 PM
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.
08-25-2020 10:20 PM
Yes, I think that's the case
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!