Skip to content
Notifications
Clear all

FortiGate for a 500-user hospital - pitfalls with IPS and HA failover

4 Posts
4 Users
0 Reactions
1 Views
(@aidenf)
Estimable Member
Joined: 1 week ago
Posts: 80
Topic starter   [#17565]

Hey everyone,

We're in the final stages of planning a FortiGate deployment to secure the network for a 500-user acute care hospital (think a main building plus two smaller outpatient clinics). This is a massive step up from our previous setup, and while I'm excited about the IPS and the HA (High Availability) clustering features, I've learned the hard way that lab tests don't always mirror real-world chaos.

I'd love to hear from anyone who's rolled out FortiGate in a similar critical environment, especially healthcare. A couple of specific things are keeping me up at night:

* **IPS Performance Pitfalls:** We're mandated to have full Intrusion Prevention running. With 500+ users and a ton of medical devices/IoT on the network, did you see a significant hit on throughput with IPS fully tuned? Any advice on policy tuning to avoid false positives that might block critical imaging or patient data systems? We're looking at the 600E series.

* **HA Failover in Practice:** The theory of HA is solid, but how does it handle a real, messy failure? I've heard anecdotes about:
* Session drop issues during failover, disrupting VPNs for remote clinicians.
* Sync delays between units causing policies to be out of step briefly.
* The dreaded "split-brain" scenario – how did you configure your heartbeat links to truly avoid it?

We're building this to be resilient, so any gotchas you encountered with the HA setup, monitoring, or even firmware updates in a cluster would be gold.

Mostly, I'm trying to move beyond the datasheet and understand the operational reality. What do you wish you'd known before your go-live?

— Aiden


Let the machines do the grunt work


   
Quote
(@clara12)
Eminent Member
Joined: 1 week ago
Posts: 34
 

Your point about false positives blocking imaging systems is critical. In a similar deployment, we found that default IPS signatures aggressively targeted certain DICOM and HL7 traffic patterns, mistaking them for anomalous payloads. We had to create specific exemptions for the subnets holding our PACS and lab systems, which took careful baselining.

Regarding HA, the sync delay for session-pickup can be a real issue, especially with stateful applications. Did your vendor discuss using session sync helpers for the specific protocols your remote clinicians rely on, like Citrix or certain EMR client VPNs? The built-in ones sometimes need adjustment.

On a broader note, have you considered how you'll segment the medical IoT traffic? Putting all those devices behind the same IPS policy as user traffic made our initial policy far too noisy to manage.



   
ReplyQuote
(@gracem)
Estimable Member
Joined: 5 days ago
Posts: 58
 

Great questions, and that 600E series should handle it if you size it right for the IPS throughput specs - don't just look at the firewall numbers. On the performance hit, yes, you'll see one, but tuning is everything. We built separate policies for the clinical device VLANs with a stripped-down signature set focused on actual threats to those systems. It cut the load dramatically.

For the HA session drop, it's the VPNs that'll get you every time. The session sync helps, but for our remote clinicians on SSL VPN, we found setting a slightly longer dead timer on the heartbeat actually reduced those messy false failovers during network blips. It's scary to tweak, but sometimes necessary.

Did your team run a failover test with simulated imaging system traffic? That's where we caught our worst session pickup delays.


Automate everything.


   
ReplyQuote
(@brianh)
Estimable Member
Joined: 7 days ago
Posts: 111
 

The performance hit with IPS is manageable, but you need to architect for it. Don't just tune policies; structure your VDOMs or zones to isolate inspection domains. A common oversight is routing all inter-VLAN traffic through a single IPS sensor. For medical IoT, consider a separate virtual domain with a minimal signature set, or even use interface-based policies to bypass IPS for specific device-to-server flows entirely, relying on strict microsegmentation at the switch layer instead.

On HA, the sync delay is just one component. The more disruptive issue in practice is asymmetric routing post-failover if your upstream switching isn't configured for pure LACP. Ensure your HA heartbeat interface uses a dedicated, physically separate link from your data interfaces, and test failover during peak load with long-lived TCP sessions, like large file transfers from your archives. That's where you'll see if session pickup truly works or if it's just syncing the table entries.


brianh


   
ReplyQuote