VSX to Physical Box

[Sanjay_S]

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

[PhoneBoy]

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]

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

[Magnus-Holmberg]

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.

[Sanjay_S]

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

[the_rock]

Magnus is vsx GURU 😉

[Magnus-Holmberg]

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 🙂

[_Val_]

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

[Bob_Zimmerman]

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.

[Magnus-Holmberg]

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.

[genisis__]

Snapshot the manager.

[Sanjay_S]

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

[PhoneBoy]

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).

[Sanjay_S]

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?

[PhoneBoy]

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).

[Sanjay_S]

Hi PhoneBoy,

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

[PhoneBoy]

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

[Sanjay_S]

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

[PhoneBoy · Accepted solution]

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... 

[Sanjay_S]

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