VPN IPSec macOS Route Issue

Forum|Forum|16 days ago
July 22, 2026
11 replies
205 views

Hi everyone, I'm experiencing a strange issue with an IPsec Dial-up VPN after migrating users from SSL VPN. The environment is FortiGate 400F with FortiClient VPN 7.4.3.4323 on macOS Sonoma 14.1. The problem only affects macOS clients; Windows clients using the same VPN configuration and user account work correctly. Split tunneling is enabled, and all firewall address objects are configured correctly as /24. However, after connecting from macOS, one of the split-tunnel routes is installed with an incorrect mask (for example, 10.10.10.0/24 becomes 10.10.10.0/31). If I remove that subnet from the split-tunnel group, the issue moves to the next subnet (10.10.11.0/24 becomes 10.10.11.0/31), so the problem follows the route order rather than a specific network. I also tested with a split-tunnel group containing only three networks, and everything works correctly on macOS. The production split-tunnel group contains around 190–200 routes. Has anyone encountered a similar issue or knows whether this is a FortiClient/macOS limitation or a known bug?

FortiGate

Best answer by MustaphaJAMAL

UPDATE / RESOLVED:

I identified the root cause with Fortinet support.

Root Cause: FortiClient for macOS allocates a fixed 4,096-character array to store IPsec split-tunnel routes. Because my production list had ~180–200 subnets, it hit this character limit. Once full, FortiClient truncates the final route before sending it to the macOS routing table, corrupting its /24 mask into a /31.

Solution: Reduce the total size and character length of the split-tunnel address group on the FortiGate:

What worked for me: I removed unused subnets, bringing the list down from 184 to 170 entries, which dropped the total characters back under the limit and fixed the /31 issue.
Permanent Recommendation: Summarize contiguous subnets (e.g., combining adjacent /24s into /22 blocks) on the FortiGate to keep the split-tunnel list safely under 128 subnets.

funkylicious

SuperUser

try using an older version of FCT, like 7.2.13.1121

"jack of all trades, master of none"

M

MohammedAlrawiii

Explorer

Did this resolve the issue ?
am facing the same issue here

Toshi_Esumi

SuperUser

In addition, I would try upgrading the Sonoma, which likely the cause.

Toshi

Toshi_Esumi

SuperUser

I would try upgrading the old Sonoma, which likely the cause. The last subversion of Sonoma was 14.8.7.
https://en.wikipedia.org/wiki/MacOS_Sonoma

Toshi

M

MustaphaJAMALAuthor

Visitor III

I tried it, but it didn't solve the issue.

M

MustaphaJAMALAuthorAnswer

Visitor III

UPDATE / RESOLVED:

I identified the root cause with Fortinet support.

Root Cause: FortiClient for macOS allocates a fixed 4,096-character array to store IPsec split-tunnel routes. Because my production list had ~180–200 subnets, it hit this character limit. Once full, FortiClient truncates the final route before sending it to the macOS routing table, corrupting its /24 mask into a /31.

Solution: Reduce the total size and character length of the split-tunnel address group on the FortiGate:

What worked for me: I removed unused subnets, bringing the list down from 184 to 170 entries, which dropped the total characters back under the limit and fixed the /31 issue.
Permanent Recommendation: Summarize contiguous subnets (e.g., combining adjacent /24s into /22 blocks) on the FortiGate to keep the split-tunnel list safely under 128 subnets.