Many interfaces when using VPN

[captainit]

Hello,

We have a problem with our VPN.

We are experiencing an issue that occurs once every month, where employees (it changes - skipping between users) using only Mac computers come to the office (but happens also in their home wifi) and are unable to access internet when they are connected to VPN.

We use:
Forticlient vpn only free - last version

IPSEC VPN

When they try to ping servers/addresses: sendto no buffer space available

When it happens I see many interfaces with addresses of VPN (192.168.11.0/24). 
After disabling interface with VPN: ifconfig interface utun4 down - internet works!

Another user told me: WIFI works, VPN works. He leaves the computer, computer goes to sleep mode and after that Forticlient seems as connected but no internet!

Another user reported: I was on the train, using HOTSPOT and Forticlient. 

Close the lid (So internet was disconnected). Went to the Office, I was connected to Office's WIFI and had this problem of buffering.

Why are there many interfaces instead of just one? Why does FortiClient create multiple connections?

#Same user#Same user#Same user#Another user

Thanks

[captainit]

OK. I will take debug logs and update.
Thanks

[captainit]

Didn't help. A new user with old version has this problem of multiple versions again - this is his connection:
2.10 is the last day when the user was connected via Forticlient

Yersterday 6.10 he had this problem - 192.168.11.0/24 is the segment of the Forticlient and he was also connected together to the WIFI - 192.168.0.0/24 - forticlient did not flush the old network configuration of VPN - he was not connected to Forticlient VPN

I don't know what to do :( It seems that Forticlient do not flush old connections sometimes.

Please help. Thanks

[AEK]

Anything relevant in FortiClient logs or in system event logs?

In FortiClient you can export the logs then try search around the time of the issue.

On MacOS I'm not sure but it should be in /var/log/system.log and with Console app (try to filter on network logs).

[captainit]

Attaching file of the logs from Forticlient:
The problem appears yersterday (In my clock time it is around 08:45-09:15 AM)

Thanks

[AEK]

By the way there is a known issue on 7.4.0 and some 7.2.x versions. This bug looks the same as yours but it affects ZTNA instead of IPsec.

1012318

Endpoints cannot connect to ZTNA after sleep or lid is off/on.

[captainit]

Hello,
I’m having trouble understanding an issue with the IPsec configuration in FortiClient VPN. We initially set the local ID in Phase 1 to a group using a full tunnel. Later, we changed it to a local ID with a split tunnel in the same client. However, after the computer wakes up from sleep mode, users seem to reconnect to the full tunnel. I can tell this because I’ve written a script that kills FortiClient if the public IP matches the office's public IP.
What can I do to resolve this issue?
Please help

[AEK]

Hi Captain

Can you share the routing table before and after wake up?

On the other hand did you manage to fix the initial issue?

[captainit]

We have reinstalled Forticlient for this user so now it is working again.
I don't know what to do, really...........

I just know that for sure he received the public IP of the office because I have script that if the public IP of internet is the same IP of office - kill Forticlient and it does.

[captainit]

This is my configuration for my IPSEC VPN in Fortigate,

Can I do something that may solve it?

[AEK]

Your screenshot shows only a little part that can't help. But I guess you enabled IPv4 split tunnel, right?

However I don't think the issue is from FG side since your client connects first with split tunnel successfully. So I think the issue is from client side.

Can you share the client's routing table before and after wake up? You can hide the public IP addresses before sharing.