<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: ISP redundancy/VPN question in Firewall and Security Management</title>
    <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/ISP-redundancy-VPN-question/m-p/237675#M46151</link>
    <description>&lt;P&gt;To add to this, do you or&amp;nbsp;&lt;a href="https://community.checkpoint.com/t5/user/viewprofilepage/user-id/38213"&gt;@the_rock&lt;/a&gt;&amp;nbsp;have any thoughts on an issue I have?&lt;/P&gt;&lt;P&gt;I've inherited a firewall with two ISP circuits.&amp;nbsp; ISP Redundancy is on, but on that page the "Apply settings to VPN traffic" is &lt;STRONG&gt;NOT&lt;/STRONG&gt; ticked.&lt;/P&gt;&lt;P&gt;In IPSec VPN &amp;gt; Link Selection, I have Use Probing &amp;gt; HA set.&amp;nbsp; Within there it has "Probe using the following addresses" with ISP1, ISP2 and another internal interface which is used for a VPN tunnel.&lt;/P&gt;&lt;P&gt;Recently I've added a 3rd ISP line.&amp;nbsp; I've added this to ISP Redundancy and failover works (browsing out to the Internet works via the 3rd ISP line).&amp;nbsp; But VPN tunnels are not coming up.&lt;/P&gt;&lt;P&gt;The 3rd party we tested with have changed their end to use my new peer IP (ISP 3).&lt;/P&gt;&lt;P&gt;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.&amp;nbsp; 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?)&lt;/P&gt;&lt;P&gt;Could the reason for VPN failing be due to either:&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;the ISP Redundancy VPN tick box not being ticked?&lt;/LI&gt;&lt;LI&gt;The IPSec Link Selection probing not having the new ISP 3 address in the probing list?&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;Might it work if I updated one of the above options?&lt;/P&gt;&lt;P&gt;Might it work if I changed the probing to "Probe all addresses..."?&amp;nbsp; What are the pros and cons of probing all addresses vs listing the IPs which are known to participate in VPNs?&lt;/P&gt;&lt;P&gt;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?&lt;/P&gt;</description>
    <pubDate>Mon, 06 Jan 2025 13:01:14 GMT</pubDate>
    <dc:creator>madu1</dc:creator>
    <dc:date>2025-01-06T13:01:14Z</dc:date>
    <item>
      <title>ISP redundancy/VPN question</title>
      <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/ISP-redundancy-VPN-question/m-p/161823#M28724</link>
      <description>&lt;P&gt;Hey guys,&lt;/P&gt;
