Migrating from pfSense to FortiGate: method and pitfalls

pfSense is an excellent open-source firewall. Many companies started with it, often installed by a contractor or an enthusiastic employee on a small appliance or an old server. It served well for years. Then the company opened a second site, hired remote workers, took out cyber insurance that asks pointed questions, and the person who knew the configuration left. That is usually when the move to FortiGate gets decided. Here is the method we follow as a Fortinet partner so that it happens without downtime or nasty surprises.

Why change

pfSense is not a bad choice: it is a choice that needs someone to look after it. When that is no longer the case, or when needs outgrow the original configuration, a FortiGate brings:

• Application and SSL inspection with signatures updated continuously by the vendor, where pfSense relies on third-party packages such as Suricata or pfBlockerNG that you install, tune and monitor yourself.
• Built-in SD-WAN for multi-site companies, with automatic link failover and voice prioritisation.
• Vendor support and hardware replacement under contract, which no open-source project provides on its own.
• Usable reports and logs, expected by insurers and auditors.
• Security Fabric: FortiSwitch switches and FortiAP access points managed from the firewall.

When to stay on pfSense

To be honest: if you have a single site, a competent person keeping pfSense up to date, and no insurance or compliance requirements, there is no rush. Migration makes sense when upkeep depends on one person, when the network spreads over several sites, or when you have to prove your level of protection. If you are also unsure about the brand, our FortiGate or WatchGuard comparison helps you decide.

What translates, and how

The two systems do not speak the same language. These are the equivalences we work through one by one.

pfSense element	FortiGate equivalent	Watch out for
Aliases	Address objects and groups	Name them clearly, drop unused aliases
Per-interface rules	Policies between interfaces or zones	FortiGate denies by default: every flow must be declared
Port forwards (inbound NAT)	Virtual IPs (VIPs) and a matching policy	Restrict the source where possible, enable inspection
Automatic outbound NAT	NAT enabled on the policy, or an IP pool	Check multiple public addresses
VLANs	VLAN interfaces, grouped into zones if needed	Keep the same numbering for the switches
DHCP and reservations	DHCP server per interface, reservations	Carry over fixed leases for printers and cameras
DNS resolver	FortiGate DNS or internal server	Recreate local records
Site-to-site IPsec VPN	IPsec tunnels	Parameters to revalidate with each third party
OpenVPN or WireGuard for remote work	IPsec VPN with FortiClient	New client to install on every laptop
Packages (HAProxy, Squid, pfBlockerNG)	Security profiles, web and DNS filtering	Not always a direct equivalent: assess case by case

This table shows why we do not convert automatically: every line calls for a decision, not a copy.

The method we follow

1. Full export and reading of the pfSense configuration: interfaces, VLANs, aliases, rules, NAT, VPN, DHCP, DNS, installed packages. Nothing is translated automatically; every rule is understood then rewritten.
2. Flow matrix: for each rule, who talks to whom, on which port, and why. Rules nobody can justify are flagged.
3. Clean-up: a configuration that has lived for several years accumulates obsolete rules, temporary exceptions never removed and forwards to servers that no longer exist. That is the moment to delete them, not copy them.
4. Sizing the FortiGate on inspected throughput, as explained in FortiGate for SMBs: which model to choose.
5. Staging: the FortiGate is configured and tested in parallel, on a test VLAN, with VPNs up to a pilot site and a few remote workers.
6. Warning third parties: partners connected over IPsec, carriers, software vendors whose access is filtered by IP address.
7. Cutover one evening or weekend, outside business hours, with a test list written in advance: internet, email, business applications, telephony, printing, VPN.
8. Rollback ready: the pfSense is kept powered off for two weeks, cabling documented, for an immediate return if needed.
9. Documentation handed to the client: diagram, flow matrix, emergency procedure, admin access.

Cutover day, in practice

The cutover itself is the shortest step, because everything has been prepared. The FortiGate, already configured and tested, takes the physical place of the pfSense: same cables, same VLANs, same public address where possible. One person runs through the test list while another watches the FortiGate logs to spot denied flows straight away. Every unexpected denial is analysed: either it reveals a forgotten legitimate flow, which is added with a precise rule, or it confirms an obsolete rule we were right to remove. The next morning, a technician stays available for the first users, and the logs are reviewed over the following days to fine-tune what needs it, without ever falling back on an “allow all” rule.

The pitfalls

• IPsec VPNs to third parties: every partner must validate the new parameters, and their timing is not in your hands. 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, or a business application stops on Monday morning.
• Sizing: SSL inspection sharply reduces the advertised throughput. We pick the model on inspected throughput, not the marketing sheet.
• Remote work: OpenVPN or WireGuard users move to FortiClient. The client must be installed, access distributed and some support time planned.
• Public IP addresses: if external services filter on your public address, it must not change, or they must be told.
• SSL inspection: it requires deploying the FortiGate certificate to endpoints, otherwise browsers show warnings.

The mistakes we fix after others

1. An “allow all” policy created on cutover night to get everything working, never removed.
2. SSL inspection left in certificate-only mode, which does not read the content exchanged.
3. The FortiGate admin interface reachable from the internet, without MFA.
4. Firmware never updated since installation.
5. No documentation: the dependence on one person, which triggered the migration, starts all over again.

We cover the right settings in 10 security settings after installing a FortiGate.

Migration checklist

• pfSense configuration export saved off the box.
• Flow matrix approved by the IT manager.
• Obsolete rules identified and deleted.
• FortiGate model and licence chosen on inspected throughput.
• VPN third parties and carriers warned, with their parameters.
• FortiClient ready for remote workers.
• SSL inspection certificate deployed to endpoints.
• Cutover test list written, with an owner for each test.
• pfSense kept powered off for two weeks, rollback procedure written.
• Final documentation handed over.

How we work

Everything starts with a free initial audit of your pfSense and your network: we read the configuration, identify the real flows and give you a proposal for model, licence and schedule. The migration is run as a project or within a managed services contract; in the latter case, the FortiGate joins our 24/7 monitoring, and a critical incident is picked up in under 15 minutes. If you have several sites, we use the opportunity to set up multi-site FortiGate SD-WAN.

Discover our cybersecurity service and our anonymised case studies. To prepare your migration, contact us: we reply within 24 business hours.