New to Fortinet equipment. Fortigate 50e with 2xFortiAP-223c. Remote desktop latency.

[jshiveley]

I work for a mental health/drug and alcohol counseling agency. Our EHR(electronic health record) is cloud based and we access it through a Remote Desktop connection. We just recently installed Fortigate 50e and FortiAP-223c to replace some residential Linksys wireless routers the guy before me left. The funny thing is we never experienced any issue accessing our EHR with the old Linksys equipment. As soon as we installed the Fortigate 50e I'm getting complaints of typing latency and disconnects.

After working with a Fortinet engineer, I believe we have the disconnects issue resolved by setting the RDP session ttl to 7200. However, we're still experiencing the typing latency at all the locations that have the new Fortigate 50e's installed. They are all on firmware version 5.4.1 build 1064. The FortiAP-223c's are on version 5.4.1 build 0339. Majority of our offices have a 50x5 cable connection. At most each location will have 7-10 users at a time. We have web filtering and antivirus policies setup. Web filtering is only setup to block access to xxx/adult rated sites. We have the antivirus security policy enabled on every protocol except MAPI, detect viruses set to block, treat windows executables in emails as viruses enabled, use fortisandbox database enabled and mobile malware protection enabled. I have removed the antivirus policy and the issue persists.

Does anyone have any ideas?

Thanks,

-Joel

[FortiOSman]

Sounds like the latency could be coming from the web filtering and AV scanning. 

Can you try creating a new rule, specifically for the RDP traffic and not have it use any UTM features? That would mimic your previous Linksys setup. You can mitigate not having those turned on by defining the destination IP for the RDP rule. Don't forget to re-add the session TTL. 

I've ran into latency issues in the past and it was because my AV scanner was using using proxy based inspection instead of flow based. Once I changed the mode to flow based my latency went back to normal. Since 5.2 flow based has been the recommended mode, as per the Fortinet engineer I was working with. 

Let me know what happens.

-FortiOSman

Up, Up, and Away!

[jshiveley]

Thanks for the reply FortiOSman. The RDP rule isn't using any UTM features and after I looked again it wasn't using any to begin with. I have defined a destination IP address for the rule, but still experiencing the latency and getting staff complaints. Any other ideas?

-Joel

[FortiOSman]

Hmm.

Does this happen on both wired and wireless? You had said you also replaced APs, maybe those are the culprit. 

Have you tried a trace route to the RDP server? Are there any anomalies? 

Another thing to check is the CLI for that rule. I have seen issues in the past where the GUI was reporting features not being enabled, but the CLI showed them as on. 

#config firewall policy

#edit <ID> 

#show

[jshiveley]

It happens on both wired and wireless clients. At first we thought it was a wireless issue, but we wired a few end users and they still have the issue. We recently had a Linksys EA6400 wireless router that ran the entire office without any issues. We raplaced that with a Fortigate 50e and 2 FortiAP-223cs for this office (some offices have 3 access points). I talk them into purchasing $20k worth of Fortinet equipment for every office and it's making me look like a tool so far.

The tracert fails after the 16th hop. Goes to request timed out and never completes. I can't say if this is the same result as the old equipment or not. We never had an issue before so I never had a need to do a tracert. Looking at the policy through CLI shows everything correct as it is in the GUI. 

[FortiOSman]

The tracert failing is fine; I would be more concerned if any hops had a large latency increase. 

Is the RDP traffic the only thing that you are having latency trouble with? Is your firewall CPU/Memory usage fine?

Have you tried a flow trace? http://kb.fortinet.com/kb/documentLink.do?externalID=FD33882

Do you still have your old equipment? Can you plug in the Linksys and confirm the issues go away? --If not, can you if you plug directly to your cable box to test?

If the issues go away when you bypass the Fortigate, I would get their support back on the phone and have them further diagnose. 

[jshiveley]

I have a ticket started and have sent the engieer our config file and a packet capture log so far. The trace route does have one hop that showed 1700ms to 2500ms on the pings. Running the trace route again the same hop 2 out of 3 pings timed out.

I'm still trying to learn the Fortios CLI, but one of the engineers I was working with used that flow trace for a vpn issue we were having so I am a little bit familiar with it. Just not to the point yet to try it myself. I do still have our old equipment, but hopefully pulling it back out to test will be a last resort. 

I'll keep you posted as to what we're able to figure out, if anything.

[jshiveley]

I just wanted to update the thread with some good news. After working with a Fortinet engineer, he determined the issue to be with the FortiGuard filtering. By default it uses port 53 which DNS also uses. Some (My ISP=Time Warner Cable) ISPs will throttle connections if they see a lot of traffic coming to/from that port. I guess they see it as an attack on DNS. After we changed the FortiGuard default filtering port to 8888 everything is back to normal on our RDP sessions. Thanks again FortiOSman for your time.

-Joel

[FortiOSman]

Great. Glad you were able to get it sorted out!