Ssl.root interface and problem with route tables

Hello everyone, I’m looking for some help with a bizarre issue I’m running into while setting up a customer with ssl-vpn access resulting in their route table populating with subnets that are not apart of their policy.

On the same azure based fortinet I have ssl-vpn setup for remote staff use. I need to setup another company with access to some resources through the same fortinet. I created a ssl-vpn portal for the customer so I could split dns setting and let them use their own. I gave them a user group and their own vpn pool for security and policy setup.

The problem I’m running into is that when I test connection the route print is populating static routes to subnets that do not belong to the policy. The only correlation I can find is that the policies that involve these subnets use the same ssl.root interface. Can anyone help me understand why this is happening and how to stop subnets outside of their policy from populating on their route print?

I appreciate any and all help, thank you so much all.

Your policies are wrong. The routing table gets what matches, so you match too much. Either you fix your policies or you override the routing addresses in the SSL-VPN portal and don’t let the split tunnel decide the routes based on policy destination.

Are you always using group as source/destionation firewall policy with ssl.root interface?
Are you using “any” as some source/destination interface?

my typical ssl-vpn policy is src ssl.root, from (vpn pool) (user group), dst (LAN) to (Subnet).