FQDN through Split tunnel overrides the default route and block internet for MAC users

[yanivg11]

Hi All,

We have followed this article to set FQDN access using Split tunnel:

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Access-to-Specific-FQDN-using-Split-Tunnel...

The users are able to access the FQDN thought the split-tunnel as expected.

However we noticed that MAC users are unable to browse internet while connected with FortiClient.

While looking into this we noticed that both Windows users and MAC users get a new default route when connecting with FortiClient.

But while Windows users are still able to browse the internet, MAC users are not.

First screenshot is from Windows user with FortiClient connected, this user is still able to browse the internet although the new default route:

Second screenshot is from MAC user, before and after FortiClient connected,

Once the FortiClient is connected this user is unable to browse the internet:

Any advice? tnx

[AEK]

Hello @yanivg11 

In split tunnel mode a defaut route through tunnel should not be injected, but only routes to specific resources. However in your screenshots we can see that default gateways were injected.

Check it any ssl vpn related policy contains "any" as destination. If so, remove it and put the specific internal destinations instead, then try reconnect to VPN to check if specific routes are injected instead of default GW.

[yanivg11]

hi AEK, thank you for your reply, I have checked the policy but we have no "ANY" as destination for our SSLVPN groups.

[AEK]

Hi @yanivg11 

As stated in the document, unresolved FQDN can cause connection failure (they didn't tell what they mean by failure but it might be a similar case as yours).

So I suspect the issue is caused by some problematic FQDN.

If possible, just as a test, replace the FQDN in the policy by their actual IP addresses, then redo a VPN connection test.

After that if you still have a default address pushed to your client then you can exclude this from being the root cause.

[yanivg11]

hi AEK,

I have removed all FQDN from the rule and kept only 8.8.8.8 as IP, not name:

* the test group "Dynamic_Test_Group" isnt in any other rule, only this one

however the extra route still showing after the ForitClient gets connected:

[AEK]

Hi @yanivg11 

This shouldn't be.

Then I suggest first update FortiClient to 7.0.14 since there are several split tunnel related issues on 7.0.9.

https://docs.fortinet.com/document/forticlient/7.0.9/windows-release-notes/991883/known-issues

[yanivg11]

Hi AEK,

First thank you for all your help.

Just fyi, I went even further and removed the "Dynamic_Test_Group" from all policy rules,

yet I'm still getting the extra route once the FortiClient connected, meaning that it is coming from the Portal mapping:

[hbac]

@yanivg11,

If you removed the "Dynamic_Test_Group" from all policies, you should not be able to connect to the VPN. Please make sure you are connecting to the correct SSLVPN portal. You can check the log to verify that. Also make sure there's no SSLVPN policies with destination=0.0.0.0/0. 

Regards, 

[yanivg11]

Hi I thought so also, however even though that the group does not exist in any policy, the VPN connection keep working.

I believe this is a difference in the behavior between static to dynamic portals.

I have upgraded the FortiClient on both Windows and MAC.
For Windows it is now  - 7.2.3.0929

For MAC it is now - 7.2.3.0822

After the FortiClient upgrade:

For Windows - the extra default route issue disappeared completely.

For MAC - same issue, the extra route is still added and the internet keep getting blocked.

[AEK]

I think, since the latest FortiClient patch has fixed Windows split tunnel related issue, I think Fortinet will/should do the same for Mac soon.

Try open a ticket to speed up this fix, or they can even send you a quick patch.