Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
B_P
Advisor
Jump to solution

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

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

0 Kudos
1 Solution

Accepted Solutions
B_P
Advisor

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

View solution in original post

10 Replies
the_rock
Legend
Legend

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?

0 Kudos
B_P
Advisor

It's an Active/Passive HA cluster.

0 Kudos
the_rock
Legend
Legend

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

0 Kudos
B_P
Advisor

@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)".

0 Kudos
Chris_Atkinson
Employee Employee
Employee

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?

CCSM R77/R80/ELITE
0 Kudos
B_P
Advisor

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.

0 Kudos
B_P
Advisor

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
Legend
Legend

Thanks for sharing!

0 Kudos
CheckPointerXL
Advisor

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?

0 Kudos
B_P
Advisor

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.

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events