Migrating from pfSense to FortiGate: method and pitfalls

pfSense is an excellent open-source firewall. Many of our clients started with it, often installed by a contractor or an enthusiastic employee. Then the company opened a second site, hired remote workers, took out cyber insurance that demands reports. That is usually when the move to FortiGate gets decided.

Why change

• Application and SSL inspection with signatures updated daily, where pfSense relies on third-party packages.
• Built-in SD-WAN for multi-site companies, with automatic link failover.
• Vendor support and hardware replacement under warranty, which no open-source project provides on its own.
• Reports and compliance expected by insurers and auditors.
• Security Fabric: Fortinet switches and WiFi managed from the firewall.

The method we follow

1. Full export and reading of the pfSense configuration: interfaces, VLANs, rules, NAT, VPN, DHCP, DNS. Nothing is translated automatically; every rule is understood then rewritten.
2. Clean-up: in every migration, a third of the rules are obsolete. That is the moment to delete them, not copy them.
3. Staging: the FortiGate is configured and tested in parallel, on a test VLAN, with VPNs up to a pilot site.
4. Cutover one evening or weekend, with the pfSense kept powered off for two weeks for an immediate rollback.
5. Documentation handed to the client: diagram, flow matrix, emergency procedure.

The pitfalls

• IPsec VPNs to third parties: every partner must validate the new parameters. We warn them early.
• Default rules: pfSense allows outbound LAN traffic by default; FortiGate denies everything except what is explicitly allowed. What “just worked” must be declared.
• Sizing: SSL inspection divides the advertised throughput. We pick the model on inspected throughput, not the marketing sheet.

As a Fortinet partner, we carry out this migration as a project or within a managed services contract. See our cybersecurity service.