<?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: VSX bootp relay originating from wrong IP in Firewall and Security Management</title>
    <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/VSX-bootp-relay-originating-from-wrong-IP/m-p/225209#M43327</link>
    <description>&lt;P&gt;Yeah, we ended up doing that to change the private tunnel IP into something that the 3rd party could route.&lt;/P&gt;</description>
    <pubDate>Fri, 30 Aug 2024 20:15:00 GMT</pubDate>
    <dc:creator>stallwoodj</dc:creator>
    <dc:date>2024-08-30T20:15:00Z</dc:date>
    <item>
      <title>VSX bootp relay originating from wrong IP</title>
      <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/VSX-bootp-relay-originating-from-wrong-IP/m-p/224605#M43170</link>
      <description>&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;We have VSX running on R81.20 JHF76, with one virtual system (id 5) running just FW1+VPN blades. It has one LAN interface, an external and a numbered VTI with universal tunnel. The default route is up the tunnel.&lt;/P&gt;&lt;P&gt;The client LAN is set to do DHCP relay to a remote server:&lt;/P&gt;&lt;P&gt;set bootp interface bond101.XXX1 on&lt;BR /&gt;set bootp interface bond101.XXX1 relay-to XXX.XXX.XXX.231 on&lt;BR /&gt;set bootp interface bond101.XXX1 primary 192.168.50.254&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;However, the DHCP relay is originating from the wrong IP - it's from the vsx private subnet, and it's then automatically NATted it behind the outgoing interface (VTI).&lt;/P&gt;&lt;P&gt;Has anyone else had this problem?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Thanks&lt;/P&gt;&lt;P&gt;Jamie&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Tue, 27 Aug 2024 08:19:31 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Firewall-and-Security-Management/VSX-bootp-relay-originating-from-wrong-IP/m-p/224605#M43170</guid>
      <dc:creator>stallwoodj</dc:creator>
      <dc:date>2024-08-27T08:19:31Z</dc:date>
    </item>
    <item>
      <title>Re: VSX bootp relay originating from wrong IP</title>
      <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/VSX-bootp-relay-originating-from-wrong-IP/m-p/224606#M43171</link>
      <description>&lt;P&gt;If you do a 'show route destination [ip of your relay-to server]' from clish or 'ip route get&amp;nbsp;[ip of your relay-to server]' from expert in the VS5 context, does it have a route out of the correct interface?&lt;/P&gt;</description>
      <pubDate>Tue, 27 Aug 2024 08:23:13 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Firewall-and-Security-Management/VSX-bootp-relay-originating-from-wrong-IP/m-p/224606#M43171</guid>
      <dc:creator>emmap</dc:creator>
      <dc:date>2024-08-27T08:23:13Z</dc:date>
    </item>
    <item>
      <title>Re: VSX bootp relay originating from wrong IP</title>
      <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/VSX-bootp-relay-originating-from-wrong-IP/m-p/224608#M43172</link>
      <description>&lt;P&gt;Hi Emma,&lt;/P&gt;&lt;P&gt;Yes, it's following the default route up the tunnel&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;PRE&gt;[Expert@FW-VSX-PRI:5]# ip route get XXX.XXX.XXX.231&lt;BR /&gt;XXX.XXX.XXX.231 via 192.0.2.81 dev vpnt509 src 172.31.248.33&lt;BR /&gt;cache&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;[Expert@FW-VSX-PRI:5]# ip route&lt;BR /&gt;default via 192.0.2.81 dev vpnt509 proto 7&lt;BR /&gt;172.31.248.0/28 dev wrp320 proto kernel scope link src 172.31.248.1&lt;BR /&gt;172.31.248.16/28 dev bond101.3xx1 proto kernel scope link src 172.31.248.17&lt;BR /&gt;PUBLICIP.0/27 dev wrp320 proto 7 scope link&lt;BR /&gt;192.0.2.81 dev vpnt509 proto 7 scope link&lt;BR /&gt;192.168.50.0/24 dev bond101.3xx1 proto 7 scope link&lt;BR /&gt;VPNPEER via PUBLICIP.30 dev wrp320 proto 7&lt;/PRE&gt;</description>
      <pubDate>Tue, 27 Aug 2024 08:34:39 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Firewall-and-Security-Management/VSX-bootp-relay-originating-from-wrong-IP/m-p/224608#M43172</guid>
      <dc:creator>stallwoodj</dc:creator>
      <dc:date>2024-08-27T08:34:39Z</dc:date>
    </item>
    <item>
      <title>Re: VSX bootp relay originating from wrong IP</title>
      <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/VSX-bootp-relay-originating-from-wrong-IP/m-p/224617#M43175</link>
      <description>&lt;P&gt;It looks like it's going to route the DHCP requests up the VPN tunnel to the relay, is that intended? If not you might should add a static route to the correct next hop for it.&lt;/P&gt;
