<?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: IPSec S2S: NON-RFC1918 network behind tunnel endpoint in Spark Firewall (SMB)</title>
    <link>https://community.checkpoint.com/t5/Spark-Firewall-SMB/IPSec-S2S-NON-RFC1918-network-behind-tunnel-endpoint/m-p/7866#M139</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;VPN routing happens in the kernel, and it's not going to show up in the routing table unless you're using route-based VPNs.&lt;/P&gt;&lt;P&gt;You can use the CLI command vpn tu to see what tunnels are actually up and active.&lt;/P&gt;&lt;P&gt;The fact you're able to receive VPN traffic suggests at least part of the configuration is right.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;My guess is that the traffic being NATted is also being subject to address translation out the external interface.&lt;/P&gt;&lt;P&gt;Since that IP is not likely in the encryption domain configuration on the remote end, the traffic is being dropped.&lt;/P&gt;&lt;P&gt;In which case, you'll want to put in a manual NAT rule to disable NAT when connecting to that remote subnet.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Wed, 25 Oct 2017 12:51:02 GMT</pubDate>
    <dc:creator>PhoneBoy</dc:creator>
    <dc:date>2017-10-25T12:51:02Z</dc:date>
    <item>
      <title>IPSec S2S: NON-RFC1918 network behind tunnel endpoint</title>
      <link>https://community.checkpoint.com/t5/Spark-Firewall-SMB/IPSec-S2S-NON-RFC1918-network-behind-tunnel-endpoint/m-p/7865#M138</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hello Folks,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;the following questions may be pretty simple, but I'm kind of struggling&amp;nbsp;to figure out a&amp;nbsp;"lowest common denominator" for googling this subject.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;My setup:&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;I have an IPSEC tunnel between a Check Point 1430 (see below) and an interop device. The remote site is not under my control and uses a non-RFC1918 network behind the remote tunnel endpoint:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;(172.16.10.0/24) [my CP] ---WAN-IP---===== ipsec ====---WAN-IP---[rem. INTEROP] (NON-RFC1918 as private network)&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I just configured this non-RFC network (a public /24 ip subnet) as (only) part of the encryption domain.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;The tunnel is active.&lt;/LI&gt;&lt;LI&gt;Traffic (e.g. icmp) can be sent from remote site to my site and echo-reply reaches the remote site.&lt;/LI&gt;&lt;LI&gt;No traffic can be initiated from my site to the remote site (no-reply) - tunnel still active.&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;My assumption:&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;My assumption is that Check Point just sees traffic for a public network and routes it to an interface with a public ip address or via default route, but not into the tunnel.&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;My questions:&lt;/STRONG&gt;&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;Is&amp;nbsp;this assumption somehow correct? If not - how is it done?&lt;/LI&gt;&lt;LI&gt;&lt;SPAN style="font-family: 'courier new', courier, monospace;"&gt;show route all &lt;SPAN style="font-family: arial, helvetica, sans-serif;"&gt;does not show any routes for VPNs (networks behind tunnels). This seems to be normal for CP.&amp;nbsp;Is there another command for viewing routes in conjunction with VPN sites or how is this thought/ done?&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="color: #333333; background-color: #ffffff;"&gt;Thanks in advance.&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;DIV style="color: #2a3a55; background-color: #f7f9ff;"&gt;&lt;SPAN class=""&gt;Appliance:&lt;/SPAN&gt;Check Point 1430 Appliance&lt;/DIV&gt;&lt;DIV style="color: #2a3a55; background-color: #f7f9ff;"&gt;&lt;SPAN class=""&gt;Security Management:&lt;/SPAN&gt;Locally managed&lt;/DIV&gt;&lt;DIV style="color: #2a3a55; background-color: #f7f9ff;"&gt;&lt;SPAN class=""&gt;Version (Firmware):&lt;/SPAN&gt;R77.20.40 (990171107)&lt;/DIV&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 25 Oct 2017 10:21:41 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Spark-Firewall-SMB/IPSec-S2S-NON-RFC1918-network-behind-tunnel-endpoint/m-p/7865#M138</guid>
      <dc:creator>Julius_Kaiser</dc:creator>
      <dc:date>2017-10-25T10:21:41Z</dc:date>
    </item>
    <item>
      <title>Re: IPSec S2S: NON-RFC1918 network behind tunnel endpoint</title>
      <link>https://community.checkpoint.com/t5/Spark-Firewall-SMB/IPSec-S2S-NON-RFC1918-network-behind-tunnel-endpoint/m-p/7866#M139</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;VPN routing happens in the kernel, and it's not going to show up in the routing table unless you're using route-based VPNs.&lt;/P&gt;&lt;P&gt;You can use the CLI command vpn tu to see what tunnels are actually up and active.&lt;/P&gt;&lt;P&gt;The fact you're able to receive VPN traffic suggests at least part of the configuration is right.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;My guess is that the traffic being NATted is also being subject to address translation out the external interface.&lt;/P&gt;&lt;P&gt;Since that IP is not likely in the encryption domain configuration on the remote end, the traffic is being dropped.&lt;/P&gt;&lt;P&gt;In which case, you'll want to put in a manual NAT rule to disable NAT when connecting to that remote subnet.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 25 Oct 2017 12:51:02 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Spark-Firewall-SMB/IPSec-S2S-NON-RFC1918-network-behind-tunnel-endpoint/m-p/7866#M139</guid>
      <dc:creator>PhoneBoy</dc:creator>
      <dc:date>2017-10-25T12:51:02Z</dc:date>
    </item>
    <item>
      <title>Re: IPSec S2S: NON-RFC1918 network behind tunnel endpoint</title>
      <link>https://community.checkpoint.com/t5/Spark-Firewall-SMB/IPSec-S2S-NON-RFC1918-network-behind-tunnel-endpoint/m-p/7867#M140</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I'm not sure if I got you right, but I created a manual SNAT rule that hides traffic&amp;nbsp;to the non-RFC1918 network behind the tunnel with an arbitrary address from the local network on my site. Things are flying.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks for your input Dameon!&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 01 Nov 2017 15:15:27 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Spark-Firewall-SMB/IPSec-S2S-NON-RFC1918-network-behind-tunnel-endpoint/m-p/7867#M140</guid>
      <dc:creator>Julius_Kaiser</dc:creator>
      <dc:date>2017-11-01T15:15:27Z</dc:date>
    </item>
  </channel>
</rss>

