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

[ahuj]

Hello,

we have SSL VPN enabled for our employees, based on policy destination.
with that we're routing only certain services via VPN to for example whitelist our public IP for services and make a service reachable for employees.
the rule contains an address group which contains several FQDNs.

The problem we see here randomly is that the firewall resolves 2 IPs for an FQDN, which is fine and intended, but the routing table on client side only contains 1 sometimes.
"suddenly" (without reconnecting or similar) the 2nd IP also appears in the routing table, but why? So randomly its working or not working to get routed via VPN.

As it is not working properly to route all needed traffic via our SSL VPN we added a 2nd rules directly below the main one.
that new rule should route all “amazon aws” traffic via VPN - this was implemented for testing and troubleshooting.

This rule does not get hit very often, assuming the routing table does not get populated with all routes, as routing all amazon-AWS traffic should cause quite a lot requests be routed via VPN.

How often does the vpn client of fortinet update the routing table and are there any limits of routes that can be set?

[saleha]

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

[ahuj]

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!

[saleha]

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

[ahuj]

Hello Saleha,

thanks for your Input.

A Jumpbox is not a solution for us.

I'm not sure if we are talking about the same and you exactly see our issue.

the above shown rules are in place and several FQDNs should be routed via VPN. it works most of the time, but sometimes it happens, that without disconnecting/reconnecting a Client only has 1 IPs instead of 2 for example. But how can that happen when the VPN Client only sets the Routes upon connect?

To that first rule we added another rule which should route all AWS traffic via VPN. but as this should cause quite a lot of traffic we're wondering why it does not get hit very often.

It seems the routingtables on client side is limited and do not get all the IP ranges when establishing a vpn connection.

i added the screenshots of the rule-based-vpn-portal and the rules. So i'm not sure what information else i can add to make it more clear to you. maybe we have a misunderstanding of the issue.

thanks a lot for your help!

ahuj

[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