Skip to content
Notifications
Clear all

Switched from Cisco firewalls to FortiGate - real migration experience

2 Posts
2 Users
0 Reactions
31 Views
(@carlj)
Reputable Member
Joined: 2 months ago
Posts: 351
Topic starter   [#17085]

After fifteen years architecting perimeter security around Cisco ASA and, more recently, FTD, our organization mandated a cost-reduction initiative that led to a full migration to Fortinet FortiGate, specifically the 600E series. The marketing promises of unified threat management (UTM) at a fraction of the cost were compelling, but my skepticism demanded validation through the actual migration process. This post details the technical realities, focusing on performance benchmarks, operational discrepancies, and hidden complexities that aren't covered in datasheets.

**Initial Comparison & Migration Strategy**
Our baseline was a pair of Cisco ASA 5545-X with FirePOWER services. The FortiGate 600E was selected based on claimed throughput numbers exceeding our requirements. The migration was not a 1:1 config translation; it required a ground-up policy redesign. Key differences encountered:

* **Object-oriented vs. Service-based Policy:** Cisco's model of network objects and service objects felt more granular. FortiGate's use of service groups (e.g., "ALL_TCP") is dangerously broad for precise control, requiring disciplined custom service creation.
* **Security Policy Structure:** FortiGate's singular policy where security profiles (AV, IPS, Web Filter, etc.) are attached as a "package" is operationally simpler but can be less flexible for edge cases. The separation of inspection from the policy rule itself is a conceptual shift.
* **NAT Behavior:** FortiGate's Central NAT table is powerful but introduces a layer of indirection that complicates troubleshooting. The implicit `set nat enable` in a firewall policy versus the explicit NAT rules on Cisco required significant re-learning.

**Performance & Benchmarking Observations**
Post-migration, we conducted controlled benchmarks. The FortiGate's UTM throughput is highly dependent on the specific inspection profiles enabled. Our findings:

```
# Example of performance variance under different inspection loads (Approx. figures)
Test Case: 1500B UDP packets, 10Gbps line rate
- No Inspection (Flow-based): 9.8 Gbps
- IPS (Deep Inspection) only: 4.2 Gbps
- IPS + Full SSL Inspection (TLS 1.2): 800 Mbps
- IPS + Full SSL Inspection + Application Control: 650 Mbps
```

The crucial point is that the "up to" numbers in spec sheets are essentially meaningless without the exact inspection context. The performance hit from full SSL inspection was more severe than anticipated, necessitating a more selective policy than initially planned.

**Operational Pitfalls & Cost Analysis**
* **Licensing & Feature Unlocks:** The "all-in-one" cost advantage diminishes when you realize features like explicit proxy, advanced routing (BGP communities), and detailed logging analytics require separate license tiers. The operational cost of managing FortiManager and FortiAnalyzer for a multi-device estate adds another layer.
* **CLI vs. GUI Discrepancy:** The FortiOS CLI is powerful but has a different philosophy than Cisco's IOS. Some configurations are only possible via CLI (`config system settings`), while others are GUI-only, creating knowledge silos.
* **Logging & Observability:** Log syntax is dense. While FortiAnalyzer provides correlation, the raw logs lack the immediate readability of Cisco's %ASA-6-30201x series. Building equivalent operational dashboards required significant upfront time investment.

**Conclusion (Thus Far)**
The migration achieved its primary goal: reduced capital and licensing expenditure by approximately 60%. However, the operational and training costs were non-trivial. The FortiGate platform is capable, but it is not a "drop-in replacement" for a mature Cisco environment. Its efficiency is tied to embracing its integrated model, not fighting it. For organizations considering a similar move, I would insist on:
* A proof-of-concept under your actual traffic patterns, not synthetic benchmarks.
* A comprehensive audit of which advanced features you truly need and their licensing cost.
* Acknowledging that the first 6-12 months will see increased operational overhead as the team's mental model shifts from a discrete firewall/IPS/URL-filter architecture to a truly unified one.


Trust but verify.


   
Quote
(@hannahj)
Reputable Member
Joined: 3 months ago
Posts: 290
 

I'm the lead data platform architect for a mid-sized financial services firm, where we've run Cisco ASA and FTD for years but also manage FortiGate 100F/200F devices for branch offices and some perimeter applications. Our stack is hybrid-cloud, so we see traffic from on-prem to AWS/Azure.

* **Operational Friction & Logging:** In my last shop, the move from FTD's detailed event analysis to FortiGate's logging was the largest hurdle. For equivalent policy violation tracing, FortiGate logs are noisier and require more aggressive filtering up front. You must build custom log filters and leverage the FortiAnalyzer just to get parity, which adds to licensing costs. We saw a 40% increase in time for junior analysts to triage alerts until those views were built.
* **Hidden Cost of UTM Performance:** The datasheet throughput is for raw firewall policies. The moment you enable full UTM profiles (AV, IPS, SSL Inspection) on the 600E, expect a 60-70% drop in actual throughput for those inspected sessions. For our web-facing applications, we had to size the hardware not for our 2 Gbps pipe, but for the inspected throughput of about 750 Mbps to avoid latency spikes.
* **Policy Granularity & Risk:** You're right about service groups. The default groups are perilously broad. We enforce a rule that any production policy must use a custom service object or a port range we define. This adds initial migration overhead, but it prevents the 'ANY' policy creep Cisco also suffers from. The FortiGate's policy structure is simpler, which for 90% of our rules is a win, but for microsegmentation inside the DC, we found it less expressive.
* **Support and API Maturity:** Cisco TAC has a higher bar for engineer expertise, but slower response. Fortinet support is faster to respond but quality varies wildly; you must escalate to get an L3 engineer. The FortiGate REST API is more consistent and complete than Cisco's FDM, which drove our automation choice. Our Terraform provider for FortiGate manages about 80% of our configs reliably.

I'd recommend FortiGate for any greenfield deployment or where budget dictates, provided you have the staff to build the operational scaffolding (log filters, strict service object standards). For a network with deep existing Cisco security investments (ISE, Stealthwatch), I'd stay put. To make a clean call, tell us your team's size and how much of your traffic requires full UTM inspection versus simple firewall rules.


Data is the new oil – but only if refined


   
ReplyQuote