<?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: Calling VSX experts in Firewall and Security Management</title>
    <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Calling-VSX-experts/m-p/104657#M8602</link>
    <description>&lt;P&gt;Migrating MGMT server to a new IP address is usually trivial with migtrate_server tool, and it does not require much to do on GW side, VSX or otherwise (other than ensuring implied rules cover the new MGMT object as well).&lt;/P&gt;
&lt;P&gt;Could you please elaborate on why you are doing migration in several stages?&lt;/P&gt;</description>
    <pubDate>Tue, 08 Dec 2020 13:27:33 GMT</pubDate>
    <dc:creator>_Val_</dc:creator>
    <dc:date>2020-12-08T13:27:33Z</dc:date>
    <item>
      <title>Calling VSX experts</title>
      <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Calling-VSX-experts/m-p/104445#M8600</link>
      <description>&lt;P&gt;I have migrated our security manager over to a new server (different IP address) as it is a different location and now in the process of migrating our gateways over to this new server. &amp;nbsp; We have some physical firewalls and some VSX firewalls. &amp;nbsp;All the physical firewalls have now been migrated over which was quite simple by reconfiguring sic on both the firewall and new manger. &amp;nbsp;However VSX ones seem to be a challenge. &amp;nbsp;There doesn’t seem a great deal of documents on how to do this for VSX and what I have read you shouldn’t do the same ie cpconfig etc. &amp;nbsp; Any advice on best way to do this for migration for VSX?&amp;nbsp;&lt;BR /&gt;&lt;BR /&gt;&lt;/P&gt;&lt;P&gt;thanks&lt;/P&gt;</description>
      <pubDate>Mon, 07 Dec 2020 03:13:15 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Calling-VSX-experts/m-p/104445#M8600</guid>
      <dc:creator>peter2020</dc:creator>
      <dc:date>2020-12-07T03:13:15Z</dc:date>
    </item>
    <item>
      <title>Re: Calling VSX experts</title>
      <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Calling-VSX-experts/m-p/104642#M8601</link>
      <description>&lt;P&gt;It's not a straight forward process and I would suggest to get professional services help if you have never done it before. There are multiple ways to migrate VSX, all depends on your actual environment. If you do want to try, check VSX provisioning tool in VSX admin guide.&lt;/P&gt;
&lt;UL&gt;
&lt;LI&gt;first build the "non-VSX" part of the gateway, configure physical interfaces, DNS, NTP, mgmt routing, backups, users etc. Just as you did with the regular gateway&lt;/LI&gt;
&lt;LI&gt;Create VSX cluster / VS-0 manually in the new mgmt (instead of regular cluster)&lt;/LI&gt;
&lt;LI&gt;then you can use VSX provisioning tool to dump VSX config from old mgmt and then re-create them in the new using the same tool.&lt;/LI&gt;
&lt;/UL&gt;
&lt;P&gt;You will need to take care of any physical interface name changes in the scripts btw&lt;/P&gt;
&lt;P&gt;That's in nutshell.&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Tue, 08 Dec 2020 10:43:24 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Calling-VSX-experts/m-p/104642#M8601</guid>
      <dc:creator>Kaspars_Zibarts</dc:creator>
      <dc:date>2020-12-08T10:43:24Z</dc:date>
    </item>
    <item>
      <title>Re: Calling VSX experts</title>
      <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Calling-VSX-experts/m-p/104657#M8602</link>
      <description>&lt;P&gt;Migrating MGMT server to a new IP address is usually trivial with migtrate_server tool, and it does not require much to do on GW side, VSX or otherwise (other than ensuring implied rules cover the new MGMT object as well).&lt;/P&gt;
