If not this will set up a second default route on your client upon dialling in successfully.
Accoarding to the metric of the default routes this may result in what you get (or not get).
Because lowest metric serves first traffic to your internal subnet that shuld go over the vpn might take the wrong way and so will not reach its destination.
If you enable split tunneling your client's default route will not be touched and a static net route for every subnet specified in split tunneling on the FGT will be rolled out upon dialling in. This is unique then and cannot go wrong way.
you could check this either by deleting your default routes and then set only one up for the tunnel - or manually add a net route for the internal subnet on the client with correct gateway.
I enountered this several times while setting up vpn ipsec tunnels during the last weeks especially on windwows clients.
"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
In case split tunneling, the first thing you need to check is if the client machine pulled the internal network prefixes into the routing table, or not, in order to isolate the issue either at the FGT side or the client side. With Windows, "route print", with Mac, "netstat -nr".