Very slow responses to anything internal when connected to ssl vpn

[the_rock]

Hey guys,

Please bear with me here, as I work way more with couple other vendors, though I would say Im fairly verse when it comes to Fortinet : - ). Anyway, here is the scenario. Customer purchased 2 brand new 200F firewalls and we have really odd problem and my colleague (who btw is real Fortigate guru) are having heck of a time trying to fix this problem. Essentially, even if single person is connected to ssl vpn, responses to anything internal are real slow and ping times can go up to 2000 seconds. We tried failover, no luck, disabled assic offload for ssl vpn rule, tested multiple barebone forticlient versions (no luck), enabled DTLS tunnel option, same issue.

Now, there are only maybe 6-7 security rules configured, so its super basic. We even have TAC case open for this for about a week, but since they cant replicate it, guy suggested to try reboot the current primary firewall. I have no clue if that will help, as it has been up for only 35 days, but it would need to be scheduled with the customer.

Also, maybe worth pointing out, ssl vpn rule does NOT have any security profiles configured at all.

This week, I attempted things from below posts, but same issue persists.

Troubleshooting Tip: ‘SSL-VPN slow file transfer ... - Fortinet Community

Solved: SSL VPN poor speed - Fortinet Community

Fortigate slow SSL VPN throughput : r/networking (reddit.com)

Current version is 7.2.5

Any help/suggestions are welcome and highly appreciated!

Thanks so much in advance.

Kind regards.

[Dannу]

Hi Andy,

if TAC cannot replicate it, can you replicate it in a lab to be able to further troubleshoot it without having to ask the customer for maintenance windows?

[the_rock]

Hey Danny,

Well, when I test this from my own work laptop or even my personal desktop, I have exact same issue.

Andy

[Dannу]

Perfect. So reboot your lab firewall that shows the same symptoms and you are able to reply to TAC.

[the_rock]

Im not connected to lab firewall. What Im saying is when I connect to their ssl vpn from my work laptop using forti client, I have exact same issue.

[Dannу]

I understand that. In order to avoid asking your customer for a maintenance schedule I recommend that you first try to replicate the issue on a lab FortiGate. That's what I do for our customers all the time.. trying to replicate the issue.. then fixing it in the lab.. after solution has been found.. inform the customer and perform the change in the customers' production environment.

Setting up a lab is free and easy. Just download a FortiGate VM issue of the same FortiOS version that is in use at your customers' producation environment. Import the and adjust the configuration and ready to test.

[the_rock]

See, thats the issue, we cant replicate it in our lab either...

[Dannу]

Then I only see two options:

• ask the customer regarding the reboot as advised by TAC
• ask the customer to send you the standby appliance to be able to test with that one in your lab

[the_rock]

Let us see if they approve the reboot, it might help.

[Yurisk]

Hi, sorry for the late reply, I see 2 ways - Short one and Long one, I'd start with the Short.

Short:

• Upgrade to 7.2.6, on 10th of October Fortinet released PSIRT alert on versions including 7.2.5 on password disclosure in SSL VPN https://www.fortiguard.com/psirt/FG-IR-23-120 so it would be a great "selling" point to the client. On the way it will do a reboot, and make sure you haven't stumbled on a hard-to-replicate bug in 7.2.5. In general, with FortiOS, the convention is to deem versions up to x.x.6 as QA releases. I've started deploying 7.2.6 and so far looks good.

Long:

• First: there is (almost) no configuration parameter that can cause such a problem intentionally, so it is not a misconfiguration (I guess you are using FortiClient in Tunnel mode, not Web mode proxying where slowness is not a bug but a feature?)
• Check health params on the FGT while experiencing the problem - CPU load, memory consumption. 
• Check MTU inside the tunnel, as MTU misalignment may cause fragmentation/defrag deteriorating the connection (it is set automatically on FC connect).  
• Try different protocols inside the tunnel - FTP/HTTP to see may be it is some specific protocol, like SMB is known to become very slow on VPNs, as opposed to FTP/HTTP.
• Look in logs for anything outstanding 
• run a sniffer in the FGT to look for retransmits, damaged packets, low MSS for TCP packets.  
• Run ping inside the tunnel and compare to the ping over the clear text to the FGTs WAN IP to see if this slowness shows in the very basic ICMP traffic as well.