&lt;P&gt;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.&lt;/P&gt;
&lt;P&gt;Here is my question:&lt;/P&gt;
&lt;P&gt;IF say primary link failed, does that mean VPN tunnels with 3rd party devices would still work?&lt;/P&gt;
&lt;P&gt;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&lt;/P&gt;
&lt;P&gt;Based on below doc, its not clear at all.&lt;/P&gt;
&lt;P&gt;&lt;A href="https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_NextGenSecurityGateway_Guide/Topics-FWG/ISP-Redundancy-and-VPN.htm?tocpath=ISP%20Redundancy%20on%20a%20Security%20Gateway%7C_____2" target="_blank" rel="noopener"&gt;https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_NextGenSecurityGateway_Guide/Topics-FWG/ISP-Redundancy-and-VPN.htm?tocpath=ISP%20Redundancy%20on%20a%20Security%20Gateway%7C_____2&lt;/A&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Specially this section:&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;TABLE class="TableStyle-TP_Table_Notes" cellspacing="0"&gt;
&lt;TBODY&gt;
&lt;TR class="TableStyle-TP_Table_Notes-Body-Body"&gt;
&lt;TD class="TableStyle-TP_Table_Notes-BodyA-Column_Style_Text-Body"&gt;
&lt;P&gt;&lt;SPAN class="Note"&gt;Note&lt;/SPAN&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;-&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;SPAN class="mc-variable Vars_BladesFeatures.tp_ispr variable"&gt;ISP Redundancy&lt;/SPAN&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;settings override the&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;SPAN class="Menu_Options"&gt;VPN Link Selection&lt;/SPAN&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;settings.&lt;/P&gt;
&lt;/TD&gt;
&lt;/TR&gt;
&lt;/TBODY&gt;
&lt;/TABLE&gt;
&lt;P&gt;&lt;STRONG&gt;When&amp;nbsp;&lt;SPAN class="mc-variable Vars_BladesFeatures.tp_ispr variable"&gt;ISP Redundancy&lt;/SPAN&gt;&amp;nbsp;is enabled, VPN encrypted connections survive a failure of an ISP link -&amp;gt;&amp;nbsp;&lt;/STRONG&gt;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?&lt;/P&gt;
&lt;P&gt;The settings in the&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;SPAN class="mc-variable Vars_BladesFeatures.tp_ispr variable"&gt;ISP Redundancy&lt;/SPAN&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;page override settings in the&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;SPAN class="Menu_Options"&gt;&lt;SPAN class="mc-variable Vars_BladesFeatures.tp_ipsecvpn variable"&gt;IPsec VPN&lt;/SPAN&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&amp;gt; Link Selection&lt;/SPAN&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;page.&lt;/P&gt;
&lt;DIV class="MCDropDown MCDropDown_Closed dropDown" data-mc-state="closed"&gt;&lt;span class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="the_rock_0-1668113898310.gif" style="width: 400px;"&gt;&lt;img src="https://community.checkpoint.com/t5/image/serverpage/image-id/18366i89B6FD664C5515F1/image-size/medium?v=v2&amp;amp;px=400" role="button" title="the_rock_0-1668113898310.gif" alt="the_rock_0-1668113898310.gif" /&gt;&lt;/span&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;SPAN class="MCDropDownHead dropDownHead"&gt;&lt;A class="MCDropDownHotSpot dropDownHotspot MCDropDownHotSpot_ MCHotSpotImage" role="button" href="https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_NextGenSecurityGateway_Guide/Topics-FWG/ISP-Redundancy-and-VPN.htm?tocpath=ISP%20Redundancy%20on%20a%20Security%20Gateway%7C_____2#" target="_blank" rel="noopener" aria-expanded="false" aria-controls="mc-dropdown-bodye22869eb-7136-4bb7-bf32-287f01decc08"&gt;Configuring&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;SPAN class="mc-variable Vars_BladesFeatures.tp_ispr variable"&gt;ISP Redundancy&lt;/SPAN&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;for VPN with a&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;SPAN class="mc-variable Vars_Other.tp_cp variable"&gt;Check Point&lt;/SPAN&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;peer&lt;/A&gt;&lt;/SPAN&gt;&lt;/DIV&gt;
&lt;DIV class="MCDropDown dropDown MCDropDown_Open" data-mc-state="open"&gt;&lt;span class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="the_rock_1-1668113898313.gif" style="width: 400px;"&gt;&lt;img src="https://community.checkpoint.com/t5/image/serverpage/image-id/18367iC2EEB2584212F7E2/image-size/medium?v=v2&amp;amp;px=400" role="button" title="the_rock_1-1668113898313.gif" alt="the_rock_1-1668113898313.gif" /&gt;&lt;/span&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;SPAN class="MCDropDownHead dropDownHead"&gt;&lt;A class="MCDropDownHotSpot dropDownHotspot MCDropDownHotSpot_ MCHotSpotImage" role="button" href="https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_NextGenSecurityGateway_Guide/Topics-FWG/ISP-Redundancy-and-VPN.htm?tocpath=ISP%20Redundancy%20on%20a%20Security%20Gateway%7C_____2#" target="_blank" rel="noopener" aria-expanded="true" aria-controls="mc-dropdown-body98023fe5-b66d-4dbe-9fb3-a7f591a185a0"&gt;Configuring&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;SPAN class="mc-variable Vars_BladesFeatures.tp_ispr variable"&gt;ISP Redundancy&lt;/SPAN&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;for VPN with a third-party peer&lt;/A&gt;&lt;/SPAN&gt;
&lt;DIV id="mc-dropdown-body98023fe5-b66d-4dbe-9fb3-a7f591a185a0" class="MCDropDownBody dropDownBody"&gt;
&lt;P&gt;&lt;STRONG&gt;If the VPN peer is&amp;nbsp;not&amp;nbsp;a&amp;nbsp;&lt;SPAN class="mc-variable Vars_Other.tp_cp variable"&gt;Check Point&lt;/SPAN&gt;&amp;nbsp;&lt;SPAN class="mc-variable Vars_Other.tp_sgate variable"&gt;Security Gateway&lt;/SPAN&gt;, the VPN may fail, or the third-party device may continue to encrypt traffic to a failed ISP link -&amp;gt;&amp;nbsp;&lt;/STRONG&gt;Well, which one is it, fail or work? What is that really based on??&lt;/P&gt;
&lt;UL&gt;
&lt;LI&gt;
&lt;P&gt;Make sure the third-party VPN peer recognizes encrypted traffic from the secondary ISP link as coming from the&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;SPAN class="mc-variable Vars_Other.tp_cp variable"&gt;Check Point&lt;/SPAN&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;A class="MCTextPopup MCTextPopupHotSpot MCTextPopupHotSpot_ #text MCTextPopup_Closed" role="button" href="https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_NextGenSecurityGateway_Guide/Topics-FWG/ISP-Redundancy-and-VPN.htm?tocpath=ISP%20Redundancy%20on%20a%20Security%20Gateway%7C_____2#" target="_blank" rel="noopener" data-mc-state="closed" data-aria-describedby="176a1635-50bf-435d-9e0c-7aba4da8286d"&gt;cluster&lt;/A&gt;&lt;/P&gt;
&lt;span class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="the_rock_2-1668113898313.gif" style="width: 400px;"&gt;&lt;img src="https://community.checkpoint.com/t5/image/serverpage/image-id/18368i1FE5DCCE9DFF74DC/image-size/medium?v=v2&amp;amp;px=400" role="button" title="the_rock_2-1668113898313.gif" alt="the_rock_2-1668113898313.gif" /&gt;&lt;/span&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;.&lt;/P&gt;
&lt;/LI&gt;
&lt;LI&gt;
&lt;P&gt;Change the configuration of&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;SPAN class="mc-variable Vars_BladesFeatures.tp_ispr variable"&gt;ISP Redundancy&lt;/SPAN&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;to&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;STRONG&gt;not&lt;/STRONG&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;use these&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;SPAN class="mc-variable Vars_Other.tp_cp variable"&gt;Check Point&lt;/SPAN&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;technologies:&lt;/P&gt;
&lt;UL&gt;
&lt;LI&gt;
&lt;P&gt;&lt;SPAN class="Menu_Options"&gt;Use Probing&lt;/SPAN&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;- Makes sure that&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;SPAN class="Menu_Options"&gt;Link Selection&lt;/SPAN&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;uses another option.&lt;/P&gt;
&lt;/LI&gt;
&lt;LI&gt;
&lt;P&gt;The options&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;SPAN class="Variable_Menu_Options mc-variable Vars_BladesFeatures.tp_ls variable"&gt;Load Sharing&lt;/SPAN&gt;,&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;SPAN class="Menu_Options"&gt;Service Based Link Selection&lt;/SPAN&gt;, and&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;SPAN class="Menu_Options"&gt;Route based probing&lt;/SPAN&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;work only on&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;SPAN class="mc-variable Vars_Other.tp_cp variable"&gt;Check Point&lt;/SPAN&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;SPAN class="mc-variable Vars_Other.tp_sgates variable"&gt;Security Gateways&lt;/SPAN&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;and Clusters.&lt;/P&gt;
&lt;P&gt;If used, the&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;SPAN class="mc-variable Vars_Other.tp_sgate variable"&gt;Security Gateway&lt;/SPAN&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;or&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;SPAN class="mc-variable Vars_BladesFeatures.tp_clmbs variable"&gt;Cluster Members&lt;/SPAN&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;use one link to connect to the third-party VPN peer.&lt;/P&gt;
&lt;P&gt;The link with the highest prefix length and lowest metric is used.&lt;/P&gt;
&lt;/LI&gt;
&lt;/UL&gt;
&lt;/LI&gt;
&lt;/UL&gt;
&lt;/DIV&gt;
&lt;/DIV&gt;</description>
      <pubDate>Thu, 10 Nov 2022 22:06:32 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Firewall-and-Security-Management/ISP-redundancy-VPN-question/m-p/161823#M28724</guid>
      <dc:creator>the_rock</dc:creator>
      <dc:date>2022-11-10T22:06:32Z</dc:date>
    </item>
    <item>
      <title>Re: ISP redundancy/VPN question</title>
      <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/ISP-redundancy-VPN-question/m-p/161865#M28734</link>
      <description>&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;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.&lt;BR /&gt;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)&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;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 &lt;span class="lia-unicode-emoji" title=":slightly_smiling_face:"&gt;🙂&lt;/span&gt;&lt;/P&gt;</description>
      <pubDate>Fri, 11 Nov 2022 14:17:15 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Firewall-and-Security-Management/ISP-redundancy-VPN-question/m-p/161865#M28734</guid>
      <dc:creator>Kryten</dc:creator>
      <dc:date>2022-11-11T14:17:15Z</dc:date>
    </item>
    <item>
      <title>Re: ISP redundancy/VPN question</title>
      <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/ISP-redundancy-VPN-question/m-p/161867#M28735</link>
      <description>&lt;P&gt;Thanks&amp;nbsp;&lt;a href="https://community.checkpoint.com/t5/user/viewprofilepage/user-id/71739"&gt;@Kryten&lt;/a&gt;&amp;nbsp;, really appreciate your response!! By the way, what I find most confusing is this statement -&amp;gt;&amp;nbsp;&lt;STRONG&gt;When&amp;nbsp;&lt;SPAN class="mc-variable Vars_BladesFeatures.tp_ispr variable"&gt;ISP Redundancy&lt;/SPAN&gt;&amp;nbsp;is enabled, VPN encrypted connections survive a failure of an ISP link&lt;/STRONG&gt;&lt;/P&gt;
