Remote Desktop Connection session is dropping very often

[#1]

Greetings all, I have a client that has FG-60 with the latest OS in their head office, and also FG-50 are sitting in their remote sites. The head office and remote sites are connected via private network, however when the remote sites are trying to have RDC into the PCs in the head office over those FGs, they' re experiencing session drop off. It happens like 10 - 20 times during the business hours. When they take the FG-50 out of the network and runs RDC directly from the PC, it runs smoothly without any problems. Do you guys aware if there' s a session time out with FG-50 when it' s in idle stage? I was guessing that caused by the faulty power supply that doesn' t give enough power to the FG that gives intermittent connectivity. Apart from that, I really have no idea why this is happening... Any suggestions guys? Thanks before. Cheers Jascha

[#2]

No, it has nothing to do with how much power is going into the box. Your problem is most likely a session timeout. The default on the Fortigate is 300 seconds (5 minutes) which is quite short for an RDP connection. I usually set port 3389 for a timeout for something between 28,800 (8 hours) and 43,200 (12 hours). That way I get no calls on the problem. Session timeout is a common problem. I have also seen this to be a problem with Outlook connecting to Exchange over a VPN.

[#3]

Hi Trombone, Thanks for your reply, however I' m quite new with Fortigate. Could you tell me where can I set the timeout on specific ports? I' m using Firmware 2.50 Build 299. Thanks again. Cheers

[#4]

I found something in the docs that looks like it. In CLI it seems to be at config system session_ttl config port edit 1494 set timeout 28800 end end Since I am new to Fortigate I really don' t know if this is correct. I will try, but you try at your own risk :-) port 1494 is citrix winframe which is my current problem regarding session hangups. @ Trombone: Is this the setting you refer to? Thanks, Stefan

[#5]

I tested the commands listed above. My problem of freezing of the citrix client persists unfortunately. If this was the setting Trombone meant, it doesn' t help with my situation. I will do further tests.

[#6]

Hi Stefan, Here' s what I got from the knowledge center: V 2.80 config system session_ttl set default 300 config port edit 8787 set timeout 3600 next end end I haven' t checked this up yet, because it' s only available for firmware version 2.80, while I' m using FG-50 (they can only use firmware version 2.50, and I' m using the latest firmware for FG-50 V2.50 build 321). I don' t think the above command list is appropriate to be used for V.2.50. Anyone knows? Thank you.

[#7]

Hi Jascha, your settings seem pretty similar to mine, only that I don' t set a default. Don' t know what the " next" is for, though... And I of course use the citrix port, not 8787. Anyhow the settings didn' t work for me. I think I found the problem, at least the situation got better now, but still needs further testing. I changed the Keylife in the IPSEC phase2 Advanced Parameters to 7100 on one side and 7200 on the other side. The freezes seem to be less frequent now. I am waiting for a report of times when the freezes happen and will review the logs for keyexchanges that match the freezes. I will post the results.

[#8]

If this helps I have an IPSEC VPN between a sonicwall and a Fortigate wifi 60 My keylife is set to 172800 on both ipsec keylifes and my remote clients use Citrix. 7200 is only 2 hours - maybe set it to last about 12 hours. a longer keylife between negotiations at least allows it not to kill a connection in the middle of a session. Also, try lightenng up on on some of the encryption if it seems to have trouble establishing a connection.

[#9]

Hi guys, I' ve tested the command listing myself for fimrware 2.50, and I think it works. I set the timeout up to 3600 seconds and tested the session without any dropouts for an hour or more. The default session timeout is set to 300 seconds, thus if it' s idling for 5 minutes, it will drop the session. I' ve also tested this by using the default, and yes it dropped after 5 - 10 minutes. For firmware V.2.50 please use this syntax: Fortigate-50# set system session_ttl port <specify_port> timeout <specify_time> <Enter> Since I' m not using VPN (e.g. IPSEC or anything else) to connect to the other sites I don' t have any problems connecting to the other sites. As these sites are connected with each other through a special core Tunnel LAN over the DSL infrastructure made by our ISP. The ISP is the one who maintains the private network termination and its security. Thus we simply put the workstation/router/firewall' s public IP address on the same subnet without any VPN connection required. If it' s just a normal internet connection which requiring VPN service, I think you guys need to have a look at - yes this might be right - increasing the keylife for IPSEC. Thanks for all your inputs guys. Cheers

[#10]

I am relatively new to VPN, so perhaps I am not right here... I always supposed the phase2 keyexchange should be working transparently without killing sessions? Is it normal that during keyexchanges no traffic flows (which would be the explanation why the sessions die)? And what security implications does it have to increase keylife from 30 minutes to 12 hours or so? In my understanding there will be much more traffic to analyse and bruteforce the keys of. Is there a way to tell how much traffic should be allowed before changing keys for security reasons? Thanks for all the help!