|
The following configuration is in place in the FortiGate, split tunnel is enabled, and it is set to allow access to subnet 192.168.10.0/24
config vpn ipsec phase1-interface
edit "RemoteAccessVPN"
set type dynamic
set interface "port1"
set ike-version 2
set peertype any
set net-device disable
set mode-cfg enable
set proposal aes128-sha256 aes256-sha256
set dhgrp 20
set eap enable
set eap-identity send-request
set ipv4-start-ip 192.168.33.1
set ipv4-end-ip 192.168.33.10
set dns-mode auto
set ipv4-split-include "net-192.168.10.0/24"
set psksecret ENC #####
next
end
config firewall address
edit "net-192.168.10.0/24"
set uuid 16f8e2ec-c488-51f0-a82a-0c98a754915c
set subnet 192.168.10.0 255.255.255.0 <-- Ensure that object is a subnet and not a range.
next
end
With this configuration, the FortiClient should inject a single route to 192.168.10.0/24 in the Windows routing table.
The IKE debugs on the FortiGate show that mode-cfg is sending the correct route for subnet 192.168.10.0/24. This can help confirm that the issue is not due to a misconfiguration on the FortiGate side.
diagnose vpn ike log filter rem-addr4 x.x.x.x
diagnose debug application ike -1
diagnose debug console timestamp enable
diagnose debug en
...
2025-11-19 02:14:45.005897 ike V=root:0:RemoteAccessVPN_0:233751: processed INITIAL-CONTACT
2025-11-19 02:14:45.006559 ike V=root:0:RemoteAccessVPN_0:233751: mode-cfg assigned (1) IPv4 address 192.168.33.1 <-- FortiGate assigns IP address 192.168.33.1 to VPN client.
2025-11-19 02:14:45.007340 ike V=root:0:RemoteAccessVPN_0:233751: mode-cfg assigned (2) IPv4 netmask 255.255.255.255
2025-11-19 02:14:45.008123 ike V=root:0:RemoteAccessVPN_0:233751: mode-cfg send (13) 0:192.168.10.0/255.255.255.0:0 <-- FortiGate is sending the correct route 192.168.10.0/24.
2025-11-19 02:14:45.008903 ike V=root:0:RemoteAccessVPN_0:233751: mode-cfg send (3) IPv4 DNS(1) 192.168.10.2
2025-11-19 02:14:45.009649 ike V=root:0:RemoteAccessVPN_0:233751: mode-cfg send (3) IPv4 DNS(2) 8.8.8.8
2025-11-19 02:14:45.010357 ike V=root:0:RemoteAccessVPN_0:233751: mode-cfg send INTERNAL_IP6_SUBNET
2025-11-19 02:14:45.011050 ike V=root:0:RemoteAccessVPN_0:233751: mode-cfg IPv6 DNS ignored, no IPv6 DNS servers found
2025-11-19 02:14:45.011852 ike V=root:0:RemoteAccessVPN_0:233751: mode-cfg send APPLICATION_VERSION 'FortiGate-VM64-KVM v7.4.8,build2795,250523 (GA.M)'
2025-11-19 02:14:45.012842 ike V=root:0:RemoteAccessVPN_0:233751: mode-cfg send (28673) UNITY_SAVE_PASSWD
...
The Windows routing table 'route print' shows that a new default route pointing to the VPN interface was injected instead of the route to 192.168.10.0/24. The machine is ignoring the route 192.168.10.0/24 sent by the FortiGate.
This behavior is sometimes observed when the FortiClient is upgraded from version 7.2.x to version 7.4.3. At the time this article was redacted, the issue had not been reproduced in FortiClient version 7.4.4.
This issue is caused by the presence of multiple FortiClient VPN adapters in the machine, and there are two known solutions.
Solution 1: Delete the extra VPN adapters (those marked with #2) from Device Manager, then reboot the machine.
Solution 2: Uninstall FortiClient from the impacted machine, reboot, and reinstall FortiClient.
After connecting, the route table will successfully show the route to 192.168.10.0/24, and the additional default route will no longer be present.
Related documents:
Technical Tip: Enable split-tunnel For IPsec VPN
Uninstalling FortiClient
Technical Tip: How to uninstall a managed FortiClient in Windows Machines
|