&lt;P&gt;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&lt;/P&gt;
&lt;P&gt;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.&lt;/P&gt;</description>
      <pubDate>Fri, 11 Nov 2022 15:08:04 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Firewall-and-Security-Management/ISP-redundancy-VPN-question/m-p/161867#M28735</guid>
      <dc:creator>the_rock</dc:creator>
      <dc:date>2022-11-11T15:08:04Z</dc:date>
    </item>
    <item>
      <title>Re: ISP redundancy/VPN question</title>
      <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/ISP-redundancy-VPN-question/m-p/161912#M28755</link>
      <description>&lt;P&gt;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.&lt;BR /&gt;On a failover, this is obviously going to have to change for any traffic to pass.&lt;BR /&gt;Whether this will work or not&amp;nbsp;depends on the remote end's ability to support such a configuration (basically what&amp;nbsp;&lt;a href="https://community.checkpoint.com/t5/user/viewprofilepage/user-id/71739"&gt;@Kryten&lt;/a&gt;&amp;nbsp;said).&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Sat, 12 Nov 2022 12:59:31 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Firewall-and-Security-Management/ISP-redundancy-VPN-question/m-p/161912#M28755</guid>
      <dc:creator>PhoneBoy</dc:creator>
      <dc:date>2022-11-12T12:59:31Z</dc:date>
    </item>
    <item>
      <title>Re: ISP redundancy/VPN question</title>
      <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/ISP-redundancy-VPN-question/m-p/161913#M28756</link>
      <description>&lt;P&gt;Thanks phoneboy. But again, it goes back to my original question...how does one interpret below statement?&lt;/P&gt;