&lt;P&gt;The Primary IP in the bootp config isn't there to set the source IP on the packets. From the admin guide: it's the IPv4 address to use as the BOOTP/DHCP router address. If you enter an IPv4 address, all BOOTP/DHCP requests received on the interface are stamped with this IPv4 address. &lt;SPAN&gt;This can be useful on interfaces with multiple IPv4 addresses (aliases).&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;Hence the outgoing packets are still going to use the source IP on the interface they are routed out of.&lt;/P&gt;</description>
      <pubDate>Tue, 27 Aug 2024 08:59:31 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Firewall-and-Security-Management/VSX-bootp-relay-originating-from-wrong-IP/m-p/224617#M43175</guid>
      <dc:creator>emmap</dc:creator>
      <dc:date>2024-08-27T08:59:31Z</dc:date>
    </item>
    <item>
      <title>Re: VSX bootp relay originating from wrong IP</title>
      <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/VSX-bootp-relay-originating-from-wrong-IP/m-p/224628#M43178</link>
      <description>&lt;P&gt;Thanks, is there a way we can "persuade" the NAT to use the LAN-side vip 192.168.50.254 as its hide NAT, not the outgoing tunnel interface? We only have a number on the VTI because it's VSX, and the other end doesn't by default know how to route back to the tunnel local interface.&lt;/P&gt;</description>
      <pubDate>Tue, 27 Aug 2024 11:58:59 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Firewall-and-Security-Management/VSX-bootp-relay-originating-from-wrong-IP/m-p/224628#M43178</guid>
      <dc:creator>stallwoodj</dc:creator>
      <dc:date>2024-08-27T11:58:59Z</dc:date>
    </item>
    <item>
      <title>Re: VSX bootp relay originating from wrong IP</title>
      <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/VSX-bootp-relay-originating-from-wrong-IP/m-p/224700#M43190</link>
      <description>&lt;P&gt;The cluster hide NAT isn't something that can be directly affected in that way. You can try adding a hideNAT rule in the policy but outbound hide NAT for packets originating from the gateway doesn't generally work. Would it be possible to NAT it at the other end of the VPN tunnel?&lt;/P&gt;</description>
      <pubDate>Wed, 28 Aug 2024 01:51:40 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Firewall-and-Security-Management/VSX-bootp-relay-originating-from-wrong-IP/m-p/224700#M43190</guid>
      <dc:creator>emmap</dc:creator>
      <dc:date>2024-08-28T01:51:40Z</dc:date>
    </item>
    <item>
      <title>Re: VSX bootp relay originating from wrong IP</title>
      <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/VSX-bootp-relay-originating-from-wrong-IP/m-p/225209#M43327</link>
      <description>&lt;P&gt;Yeah, we ended up doing that to change the private tunnel IP into something that the 3rd party could route.&lt;/P&gt;</description>
      <pubDate>Fri, 30 Aug 2024 20:15:00 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Firewall-and-Security-Management/VSX-bootp-relay-originating-from-wrong-IP/m-p/225209#M43327</guid>
      <dc:creator>stallwoodj</dc:creator>
      <dc:date>2024-08-30T20:15:00Z</dc:date>
    </item>
  </channel>
</rss>

