Home / server / Questions / 878276
In Process
Vesper
Asked: 2017-10-13 22:53:02 +0800 CST

Fine tune a Remote Desktop Gateway server to tolerate packet losses

  • 772

I have a Windows 2012R2 server acting as remote desktop gateway for a number of RDSH servers inside the perimeter, and have a firewall between it and the Internet allowing access from outside to that gateway. Our users report problems that their RDS connections via that gateway occasionally break with errors related to RDG server drop, while RDG only reports "client disconnected" with statistics. Investigation has discovered that the firewall is overloaded at times, dropping packets from its input queue. Sadly, firewall is an appliance that is not easily replaced (replacement will take some 6 months, and the problem is of course to be solved yesterday), so I have to make my RDG work in a network that's congested by default.

Are there any settings that I can apply to RDG so that it won't drop UDP connections for an extended period of time, or maybe not advertise UDP connection at all, just to make sure that eventually TCP would push a L3 packet through the firewall and the connection won't break?

windows-server-2012-r2

1 Answers

  1. RDP is pretty lighweigh, I recommand other thing for your router as it hit 100% CPU time. Rdp User found it drop, but Iam sure it affect you on other services

    Following our comment I would suggest;

    Try to save on CPU cycle for your appliance.

    Normal port forward is not usally something that will put a high load on your appliance, as such please check around;

    • VPN use a lot of CPU cycle, as such;

    -- If you have Site to Site VPN tunnel up, please validate when the %CPU is high if that follow high VPN usage.

    -- If your appliance accept VPN user please validate how much are connected when the symptom arise, to see if you can limit such.

    -- Please validate if your appliance exclude in the DPI the VPN usage.

    • DPI, it use a lot of CPU cycle too, as such; (if you cant disable it)

    -- Validate your current WAN usage when the symptom appear, as a too high WAN link versus a small appliance with DPI will get it CPU maxed.

    -- If you do inter zone routing in the firewall, validate if DPI is run against those packets as well.

    Most of all check if you can run a debug when the symptom appear, as some appliance allow to see what cause the high cpu usage, like a linux top command.

    If you can't save on CPU cycle, I suggest;

    • Rent a router for the time you buy a new's one, some vendor allow that, like we do at our job, we just do the bill minus the rent later on.

    • or get a new IP at your ISP and use a small soho router for the forward, to completly remove that traffic from your main router.

    • 1