R81.10 JHF T87 | IPSEC VPN - Secondary Cluster Member Not Receiving VPN Traffic

[B_P]

In an Active/Passive HA cluster, VPN works great with the primary cluster member yet fails to pass traffic for two out of three remote sites when secondary member is active.

• Secondary cluster member, SITE-01-FW02, shows an established IKEv2 IPSEC VPN.
• VPN TU shows refreshing VPN tunnels after dropping peer with "Delete all IPsec+IKE SAs", etc.
• Traffic is encrypted at SITE-01 end and decrypted at SITE-02, yet reverse only shows encrypted at SITE-02 with nothing showing up at SITE-01.

How can a secondary cluster member have issues like this, especially considering the VPN appears to be establishing just fine. Everything else works with it.

*edit: added active/passive ha verbiage

[the_rock]

Nothing would pass through backup cluster member, since no traffic would ever hit standby member anyway. Thats mind you if its HA, or is this load sharing?

[B_P]

It's an Active/Passive HA cluster.

[the_rock]

Let me make sure I understand this properly. So say, just as an example, you have a cluster HA (active/passive), lets call it cp-cluster and say cp01 is master and cp02 is standby. Are you saying that when cp01 is active, all works fine, but if cp02 is active and cp01 is stanby, thats when you have a problem connecting to 2 out of 3 remote sites?

If so, then we would need to run bunch of captures and vpn debugs to figure out why

vpn debug trunc

vpn debug ikeon

-generate some traffic

vpn debug ikeoff

Get ike/elg and vpnd.elg files from $FWDIR.log dir

Also, would not hurt to run fw monitor commands to see what happens with the traffic.

Cheers mate.

Andy

[B_P]

---

@the_rock wrote:

but if cp02 is active and cp01 is stanby, thats when you have a problem connecting to 2 out of 3 remote sites?

---

That's correct. I even saw it where the 3rd site that does work with cp02 would sometimes not work with cp01. The only thing that stood out to me in the vpnd.elg was this

message [tunnel] tnlmon_transmitter_tt_cb: Gateway = 10.80.5.3, type = 1 => Error = 1

This was in site-02 firewall and that IP is the cluster IP for the site-01.

The setup is a IKEv2 VPN and one thing I noticed with 'vpn tu' on the secondary fw is there are a lot of IKEv1 tunnels. Not sure why that is. I also can't drop and re-establish the tunnels with option 7 "Delete all IPsec+IKE SAs for a given peer (GW)".

[Chris_Atkinson]

What "link-selection" settings are configured and is the routing for the peer addresses the same on both cluster members - following default route?

Also is there anything different between the 3 remote sites, are they all the same vendor gateways etc?

[B_P]

Link selection is "Use DNS resolving > Gateway's name and domain". All the routes are the same and all the sites use Check Point gateways.

[B_P · Accepted solution]

I reached out to TAC which pointed to sk180542 which led me to this post:

While the sk article says a hotfix may be necessary, just running the following commands resolved the issue:

1) fw tab -t orig_route_params -x -y

2) vpn tu del all

[the_rock]

Thanks for sharing!

[CheckPointerXL]

sk mentions:

• The orig_route_params file shows the physical IP address of the cluster member instead of the cluster's Virtual IP Address (VIP).

how can we check it?

[B_P]

I got this site from TAC: https://www.browserling.com/tools/hex-to-ip

Paste just one section of numbers in there. So if the output starts with "<c0a80519," paste in just c0a80519 and it will convert to 192.168.5.25.