ISP redundancy/VPN question

[the_rock]

Hey guys,

I really hope someone can clarify this for me, as I find documentation very confusing about it. So, say customer has primary isp link 1.1.1.1 and 2ndary 2.2.2.2 and VPN link selection is set for probing and 1.1.1.1 is set as primary and IPS REDUNDANCY page has option selected to carry settings over to VPN.

Here is my question:

IF say primary link failed, does that mean VPN tunnels with 3rd party devices would still work?

Not trying to be ironic now, but section about 3rd party devices sounds a bit silly to me personally...I mean, OF COURSE encrypted traffic may work or may NOT work, what other option is there? lol

Based on below doc, its not clear at all.

https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_NextGenSecurityGateway_Guide/Topic...

Specially this section:

Note - ISP Redundancy settings override the VPN Link Selection settings.

When ISP Redundancy is enabled, VPN encrypted connections survive a failure of an ISP link -> Does this mean that REGARDLESS if its CP-CP or CP-3rd party VPN tunnel, that IF primary ISP link fails that tunnels will continue to work?

The settings in the ISP Redundancy page override settings in the IPsec VPN > Link Selection page.

Configuring ISP Redundancy for VPN with a Check Point peer

Configuring ISP Redundancy for VPN with a third-party peer

If the VPN peer is not a Check Point Security Gateway, the VPN may fail, or the third-party device may continue to encrypt traffic to a failed ISP link -> Well, which one is it, fail or work? What is that really based on??

• Make sure the third-party VPN peer recognizes encrypted traffic from the secondary ISP link as coming from the Check Point cluster

  

  .

• Change the configuration of ISP Redundancy to not use these Check Point technologies:

  • Use Probing - Makes sure that Link Selection uses another option.

  • The options Load Sharing, Service Based Link Selection, and Route based probing work only on Check Point Security Gateways and Clusters.

    If used, the Security Gateway or Cluster Members use one link to connect to the third-party VPN peer.

    The link with the highest prefix length and lowest metric is used.

[Kryten · Accepted solution]

Complex and confusing topic...I cannot answer everything here, but since I have had some troubles with multiple ISP links and VPN, I can at least answer parts of it.

For VPN connections to 3rd party devices it would be important in this scenario that the other end has both of your ISP IP addresses configured for the Tunnel connection. Otherwise it will not recognize the traffic belonging to that connection when the secondary link is used.
Also the IKE-ID (or VPN-ID or whatever it may be called) might be an issue here. I am not sure how this is handled with ISP-redundancy, but usually CheckPoint will use the IP address determined in the first part of the Link Selection settings as ID, even if the traffic goes out on a different interface with a different IP. Some 3rd party devices (depending also on config I guess) are very strict with that ID and do not accept anything different there. Luckily this can be changed via registry, so it is based on the routing instead of the LinkSelection setting. (see Scenario 2 in sk108600 for that)

So the statement "may work or may NOT work" is true indeed I fear, but the above things should reduce the amount of connections that do NOT work I think 🙂

[the_rock]

Thanks @Kryten , really appreciate your response!! By the way, what I find most confusing is this statement -> When ISP Redundancy is enabled, VPN encrypted connections survive a failure of an ISP link

To me, that clearly states that no matter what, regardless if its cp to cp OR cp to 3rd party VPN tunnel or regular/permanent tunnel, if one ISP link fails, VPN would continue to work...just my own logic and how I read that statement. As far as my other comment, yes, I was being sarcastic, because in reality, its like anything in life...I MAY or may NOT be alive tomorrow, right? haha

Anyway, in all seriousness, I thank you very much for the detailed explanation, it certainly makes sense. I hope though that someone who works for CP will give an official statement on this. Ostensibly, the statements in the document I referred to could be put more precisely.

[PhoneBoy]

One of the functions of Link Selection (whether controlled directly or via the ISP Redundancy settings) is to change the IP used to originate VPN connections from.
On a failover, this is obviously going to have to change for any traffic to pass.
Whether this will work or not depends on the remote end's ability to support such a configuration (basically what @Kryten said).

[the_rock]

Thanks phoneboy. But again, it goes back to my original question...how does one interpret below statement?

When ISP Redundancy is enabled, VPN encrypted connections survive a failure of an ISP link...

To me personally, that statement clearly implies that no matter what type of tunnel it is or vendor, that VPN WILL continue to work.

[PhoneBoy]

The key here is "VPN Encrypted Connections."
The VPN Tunnel will have to be rebuilt once the IP address changes due to failover.
The connection inside the VPN tunnel will survive a failover. 

[the_rock]

Ah, I see...well, I think its worded the wrong way in the document and should be fixed to reflect actual intended behavior.