&lt;P&gt;&lt;STRONG&gt;When&amp;nbsp;&lt;SPAN class="mc-variable Vars_BladesFeatures.tp_ispr variable"&gt;ISP Redundancy&lt;/SPAN&gt;&amp;nbsp;is enabled, VPN encrypted connections survive a failure of an ISP link...&lt;/STRONG&gt;&lt;/P&gt;
&lt;P&gt;To me personally, that statement clearly implies that no matter what type of tunnel it is or vendor, that VPN &lt;STRONG&gt;WILL &lt;/STRONG&gt;continue to work&lt;STRONG&gt;.&lt;/STRONG&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Sat, 12 Nov 2022 13:33:37 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Firewall-and-Security-Management/ISP-redundancy-VPN-question/m-p/161913#M28756</guid>
      <dc:creator>the_rock</dc:creator>
      <dc:date>2022-11-12T13:33:37Z</dc:date>
    </item>
    <item>
      <title>Re: ISP redundancy/VPN question</title>
      <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/ISP-redundancy-VPN-question/m-p/161921#M28760</link>
      <description>&lt;P&gt;The key here is "VPN Encrypted Connections."&lt;BR /&gt;The VPN Tunnel will have to be rebuilt once the IP address changes due to failover.&lt;BR /&gt;The connection inside the VPN tunnel will survive a failover.&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Sat, 12 Nov 2022 14:55:47 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Firewall-and-Security-Management/ISP-redundancy-VPN-question/m-p/161921#M28760</guid>
      <dc:creator>PhoneBoy</dc:creator>
      <dc:date>2022-11-12T14:55:47Z</dc:date>
    </item>
    <item>
      <title>Re: ISP redundancy/VPN question</title>
      <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/ISP-redundancy-VPN-question/m-p/161922#M28761</link>
      <description>&lt;P&gt;Ah, I see...well, I think its worded the wrong way in the document and should be fixed to reflect actual intended behavior.&lt;/P&gt;</description>
      <pubDate>Sat, 12 Nov 2022 15:52:12 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Firewall-and-Security-Management/ISP-redundancy-VPN-question/m-p/161922#M28761</guid>
      <dc:creator>the_rock</dc:creator>
      <dc:date>2022-11-12T15:52:12Z</dc:date>
    </item>
    <item>
      <title>Re: ISP redundancy/VPN question</title>
      <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/ISP-redundancy-VPN-question/m-p/237675#M46151</link>
      <description>&lt;P&gt;To add to this, do you or&amp;nbsp;&lt;a href="https://community.checkpoint.com/t5/user/viewprofilepage/user-id/38213"&gt;@the_rock&lt;/a&gt;&amp;nbsp;have any thoughts on an issue I have?&lt;/P&gt;&lt;P&gt;I've inherited a firewall with two ISP circuits.&amp;nbsp; ISP Redundancy is on, but on that page the "Apply settings to VPN traffic" is &lt;STRONG&gt;NOT&lt;/STRONG&gt; ticked.&lt;/P&gt;&lt;P&gt;In IPSec VPN &amp;gt; Link Selection, I have Use Probing &amp;gt; HA set.&amp;nbsp; Within there it has "Probe using the following addresses" with ISP1, ISP2 and another internal interface which is used for a VPN tunnel.&lt;/P&gt;&lt;P&gt;Recently I've added a 3rd ISP line.&amp;nbsp; I've added this to ISP Redundancy and failover works (browsing out to the Internet works via the 3rd ISP line).&amp;nbsp; But VPN tunnels are not coming up.&lt;/P&gt;&lt;P&gt;The 3rd party we tested with have changed their end to use my new peer IP (ISP 3).&lt;/P&gt;&lt;P&gt;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.&amp;nbsp; 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?)&lt;/P&gt;&lt;P&gt;Could the reason for VPN failing be due to either:&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;the ISP Redundancy VPN tick box not being ticked?&lt;/LI&gt;&lt;LI&gt;The IPSec Link Selection probing not having the new ISP 3 address in the probing list?&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;Might it work if I updated one of the above options?&lt;/P&gt;&lt;P&gt;Might it work if I changed the probing to "Probe all addresses..."?&amp;nbsp; What are the pros and cons of probing all addresses vs listing the IPs which are known to participate in VPNs?&lt;/P&gt;&lt;P&gt;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?&lt;/P&gt;</description>
      <pubDate>Mon, 06 Jan 2025 13:01:14 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Firewall-and-Security-Management/ISP-redundancy-VPN-question/m-p/237675#M46151</guid>
      <dc:creator>madu1</dc:creator>
      <dc:date>2025-01-06T13:01:14Z</dc:date>
    </item>
    <item>
      <title>Re: ISP redundancy/VPN question</title>
      <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/ISP-redundancy-VPN-question/m-p/237677#M46152</link>
      <description>&lt;P&gt;You got it, thats exactly it. You need to check that setting " Apply settings to VPN traffic"&lt;/P&gt;
