Fortinet FortiGate to Palo Alto Migration
Moving from FortiOS to PAN-OS? NetConverter's comprehensive multi-step pipeline automates the conversion of firewall policies, VIPs, address objects, and service definitions with checkpoint-validated translation and confidence scoring.
Why FortiGate → Palo Alto Is Mostly About NAT
If you're moving from FortiOS 7.4 to Palo Alto PAN-OS 11.2, the security policy model translates cleanly — both vendors use zone-based policy with named address/service objects. The hard part is NAT. FortiGate supports two NAT modes: per-policy NAT (NAT enabled inside a firewall policy) and central NAT (separate config firewall central-snat-map table). Most production FortiGates use a hybrid — central SNAT + per-policy DNAT via VIP objects. Translating to Palo Alto requires unifying these into PAN-OS's flat NAT policy table while preserving evaluation order.
The other migration killer: FortiGate VIP objects with port-forwarding (config firewall vip with portforward enable) need to split into Palo Alto destination NAT + service object pair. A FortiGate VIP forwarding tcp/8443 → 10.0.0.10:443 becomes (1) a PAN-OS address object for the public IP, (2) a service object for the original tcp/8443, (3) a service object for the translated tcp/443, and (4) a NAT rule chaining them. NetConverter handles this VIP-to-DNAT split automatically and validates the result with a packet-tracer simulation.
Technical reference
Required inputs
Convert runs from a FortiGate configuration export (typically FortiGate.conf / full-config CLI dump). It is not a live SSH session and does not collect device credentials on the cloud convert path. On SaaS you upload that file to netconverter.ai (CloudFront → ALB → app). Configs leave the customer network on the SaaS path.
Supported on this path
- FortiGate is a full source and target platform. This guide targets Palo Alto SET, PAN-OS XML, and Panorama.
- Address objects and groups, custom services, and firewall policies with zone/interface mapping.
- NAT: per-policy NAT, central SNAT maps, and VIP / port-forward (including
match-vipintent documented in evidence). - VDOM boundaries mapped to vsys or Panorama device-groups (YAML v2 preset).
- Cisco ASA is source-only on other paths; FMC is destination-only and is not a source here.
Known gaps / engineer review
- Unused-object delete is not productized.
- Mixed TCP/UDP service objects still split to single-protocol PAN-OS services where required.
- UTM profiles (AV, IPS, web filter) are out of automatic policy translation — they land as Manual Steps with KB references.
- No Check Point output. Check Point is a separate source-only Handoff Bundle path.
Validation performed
- CP1 objects and CP2 features.
- CP3 references — deterministic parse-back; no AI.
- CP4a rulepacks: 152 rules / 13 packs (re-measured). CP4b is declared AI correction. CP4c is advisory only and cannot fail the translation.
- BC1–BC4 behavioral checks. BC4 (zone integrity) is a hard stop: serialize is not called when BC4 is BLOCKER.
- Status vocabulary: PASSED / PASSED_WITH_WARNINGS / NEEDS_REVIEW / BLOCKED.
What still requires an engineer
Review BLOCKED and NEEDS_REVIEW findings, confirm VIP/port-forward and VDOM/vsys mapping, choose App-ID vs service mapping, and own production cutover. Named findings are the review list — not a population accuracy percentage.
Data handling
SaaS uploads the export to NetConverter cloud. AI receives summaries and counts, not raw configuration or customer IPs. Device credentials are not stored on the cloud convert path. See encryption and data handling.
Synthetic example (not a customer)
Documentation addresses only (RFC 5737). Illustrative PAN-OS SET after a FortiGate VIP + policy export — not a customer config.
set address net-inside ip-netmask 192.0.2.0/24 set address host-web ip-netmask 198.51.100.10/32 set address host-web-pub ip-netmask 203.0.113.10/32 set service svc-web protocol tcp port 443 set rulebase security rules allow-web from untrust set rulebase security rules allow-web to dmz set rulebase security rules allow-web source any set rulebase security rules allow-web destination host-web set rulebase security rules allow-web service svc-web set rulebase security rules allow-web action allow set rulebase nat rules vip-web from untrust set rulebase nat rules vip-web to dmz set rulebase nat rules vip-web destination host-web-pub set rulebase nat rules vip-web destination-translation translated-address host-web
The Challenge of FortiGate to Palo Alto Migration
Policy Structure Differences
FortiGate uses policy IDs and interface-pair based rules, while Palo Alto uses zone-based security policies with different matching logic.
VIP to NAT Translation
Fortinet's VIP objects must be decomposed into Palo Alto address objects and NAT rules - a tedious manual process.
VIP and match-vip semantics
FortiGate VIPs pair with deny policies using match-vip to block traffic that does not hit a VIP. NetConverter preserves VIP shadowing intent when synthesizing Palo Alto NAT and documents version-specific match-vip defaults in the evidence report.
Service Definition Mapping
Custom services and service groups have different syntax and need careful mapping to preserve port definitions.
Address Object Conversion
Address objects, address groups, and wildcards need to be converted to Palo Alto's address object format.
How NetConverter Solves It
Vendor-Neutral Translation
Our comprehensive multi-step pipeline normalizes configurations to a unified format, so one parse can serve any supported target for that device class. Platforms have roles: some are supported as both source and target, some are source-only, and some are destination-only.
Intelligent Policy Migration
Policies are converted with proper zone mapping, maintaining security intent while adapting to Palo Alto's model.
Automated VIP Conversion
VIPs are converted to Palo Alto address objects and NAT rules with port-forward mappings. match-vip deny semantics are evaluated against FortiOS version defaults so VIP-shadowing behavior is not silently widened.
Service Migration
All service objects and groups are converted with port definitions and protocols preserved accurately.
Complete Object Migration
Address objects, groups, and wildcards are converted with naming conventions maintained.
4-Tier Validation System
Every translation undergoes comprehensive validation: syntax correctness, semantic accuracy, vendor best practices compliance, and AI-assisted review.
Confidence Scoring
Each conversion includes a confidence score indicating translation quality, helping you prioritize review efforts and ensuring production readiness.
See Quick Convert Output in Action
Representative Quick Convert run for this migration path — validated output, 26-section evidence report, and governed AI Studio explanations for change control.
Migration Results
Need Custom Development or Complex Migration Support?
For large-scale enterprise migrations, custom protocol requirements, or dedicated engineering support, our team is here to help.
Ready to Migrate?
Convert your Fortinet FortiGate configuration to Palo Alto PAN-OS in minutes. No credit card required.
Start Free MigrationFrequently Asked Questions
How does FortiGate central NAT translate to Palo Alto?
central-snat-map entries become Palo Alto NAT policies in source-NAT mode. Each entry's srcaddr + dstaddr + orig-port + nat-ippool maps to a PAN-OS NAT rule with bidirectional translation flagged appropriately. NetConverter preserves entry ordering — central SNAT order matters in FortiOS — and surfaces any rule that depends on FortiOS-specific behaviors (e.g., poolname referring to a depleted pool) in the Manual Steps section.What happens to FortiGate VIPs with port forwarding during migration?
portforward enable are split into a Palo Alto address object + service object pair + NAT rule. A VIP forwarding tcp/8443 → internal:443 becomes a PAN-OS address object, a service object for the external port (tcp/8443), a service object for the internal port (tcp/443), and a destination-NAT rule chaining them. The simulate_flow tool validates the resulting packet path post-migration.