&lt;P&gt;Could you please elaborate on why you are doing migration in several stages?&lt;/P&gt;</description>
      <pubDate>Tue, 08 Dec 2020 13:27:33 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Calling-VSX-experts/m-p/104657#M8602</guid>
      <dc:creator>_Val_</dc:creator>
      <dc:date>2020-12-08T13:27:33Z</dc:date>
    </item>
    <item>
      <title>Re: Calling VSX experts</title>
      <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Calling-VSX-experts/m-p/104696#M8603</link>
      <description>&lt;P&gt;Hi Val&amp;nbsp; - I have migrated the whole database to the new server ok using the migrate_server tool and that is fine.&amp;nbsp; &amp;nbsp;I have also established the gateways&amp;nbsp; to connect to the new management server IP address by re-establishing sic on both the firewall and then the manager .&amp;nbsp; &amp;nbsp;All I have to do is get the VSX gateways to establish sic from the old manager to the new manager and what is the correct way/steps&amp;nbsp; of doing this without breaking anything.&amp;nbsp; &amp;nbsp; There doesn't seem to be any documentation out there to do this and people don't seem to know how to do it correctly.&amp;nbsp; &amp;nbsp; Any knowledge you have on this would be very grateful?&amp;nbsp; &amp;nbsp;Many Thanks&lt;/P&gt;</description>
      <pubDate>Tue, 08 Dec 2020 18:51:28 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Calling-VSX-experts/m-p/104696#M8603</guid>
      <dc:creator>peter2020</dc:creator>
      <dc:date>2020-12-08T18:51:28Z</dc:date>
    </item>
    <item>
      <title>Re: Calling VSX experts</title>
      <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Calling-VSX-experts/m-p/104697#M8604</link>
      <description>&lt;P&gt;Thanks for you message.&amp;nbsp; &amp;nbsp;The new manager has all the DB migrated from the old manager so has the firewalls and the contexts etc.&amp;nbsp; &amp;nbsp;The only issue I have is disconnecting the VSX gateways from the old management server to the new management server.&amp;nbsp; &amp;nbsp;VSX seems to be very temperamental and seems you cannot use cpconfig with the sic on gateways like a non vsx gateway.&amp;nbsp; &amp;nbsp;Doesn't seem to be any documents regarding VSX on how to this and the people I have spoken to so far don't seem to know the proper way of doing this&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Tue, 08 Dec 2020 18:56:08 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Calling-VSX-experts/m-p/104697#M8604</guid>
      <dc:creator>peter2020</dc:creator>
      <dc:date>2020-12-08T18:56:08Z</dc:date>
    </item>
    <item>
      <title>Re: Calling VSX experts</title>
      <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Calling-VSX-experts/m-p/104714#M8605</link>
      <description>&lt;P&gt;Then I have a couple of questions for you:&lt;/P&gt;
&lt;UL&gt;
&lt;LI&gt;Did you add a rule in the old situation to allow full access from the new IP to the gateways?
&lt;UL&gt;
&lt;LI&gt;if the answer is yes:&lt;/LI&gt;
&lt;/UL&gt;
&lt;/LI&gt;
&lt;LI&gt;Did&amp;nbsp; you try to push policy from the new server without resetting SIC to any of the normal gateways?&lt;/LI&gt;
&lt;LI&gt;Did you try to push policy to the VSX gateways?&amp;nbsp;&lt;/LI&gt;
&lt;/UL&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;If the answer to the first question was No, please add that to the rules for the VSX Gateways and push policy from the old management to the VSX gateways and then try to push policy from the new management to the VSX gateways. Once this has succeeded, push the policy to the VSs.&lt;/P&gt;</description>
      <pubDate>Tue, 08 Dec 2020 23:54:48 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Calling-VSX-experts/m-p/104714#M8605</guid>
      <dc:creator>Maarten_Sjouw</dc:creator>
      <dc:date>2020-12-08T23:54:48Z</dc:date>
    </item>
    <item>
      <title>Re: Calling VSX experts</title>
      <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Calling-VSX-experts/m-p/104730#M8606</link>
      <description>&lt;P&gt;That is exactly my point. SIC should work out of the box, no additional hustle, if everything is done correctly.&lt;/P&gt;
&lt;P&gt;&lt;U&gt;You do not need to re-establish SIC&lt;/U&gt;.&lt;/P&gt;
&lt;P&gt;On old management you should add a dummy object as a secondary MGMT server, with IP address of the new MGMT server. After pushing policies on all FWs, shut down the old MGMT server and check SIC from the new one. It should work. If it does not, something in the middle is interfering.&lt;BR /&gt;&lt;BR /&gt;All that under assumption you did not disable control connections in implied rules. If you did, on old MGMT you should also add an early explicit rule allowing control connections to/from FW &amp;amp; new MGMT IP.&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Wed, 09 Dec 2020 08:17:55 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Calling-VSX-experts/m-p/104730#M8606</guid>
      <dc:creator>_Val_</dc:creator>
      <dc:date>2020-12-09T08:17:55Z</dc:date>
    </item>
    <item>
      <title>Re: Calling VSX experts</title>
      <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Calling-VSX-experts/m-p/104750#M8607</link>
      <description>&lt;P&gt;I this scenario I would run vsx_util_reconfigure from new mgmt and re-build VSX to avoid any issues with certs and SIC. You would need to do reset_gw first.&lt;/P&gt;
&lt;P&gt;Depends how much downtime can you have. But start with standby and once done fail over and re-build other one&lt;/P&gt;</description>
      <pubDate>Wed, 09 Dec 2020 10:29:10 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Calling-VSX-experts/m-p/104750#M8607</guid>
      <dc:creator>Kaspars_Zibarts</dc:creator>
      <dc:date>2020-12-09T10:29:10Z</dc:date>
    </item>
  </channel>
</rss>