&lt;P&gt;Andy&lt;/P&gt;</description>
      <pubDate>Mon, 06 Jan 2025 13:06:14 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Firewall-and-Security-Management/ISP-redundancy-VPN-question/m-p/237677#M46152</guid>
      <dc:creator>the_rock</dc:creator>
      <dc:date>2025-01-06T13:06:14Z</dc:date>
    </item>
    <item>
      <title>Re: ISP redundancy/VPN question</title>
      <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/ISP-redundancy-VPN-question/m-p/237680#M46154</link>
      <description>&lt;P&gt;Spot on, thanks Andy.&amp;nbsp; I'll give that a try on the next testing window!&lt;/P&gt;</description>
      <pubDate>Mon, 06 Jan 2025 13:10:03 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Firewall-and-Security-Management/ISP-redundancy-VPN-question/m-p/237680#M46154</guid>
      <dc:creator>madu1</dc:creator>
      <dc:date>2025-01-06T13:10:03Z</dc:date>
    </item>
    <item>
      <title>Re: ISP redundancy/VPN question</title>
      <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/ISP-redundancy-VPN-question/m-p/237681#M46155</link>
      <description>&lt;P&gt;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.&lt;/P&gt;
&lt;P&gt;Andy&lt;/P&gt;</description>
      <pubDate>Mon, 06 Jan 2025 13:11:22 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Firewall-and-Security-Management/ISP-redundancy-VPN-question/m-p/237681#M46155</guid>
      <dc:creator>the_rock</dc:creator>
      <dc:date>2025-01-06T13:11:22Z</dc:date>
    </item>
  </channel>
</rss>

