<?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 Two interoperable devices with same encryption domain for VPN failover? in Firewall and Security Management</title>
    <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Two-interoperable-devices-with-same-encryption-domain-for-VPN/m-p/277096#M105457</link>
    <description>&lt;P&gt;Hi all,&lt;/P&gt;&lt;P&gt;I need to build a redundant Site-to-Site VPN between a Check Point ClusterXL running R81.10 and a Huawei Gateway with two WAN interfaces. The Huawei device has two public WAN IPs, but both links use the same encryption domain. WAN2 should only be used as a backup/failover link, no load balancing is required.&lt;/P&gt;&lt;P&gt;Currently a domain-based VPN with a single WAN link is already working without issues.&lt;/P&gt;&lt;P&gt;I would like to know what is considered best practice on the Check Point side for implementing WAN redundancy in this kind of setup. Is it supported to create two interoperable devices (one per Huawei WAN IP), use the same encryption domain on both objects, and add both as satellite gateways into the same VPN community?&amp;nbsp;&lt;BR /&gt;&lt;BR /&gt;Or is it strictly recommended to use Route-Based VPN in this setup?&lt;BR /&gt;&lt;BR /&gt;Thanks in advance!&lt;/P&gt;</description>
    <pubDate>Tue, 19 May 2026 12:23:35 GMT</pubDate>
    <dc:creator>jure</dc:creator>
    <dc:date>2026-05-19T12:23:35Z</dc:date>
    <item>
      <title>Two interoperable devices with same encryption domain for VPN failover?</title>
      <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Two-interoperable-devices-with-same-encryption-domain-for-VPN/m-p/277096#M105457</link>
      <description>&lt;P&gt;Hi all,&lt;/P&gt;&lt;P&gt;I need to build a redundant Site-to-Site VPN between a Check Point ClusterXL running R81.10 and a Huawei Gateway with two WAN interfaces. The Huawei device has two public WAN IPs, but both links use the same encryption domain. WAN2 should only be used as a backup/failover link, no load balancing is required.&lt;/P&gt;&lt;P&gt;Currently a domain-based VPN with a single WAN link is already working without issues.&lt;/P&gt;&lt;P&gt;I would like to know what is considered best practice on the Check Point side for implementing WAN redundancy in this kind of setup. Is it supported to create two interoperable devices (one per Huawei WAN IP), use the same encryption domain on both objects, and add both as satellite gateways into the same VPN community?&amp;nbsp;&lt;BR /&gt;&lt;BR /&gt;Or is it strictly recommended to use Route-Based VPN in this setup?&lt;BR /&gt;&lt;BR /&gt;Thanks in advance!&lt;/P&gt;</description>
      <pubDate>Tue, 19 May 2026 12:23:35 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Two-interoperable-devices-with-same-encryption-domain-for-VPN/m-p/277096#M105457</guid>
      <dc:creator>jure</dc:creator>
      <dc:date>2026-05-19T12:23:35Z</dc:date>
    </item>
    <item>
      <title>Re: Two interoperable devices with same encryption domain for VPN failover?</title>
      <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Two-interoperable-devices-with-same-encryption-domain-for-VPN/m-p/277148#M105486</link>
      <description>&lt;P&gt;This SK suggests you can do it without resorting to Route-Based VPN:&amp;nbsp;&lt;A href="https://support.checkpoint.com/results/sk/sk164355" target="_blank"&gt;https://support.checkpoint.com/results/sk/sk164355&lt;/A&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Tue, 19 May 2026 17:35:36 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Two-interoperable-devices-with-same-encryption-domain-for-VPN/m-p/277148#M105486</guid>
      <dc:creator>PhoneBoy</dc:creator>
      <dc:date>2026-05-19T17:35:36Z</dc:date>
    </item>
    <item>
      <title>Re: Two interoperable devices with same encryption domain for VPN failover?</title>
      <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Two-interoperable-devices-with-same-encryption-domain-for-VPN/m-p/277190#M105502</link>
      <description>&lt;P&gt;thanks for sharing this SK. I looked into Check Points documentation on MEP (&lt;A href="https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_SitetoSiteVPN_AdminGuide/Topics-VPNSG/MEP.htm#Overview_of_MEP" target="_blank"&gt;Multiple Entry Point (MEP) VPNs&lt;/A&gt;). According to the documentation, implicit MEP is supported in scenarios where fully or partially overlapping encryption domains exist, or where Primary/Backup Security Gateways are configured.&lt;SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;Do you recommend using explicit MEP in this scenario, or would implicit MEP do the job as well?&lt;BR /&gt;&lt;/SPAN&gt;&lt;/P&gt;</description>
      <pubDate>Wed, 20 May 2026 11:04:12 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Two-interoperable-devices-with-same-encryption-domain-for-VPN/m-p/277190#M105502</guid>
      <dc:creator>jure</dc:creator>
      <dc:date>2026-05-20T11:04:12Z</dc:date>
    </item>
    <item>
      <title>Re: Two interoperable devices with same encryption domain for VPN failover?</title>
      <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Two-interoperable-devices-with-same-encryption-domain-for-VPN/m-p/277210#M105508</link>
      <description>&lt;P&gt;Assuming you meet the criteria for Explicit MEP, I see no reason not to use it.&lt;/P&gt;</description>
      <pubDate>Wed, 20 May 2026 13:56:00 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Two-interoperable-devices-with-same-encryption-domain-for-VPN/m-p/277210#M105508</guid>
      <dc:creator>PhoneBoy</dc:creator>
      <dc:date>2026-05-20T13:56:00Z</dc:date>
    </item>
  </channel>
</rss>

