How to Migrate VLANs to Virtual Switch on FortiGate Without Losing Configurations?

[hassan1]

I'm working with a FortiGate 100F and attempting to migrate 10 VLANs from port5 to a newly created virtual switch. My goal is to preserve all existing configurations, including policies and routing tied to these VLANs, during the migration. I've tried editing the backup configuration file to replace port5 with the virtual switch's name and re-upload it, but after doing so, all my VLANs vanished from the configuration. I ensured that syntax and references were correctly maintained in the edit.

Has anyone successfully completed a similar migration, or can provide insights on how to retain VLAN configurations when moving to a virtual switch? Are there specific steps or considerations in the FortiGate setup to prevent the loss of VLAN configurations during such a process?

[AEK]

Hi Hassan

In such situation one of the good methods is to use zones. I'd proceed as follows:

1. Make a full backup of your FG config
2. Create a zone for each VLAN
3. Migrate VLANs to Zones (interface migration wizard)
4. Create the new interface VLANs
5. Add each new interface VLAN to the right existing zone (you will have 2 VLAN interfaces by zone, one old and one new)
6. Propagate the VLANs from the switch to FG's new port(s)
7. Migrate the interface IP addresses from the old VLAN interfaces to the new VLAN interfaces
8. Test if everything is ok
9. Once all is fine delete the old VLAN interfaces
10. Rollback from backup config in case of major issue

Do it in maintenance window.

Downtime approximately 10 mn.

Test it first on a test system if possible

[hassan1]

Thank you for the detailed recommendations on migrating VLANs to zones and adjusting network configurations. I understand the proposed approach and its benefits for managing network policies and simplifying configurations. However, I'm facing a significant challenge due to the scale of our network, which includes over 112 switches and more than 1015 firewall policies, alongside numerous policy routes.

Given the complexity and breadth of our network infrastructure, a major concern is the practicality of implementing these changes without causing extensive downtime or operational disruption. The initial estimate of approximately 10 minutes of downtime seems optimistic in our context. Redefining policies and reconfiguring all switches in this timeframe isn't feasible, considering the need for careful planning, phased implementation, and rigorous testing to ensure network integrity and performance.

Implementing changes on such a scale likely requires a more gradual transition plan, potentially leveraging automation tools to manage repetitive tasks and minimize human error. However, even with automation, the scope of changes—especially updating switch configurations and firewall policies—presents a considerable workload.

I'm seeking further guidance on managing this transition more effectively under these constraints. Are there alternative strategies that might accommodate the large scale of our network, while minimizing downtime and disruption? Additionally, would engaging with professional services for planning and execution support be advisable in this scenario?

I appreciate any insights or suggestions you can offer, including experiences from similar large-scale migrations or best practices for managing complex network transitions.

[AEK]

You're welcome Hassan

I'll try to ask with short answers some of your questions but probably not all of them, hoping that it will help.

• For large scale a good solution to speed up the migration and minimize time is to prepare and use CLI scripts for switch & FG
• No need to change any firewall policy. The only thing changed in policies is to change interfaces by zones, and this is done automatically and quickly by wizard (almost no traffic interruption)
• Sometimes when your environment is very critical and you can't handle such migration then yes you should call PS
• Full backup (switch & FG) is your best guarantee. Prepare a plan and rollback plan in a realistic maintenance window. Stop everything and execute rollback if maintenance window reaches its end

[hassan1 · Accepted solution]

Thank you for your prompt reply and valuable insights. I appreciate your suggestions on using CLI scripts and minimizing firewall policy adjustments during the migration process. Your mention of using a wizard for interface-to-zone migration was particularly intriguing.

Regarding the suggestion to call Professional Services (PS), while I understand the importance of expert guidance in critical environments, I'm optimistic about handling the migration internally. As a member of Professional Services myself, I'm confident in our team's abilities to manage the migration effectively. Nevertheless, I'll keep PS support in mind for any unforeseen challenges.

After further exploration, I stumbled upon an article discussing the migration of VLANs to other interfaces using FortiGate devices. It offers detailed steps and insights that align closely with our migration objectives. I found it helpful and thought it might complement our migration strategy. You can find the article here: Technical Tip: Transfer/Migrate VLAN to another interface.
URL: - https://community.fortinet.com/t5/FortiGate/Technical-Tip-Transfer-Migrate-VLAN-to-another-interface...

I'm pleased to share that implementing the solution outlined in the article took no more than 10 minutes, and our network is functioning flawlessly. It's reassuring to see such efficient results, and I'm confident in the decisions we've made for our migration strategy.

Thank you once again for your assistance. Your input has been invaluable in shaping our migration approach.

Best regards