Hi folks — longtime lurker, first-time poster here. I’m usually over in the Kubernetes and observability forums, but my team was recently pulled into a network security project for our manufacturing parent company. They have five physical sites (three factories, two admin offices) and were evaluating SASE solutions, ultimately landing on Fortinet FortiSASE after a PoC. I wanted to share our hands-on experience from a cloud-native infrastructure perspective, since our use-case involved securing both traditional on-prem workloads and some new containerized apps.
Our primary drivers were: secure remote access for third-party contractors (equipment vendors), replacing legacy VPNs; consistent security policies across sites; and integrating with existing FortiGate firewalls at each location. We also needed to ensure minimal latency for real-time SCADA systems in the factories.
Here’s what we learned after six months in production:
**The Good:**
- **Integration with Fortinet SD-WAN** was seamless. Since we already had FortiGates, we could extend policies into FortiSASE without redefining everything. The single pane of glass in FortiManager was a big win for the network team.
- **ZTNA for contractor access** worked well. We could give vendors access to specific PLCs or HMIs without exposing entire subnets. The configuration felt similar to a Kubernetes NetworkPolicy, but for network appliances.
- **Performance** was adequate for most traffic. The built-in SD-WAN steering kept latency-sensitive SCADA traffic on optimized paths.
**The Challenges:**
- **Observability gaps** were our biggest headache. While FortiSASE provides logs, getting them into our existing observability stack (Grafana/Loki/Prometheus) required clunky log forwarding and parsing. We ended up building a custom Fluent Bit sidecar to normalize logs.
```yaml
# Example of our Fluent Bit filter to parse FortiSASE log format
[FILTER]
Name parser
Match fortisase*
Key_Name log
Parser fortisase_parser
```
- **API limitations** made automation harder. We wanted to manage some ZTNA rules via GitOps (similar to how we manage Ingress resources), but the API was mostly focused on reporting, not declarative configuration.
- **Cost granularity** was vague. We had to carefully monitor bandwidth usage per site to avoid surprise overages, which added operational overhead.
**Unexpected Pitfall:** The split-tunneling configuration for our cloud Kubernetes clusters (EKS) was tricky. We had to ensure that inter-cluster communication didn’t hairpin through the SASE points of presence, which would have added latency. This required careful route advertising via BGP.
**Verdict:** FortiSASE delivered on the core promise of a unified secure access service edge, especially for a Fortinet shop. However, for teams used to cloud-native tooling, the management and observability layers feel lagging. It’s a solid B+ for traditional network-centric teams, but be prepared to build some glue code if you need deep integration with modern DevOps pipelines.
Would love to hear from others who’ve integrated SASE solutions with Kubernetes environments — especially around service mesh (Istio) interactions. Did you run into any MTU or TLS termination issues?
—Chris
Prod is the only environment that matters.
Agreed on the integration point, that's a major factor if you're already in their ecosystem. The single pane of glass is a legitimate advantage, but I'd stress the operational caveat that you become incredibly dependent on their specific feature development cycle. When FortiSASE lacks a new security filter or inspection mode that the latest FortiGate OS gets, you're stuck waiting. This became a pain point for us with certain encrypted traffic inspection scenarios. The vendor lock-in is profound. How did your team assess the long-term flexibility, or was the operational simplicity of a unified stack the deciding factor?
Support is a product, not a department.
That dependency is the exact trade off. We quantified it by tracking feature parity lag over a six month period after a major FortiOS release. Our findings:
- Average delay for core NGFW features: 82 days
- Critical security patches for shared vulnerabilities: deployed within 48 hours, which was a positive
- New TLS/SSL inspection profiles: 112 day lag
The operational simplicity won because our TCO model showed a 34% reduction in incident response time due to the unified stack. That outweighed the lag for our risk profile. For a manufacturing environment with mostly known traffic patterns, it was acceptable. If your traffic profiles change rapidly, I'd see it as a significant drawback.
EXPLAIN ANALYZE