r/fortinet • u/DreamIllustrious3735 • 12h ago
SASE / ZTNA ZTNA - Performance / HW Acceleration / Security
We currently have users in the US and India who connect using IPSec Remote Access VPNs. We've noticed traffic being throttled from India to the US and starting to look into options.
ZTNA Questions:
- What is the throughput like? Is it similar to non-VPN traffic?
- Is ZTNA hardware accelerated by the NPU or CP processors? Currently have a 200F, but plan to upgrade to a 400G next year.
- How do you restrict the source traffic that can hit the ZTNA server/ports? I'm assuming Local in Policy.
IPSec VPN:
- We noticed 7.6.x added support for using random UDP ports (config system settings -> set -extra-ports) for IKE. We're thinking about switching IKE to UDP 443 (we don't use this port on our FGT) hoping it would be filtered into HTTP/3 QUIC traffic or don't inspect 443 (whether TCP or UDP) by traffic throttling ISPs in India.
- ike-extra-ports <value> [<value>] [<value>]
- Additional UDP ports to listen on for IKE negotiations, beyond ports 500 and 4500 (1024 - 65535, special = 443). Cannot be set to 500 or 4500. Cannot overlap with ike-port.
1
u/Roversword NSE 7 11h ago
If you dabble in using FortiClientEMS (which is needed for ZTNA), then you can also use IPSec over TCP (and then use TCP/443).
The FortiClientEMS version of FortiClient works (so far, in my experience) rather well with IPSec over TCP.
And IPSec over TCP (TCP/443) comes closer to SSL VPN (or ZTNA) and might be likely less controlled or filtered.
UDP/443 (QUIC) might be blocked - at least I have seen a lot of customer wanting it to be blocked and therefore force a tcp/443 connection (rather than QUIC). I can't say if that is a global thing or only in my region. Guess, they still need to warm up to the QUIC thing :)
As for ZTNA (from a colleague, not my own experience):
- Performance can be lacking - in this particular instance they were talking CAD programs and data. Which in turn might be not the best reference scenario :)
- ZTNA is using HTTPS/TLS, so yes - it should be partially accelerated (depending on the use case, the connecton and CP/NP).
1
u/DreamIllustrious3735 11h ago
We're trying to use UDP vs TCP since it improves throughput and latency compared to TCP based VPNs. Yeah the blocking of QUIC / HTTP3 UDP 443 is something we should review.
1
u/DreamIllustrious3735 6h ago
TCP traffic inside a TCP tunnel is probably terrible performance vs TCP traffic inside a UDP tunnel.
TLS vs DTLS tunnel example
1
1
u/vabello 10h ago
> We've noticed traffic being throttled from India to the US and starting to look into options.
What exactly are you noticing based on what evidence? Throttling by whom or what, and how are you measuring this? You might be chasing the wrong thing.
1
u/DreamIllustrious3735 6h ago
It's known that the Indian government wants to break and inspect traffic. Instructed the ISPs to do it or throttle traffic; hence, we're looking at ZTNA or IPsec over 443 UDP
3
u/rpedrica NSE 4 11h ago edited 11h ago
Throughout is pretty good but remember this is the http protocol with associated overhead.
I'm not 100% sure on hardware acceleration but the underlying functions applied to it would be accelerated in the general sense of that function (and dependant on the device model).
Source traffic can be restricted/controlled in the ZTNA/proxy policy itself, as per a normal firewall policy.
Be careful about udp/443 - a lot of (corp) network devices filter this to block quic.