Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Sanjay_S
Advisor
Jump to solution

VSX to Physical Box

Hi All,

We are migrating one of our customer with 4 member cluster from VSX to physical box as we had only one VS. What is the best way to migrate the policy. Anything that should be considered before planning this? Can we use export import policy package(Python) to migrate the VSX policy to normal?

Regards,

Sanjay S

0 Kudos
1 Solution

Accepted Solutions
PhoneBoy
Admin
Admin

local.scv is configured on the management for regular gateways as well and should be pushed as part of the regular policy installation process.
The gateway will need "Policy Server" ticked as a feature, as shown here: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut... 

View solution in original post

0 Kudos
19 Replies
PhoneBoy
Admin
Admin

If it’s the same management domain, then you don’t even need to do that: just replace all instances of the VS with the newly built gateway object and push policy.
If you’re moving the gateway to different management, then yes, you can use the Python export/import script.

Sanjay_S
Advisor

Thank you PhoneBoy.

I have few doubts here. Replacing the VS with the Gateway and pushing is a easy solution is what I feel. But what is the best backout plan in case if we face any issues? Also we are just in the planning phase and need to know more details about the option. Is there any document i can find for it?

Regards,

Sanjay S

0 Kudos
Magnus-Holmberg
Advisor

Install the GW in the same domain as the VS, then prepp everything.
keep in mind that VS only need 1 IP, but if you doing normal GW then you will need 3 for cluster XL.
So check all your vlan/prefix that you have available IPs.

As its to a seperate box you should be able to connect it in paralell.
and when you want to change, just remove the VLAN from switch to VSX cluster and open them on ports to the new boxes.

Doing it that way gives you an easy way back if needed, just revert the change in the switch and you are back to normal.

https://www.youtube.com/c/MagnusHolmberg-NetSec
Sanjay_S
Advisor

Thanks Magnus for the explanation. I will look into it and work. 

0 Kudos
the_rock
Legend
Legend

Magnus is vsx GURU 😉

0 Kudos
Magnus-Holmberg
Advisor

hehe i wish, 10years and still feel like a rookie. there are ppl here that has alot more experience with VSX and that why community's like these are great 🙂

https://www.youtube.com/c/MagnusHolmberg-NetSec
0 Kudos
_Val_
Admin
Admin

Yep, sounds good, this is a solid plan, @Magnus-Holmberg 

0 Kudos
Bob_Zimmerman
Authority
Authority

Strictly, you don't need any additional IPs for a non-VSX firewall. They can do exactly the same off-net VIP thing VSX does. It's a little weird, but it's supported.

The biggest hard limitation I know of moving from VSX to non-VSX is routing. VSX has a separate routing table for VS0, which is used for management traffic. Non-VSX firewalls only have one routing table, so getting to the management server is potentially much more complicated, especially from a standby management server in case of failure of the primary.

0 Kudos
Magnus-Holmberg
Advisor

Sure thats true, but it will look "strange" 🙂

Yes mgmt traffic etc need to be fixed before, but if installing it in paralell it should be fixable.
My point was more that you dont need do a big bang, you can actually prepp and set it up and then do a "big bang" with a very easy way to return to how it was before.

https://www.youtube.com/c/MagnusHolmberg-NetSec
0 Kudos
genisis__
Leader Leader
Leader

Snapshot the manager.

0 Kudos
Sanjay_S
Advisor

Sure Genisis.

I was testing both the options suggested by PhoneBoy, with the help of Magnus's explanation.

When checked the Export Import Script, I see more limitations and more work.

When i go with replacing the VS instances, i followed the below steps in our LAB environment.

> Cloned the Policy Package, Removed the VS instances in the closed policy. Created the new cluster with the physical boxes. Replaced the VS instances with the cluster and pushed the policy to the new cluster. 

> As i cloned the policy and using cloned policy for Physical box and the VS policy to VS. For now i can make changes to both the policies and install it individually to VS as well as Physical box till the migration day is it correct?

> Also we have Desktop Policy, Identity Awareness & Mobile Access blade enabled for VS, while cloning all these will be pushed to physical box is my understanding correct? If i go with this method in production do i need to consider checking anything else or just replace and push should e enough?

Regards,

Sanjay S

0 Kudos
PhoneBoy
Admin
Admin

Desktop Policy and some parts of the Mobile Access configuration do not have API support and are thus not exported by that script--they will have to be migrated manually.
Any Identity Awareness configuration done in the VS itself will have to be manually migrated as well (same with all other settings in the gateway object).

0 Kudos
Sanjay_S
Advisor

Thanks PhoneBoy for your help on this. 

Now i am preferring the method you suggested instead of Python import/export script.

"just replace all instances of the VS with the newly built gateway object and push policy."

So here i followed the below steps to achieve the migration easily as you suggested.

> Cloned the Policy Package, Removed the VS instances in the closed policy. Created the new cluster with the physical boxes. Replaced the VS instances with the cluster and pushed the policy to the new cluster. 

> As i cloned the policy and using cloned policy for Physical box and the VS policy to VS. For now i can make changes to both the policies and install it individually to VS as well as Physical box till the migration day is it correct?

> Also we have Desktop Policy, Identity Awareness & Mobile Access blade enabled for VS, while cloning all these will be pushed to physical box is my understanding correct? If i go with this method in production do i need to consider checking anything else or just replace and push policy should be enough?

0 Kudos
PhoneBoy
Admin
Admin

Correct, make changes to both policies and the configuration for Desktop Policy, Identity Awareness, and Mobile Access.
Replacing and pushing policy should be enough, but it will be disruptive.
You can minimize this by temporarily disabling "Drop Out of State" for TCP/UDP in Global Properties, which will minimize the number of dropped connections. 
(Note do not leave this enabled long term as it is a security risk).

0 Kudos
Sanjay_S
Advisor

Hi PhoneBoy,

So Desktop Policy, Identity Awareness, and Mobile Access i need to re-configure on newly configured Cluster object is that right?

0 Kudos
PhoneBoy
Admin
Admin

And possibly other things as well, but those for sure.

0 Kudos
Sanjay_S
Advisor

Hi PhoneBoy,

One more additional request on this. We have changes made on the Management server for the virtual system on the local.scv file.

When it comes to physical box it would be on firewalls is it? Do we need to make the same changes on the firewalls local.scv file and push the policy?

Regards,

Sanjay S

0 Kudos
PhoneBoy
Admin
Admin

local.scv is configured on the management for regular gateways as well and should be pushed as part of the regular policy installation process.
The gateway will need "Policy Server" ticked as a feature, as shown here: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut... 

0 Kudos
Sanjay_S
Advisor

Thanks all for your support we successfully migrated VSX to Physical box without any issues. Special mention PhoneBoy 🙂

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events