SSLVPN not routing correctly for SSL VPN "Enabled Based on Policy Destination"

Hi Ahuj,

Thank you for reaching out. Fortigate provides the sslvpn connected client with routes only when the client successfully connects to the vpn. No further routing updates to the client until the client disconnects and reconnects again. What is the type of routing happening here on this site is it dynamic or static. what is the routing path to the destination with the 2-ip addresses. Can you share more details on how does the FQDN or hostname have 2 ip addresses - i.e. how the 2 servers or boxes hosting this FQDN are working together, active-passive, each cover requests from specific sources, etc - also one way to look a solution is to use address override and provide the 2 ip addresses for the hostname in one or 2 address objects. This way both destinations will be advertised to the connecting vpn clients.

Commands to troubleshooting routing issues:

# diag sniffer packet any "host x.x.x.x or y.y.y.y" 4 0 l ------- provides source, destination and direction of trafffic to x.x.x.x or y.y.y.y

# get router info routing-table all

# get router info routing-table details x.x.x.x  -------- can be a subnet or single ip

# diag sys session filter dst x.x.x.x --------- you can add other filters to limit session list command output to specific session(s)

# diag sys session list

# dia de flow filter addr x.x.x.x

# diag de flow show function-name enable

# diag de flow trace start 10

# diag de console time en

# diag de en

Thank you,

saleha

Hello Saleha,

Thanks for your information and input about updating routing tables on client side.

This means a client that is connected since hours does not get populated with latest routes, when there may have been an IP-Change.

We're using AWS Cloudfront for several services, which causes changes of IPs randomly.

For some services we have just a loadbalancer which serves 1 to 4 IPs. (mostly 2)
Sadly, it's not a solution to add 2 address objects for services like that.

Thank you!

Hi ahuj,

Thank you for the reply. That does create a concern since the destination is in such a dynamic nature there may be a need to provide a large summary route to include all possible ip addresses in the policy or the the override addresses list on the vpn portal settings. Alternatively this can be handled by jump box where sslvpn users connect to single computer or VM behind the firewall and use that box to access the destination by hostname. I still have to understand if the destination can have variation in addresses based on the nature of cloud services, what routes are used to access these services or how does rout change for the destination service or server users are trying to reach. You did mention that routing table gets updated with different addresses for the same destination so I assume you are useing ISDB routes deployment which would act as a policy route rather than adding directly an active route in the routing table or maybe you are using sdwan rules with application control.

The use of jump box as a solution here does come with the caveat of additional resources to deploy and manage as well as the additional firewall policies or rules to control and secure this traffic.

Thank you,

saleha

Hi ahuj,

Thank you for the reply. Apologies for the confusion I did forget to check the firewall policy screen shot when I sent my second reply. The policy is using an ISDB address object which is dynamically updated by fortiguard as long as the license is active and the connection to fortiguard update servers is solid. Since the sslvpn portal is using policy-based split tunnelling and no address override that should allow forticlient to obtain routes for the whole list of ip addresses collected from the ISDB address object for the AWS entry. As mentioned before forticlient does obtain the routing table only when it connects to the vpn and no periodic updates while it stays connected. I would recommend a support ticket based on what you mentioned about the policy not have much hit count. The sniffer command and debug flow can help with checking the traffic also "Forware traffic logs" would help identifying if there are packets being denied or matching wrong policy for example.

Thank you,

saleha