Technical tip: SSLV PN split tunnel portal with policy-based destination behavior

[saleha]

Description	This article describes that it is common practice with SSL VPN portals to enable split-tunneling while using the 'Enabled Based on Policy Destination. Option allowing connected users to that SSL VPN tunnel to routes or subnets based only on the firewall policies 'destination' and 'outgoing interface' options.
Scope	FortiGate.
Solution	Using split-tunnel with firewall policy as the base for allowed subnet by default means firewall policies for the ssl.root interface cannot exist with a destination as 'ALL' addresses. That also means the user's internet traffic will use the home/remote office ISP directly instead of the ISP connected to the FortiGate except for specific destinations allowed on firewall policies where ssl.root is the 'incoming interface'. If a user account belongs to multiple user groups while each group is assigned a different portal, the first group the authentication daemon matches that user account with will force that user traffic to be controlled only by the matching firewall policy. This is important in the case of split-tunneling SSL VPN portals as it means the user will authenticate based on the order of the firewall policy that has that user group as the source and allowed subnets will be controlled by the policy that matches the group or portal the user connects with. common commands to troubleshoot users connecting to the wrong SSL VPN portal: exec vpn sslvpn list diag debug application sslvpn -1 diag debug application fnbamd -1 <----- In case of local user account. diag debug application radiusd -1 <----- Radius user account. diag debug application samld -1 <----- In case of saml authentication. diag debug console time en diag debug en