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.

[madu1]

To add to this, do you or @the_rock have any thoughts on an issue I have?

I've inherited a firewall with two ISP circuits.  ISP Redundancy is on, but on that page the "Apply settings to VPN traffic" is NOT ticked.

In IPSec VPN > Link Selection, I have Use Probing > HA set.  Within there it has "Probe using the following addresses" with ISP1, ISP2 and another internal interface which is used for a VPN tunnel.

Recently I've added a 3rd ISP line.  I've added this to ISP Redundancy and failover works (browsing out to the Internet works via the 3rd ISP line).  But VPN tunnels are not coming up.

The 3rd party we tested with have changed their end to use my new peer IP (ISP 3).

Unfortunately at the time we tested we didn't have enough time to properly troubleshoot, so I'm trying to guess why it didn't work ready for the next time I try a failover.  I vaguely recall seeing IKE arriving from the 3rd party to the ISP 3 IP, but my firewall wasn't replying to it (I think that's what happened?)

Could the reason for VPN failing be due to either:

• the ISP Redundancy VPN tick box not being ticked?
• The IPSec Link Selection probing not having the new ISP 3 address in the probing list?

Might it work if I updated one of the above options?

Might it work if I changed the probing to "Probe all addresses..."?  What are the pros and cons of probing all addresses vs listing the IPs which are known to participate in VPNs?

As soon as the 3rd party changed the peer IP back to my ISP 1 IP the tunnel came straight back up, so I'm guessing one of the options above is what's causing VPNs on ISP 3 to fail?

[the_rock]

You got it, thats exactly it. You need to check that setting " Apply settings to VPN traffic"

Andy

[madu1]

Spot on, thanks Andy.  I'll give that a try on the next testing window!

[the_rock]

Of course, any time. Message me directly if you need help. I worked many hours on this with customer few years ago and CP escalations, so I am very familiar with the process.

Andy

[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.