- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
03-26-2014 08:38 AM
Hello All,
I have a support case open with PAN but I thought I would query others smarter than I.
I first noticed an issue when configuring an SSL-portal using a Floating IP. It seems as though only the session owner can communicate with it's preferred floating IP.
Example 1:
Client A -> 0.0.0.0/0 -> active-primary -> https://x.x.x.129 = WORKS!
Client A -> 0.0.0.0/0 -> active-primary -> https://x.x.x.128 = FAIL
Example 2:
Client A -> 0.0.0.0/0 -> active-secondary -> https://x.x.x.129 = FAIL
Client A -> 0.0.0.0/0 -> active-secondary -> https://x.x.x.128 = WORKS!
From these examples, only the session owner can communicate with its respective floating IP. I have also seen where IPSec tunnels that terminated to ONLY the Active-Primary are having intermittent issues with communicating with internal hosts. All outbound and inbound NAT'd traffic seems to be doing wonderfully, just sessions that terminate to the firewalls themselves seem to be having issues.
I have a drawing that I can share if anyone shows interest in helping me troubleshoot. I'm at a loss and been at if for 4 days.
TIA!
04-07-2014 01:30 PM
Gonna answer this one myself. After talking with PA support, traffic destined to a Floating IP through it's peer was never designed to go through HA3 packet forwarding. It is assumed that the owner of the Floating IP would always get the traffic first via ARP and the virtual mac. In my situation, I have two /29 that communicate with the upstream ISP routers and I was attempting to use one of my /24 (BGP routed) IPs as a floater. I was wanting to use the Floating IP as a signal point of entry for S2S VPNs. Because of asymmetric routing and BGP, there was no way to guarantee that the Floating IP owner would 100% always receive the packet.
I'm working around this issue for now and just using a /30 that is ALWAYS statically routed to one device. But I'm still having IPSec VPN problems, but that's another post. Hope this helps someone.
04-07-2014 01:30 PM
Gonna answer this one myself. After talking with PA support, traffic destined to a Floating IP through it's peer was never designed to go through HA3 packet forwarding. It is assumed that the owner of the Floating IP would always get the traffic first via ARP and the virtual mac. In my situation, I have two /29 that communicate with the upstream ISP routers and I was attempting to use one of my /24 (BGP routed) IPs as a floater. I was wanting to use the Floating IP as a signal point of entry for S2S VPNs. Because of asymmetric routing and BGP, there was no way to guarantee that the Floating IP owner would 100% always receive the packet.
I'm working around this issue for now and just using a /30 that is ALWAYS statically routed to one device. But I'm still having IPSec VPN problems, but that's another post. Hope this helps someone.
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!