Here at Cantarus, our multi-purpose KalaniCloud hosting is used for a variety of different hosting requirements, from websites and backup data to email and Windows Remote Desktop Services (RDS), formerly Terminal Services (TS). This article focuses on the latter, and specifically on providing such Remote Desktop Protocol (RDP) services via a site-to-site VPN tunnel using SonicWALL firewalls at each end because we experienced some issues with intermittent, recurring dropped connections.
A web search showed that (a) we were far from the only ones and (b) no single website had provided a comprehensive solution.
RDP is a streaming protocol and is very sensitive to interruption in the connection. A momentary drop in connection can cause the RDS client to disconnect, freezing the screen for the end user until the RDS client automatically attempts to reconnect. This reconnection process can take anywhere between a few tens of seconds and a minute or more and is very disruptive for the end user.
The sections below describe how to achieve the best RDS performance over SonicWALL site-to-site VPN tunnels. Many of the settings will also apply to connections using the software SonicWALL Global VPN Client (GVPNC), particularly PMTU, since this can vary between different client Internet connections.
In our experience, the single most significant cause of dropped RDS connections over VPN tunnels is TCP timeout settings that are too low.
When creating a firewall rule in SonicWALL firewalls, the TCP Connection Inactivity Timeout is set to 15 minutes by default. Although one might consider that an active RDS session should not be regarded as inactive by SonicWALL, in practice, this value can indeed cause the RDS connections to be dropped. Based on experience, we'd recommend this is changed to at least 120 minutes.
Changing the TCP Connection Inactivity Timeout value is straightforward; simply edit the appropriate firewall rule, navigate to the User & TCP/UDP (or Advanced for pre-version 7 firmware) tab and change the setting there. However, it is essential to do this only for access rules covering just RDS traffic as otherwise, the timeout for all traffic is changed which can result in excessive numbers of inactive connections accumulating on the firewall and consuming resources.
A common issue with implementing the above VPN tunnel firewall rules is that SonicWALL, by default, automatically create the access rules associated with the VPN tunnels, and these auto-generated rules cover all traffic types between the endpoints. To address this, we recommend making your own custom firewall rules and preventing the automatic creation of rules (which is more secure as not all services must be opened) which is achieved as follows:
Route-based VPN tunnels are our preference when working with SonicWALL firewalls at both ends of a VPN tunnel. This is because they are more flexible in that the endpoint subnets don't need to be specified (custom routes are created instead), meaning clashes between endpoint subnets can be avoided.
As RDS is a streaming protocol, packet fragmentation should be avoided. SonicWALL firewalls do provide fragmented packet handling functionality, and this is controlled via the VPN > Advanced page.
We'd recommend checking both the Enabled Fragmented Packet Handling and Ignore DF (Don't Fragment) Bit. This may seem contrary to the above, which states that RDS traffic shouldn't be fragmented; the ideal approach is to ensure that packet fragmentation does not occur by using correct PMTU settings (see below), but if it does, then these settings prevent the packets being dropped which would likely cause issues with the RDS session. Further, failing to fragment packets can interfere with Path MTU Discovery traffic.
Whichever approach you choose, ensure it is identical on the SonicWALL firewalls at both ends of the VPN tunnel and be aware that it is a global setting applying to all VPN tunnels terminating at each appliance.
As described above, fragmentation of the RDP streaming protocol is undesirable and should be avoided. The most common cause of such fragmentation is incorrect Maximum Transmission Unit (MTU) values for the traffic's path.
The PMTU (Path Maximum Transmission Unit) is the largest packet that can traverse a given connection (path) without fragmentation. The most common MTU value for UK Internet connections is 1,500 bytes, and this should be set appropriately in the WAN interface configuration on the SonicWALL firewalls.
Path Maximum Transmission Unit Discovery (PMTUD) is a technique in computer networking for determining the maximum transmission unit (MTU) size on the network path between two Internet Protocol (IP) hosts, usually intending to avoid IP fragmentation. More information can be found here. Note that SonicWALL firewalls do not honour or pass to the LAN MTU Path Discovery messages as they are unauthenticated and can be used as a denial of service attack.
The current version of the SonicWALL firmware provides a Path MTU Discovery tool under the Device > Diagnostics > PMTU Discovery menu (Or the Investigate > System Diagnostics > Select PMTU Discovery from the Diagnostic Tool menu - page for pre-version 7 firmware). Enter an IP or hostname in the Address field, and select the relevant interface from the dropdown – click the GO button, and the firewall will automatically calculate your PMTU.
However, if you need an alternative and straightforward manual method of determining the PMTU, you can do the same calculation via ping from the command line. A ping command of the format –
(Windows) ping <target FQDN or IP> -f -l <send buffer size in bytes>
(Mac) ping <target FQDN or IP> -D -s <send buffer size in bytes>
(Linux) ping <target FQDN or IP> -M do -s <send buffer size in bytes>
can be used with the last parameter being varied until the ping response is no longer fragmented, allowing for the fact that the IP + ICMP header size is itself 28 bytes, so a value of 1472 would be returned by this test on a line with an MTU of 1,500.
When deploying a site-to-site VPN tunnel between two SonicWALL (or other) devices, the PMTU is reduced by a further 56 bytes due to the cryptographic overhead associated with an IPSEC VPN tunnel. Therefore, when protocols sensitive to fragmentation - for example, RDP for RDS - are traversing a VPN tunnel over Internet connections with MTUs of 1,500, the connection endpoints (e.g. the RDS server and client machine) must have their MTU set to no more than 1416 bytes (1,500 - 28 - 56). This is not necessary when using Windows Point-to-Point Tunnelling Protocol (PPTP) VPN since Windows automatically adjusts the MTU to account for the cryptographic overhead.
One easy way of making this MTU change is configuring the Windows network adaptor on both ends, as per Option 2 in this article.
There is an excellent technical article for addressing the same issue on Cisco devices here.
Limitations on Internet connection bandwidth (often referred to as 'contention') is a common cause of RDS performance problems, both in terms of poor responsiveness and drop-outs.
Organisations experiencing bandwidth problems often assume that they simply need more bandwidth. However, SonicWALL firewalls provide advanced bandwidth management capabilities to ensure that traffic sensitive to latency and connection speed is prioritised over other traffic. This makes much better use of existing bandwidth and avoids potentially substantial costs associated with upgrading an Internet connection.
We recommend that RDS traffic is given the highest (real-time) bandwidth management priority and that an appropriate amount of bandwidth is reserved for it. This can be done at a firewall rule level or via SonicWALL's App Rules feature for correctly-licensed appliances. It is incredible how much of a difference this simple change can make to RDS usability!
Licensed SonicWALL firewalls provide a comprehensive set of on-appliance security services, including Gateway Anti-Virus (GAV), Anti-Spyware (AS) and Intrusion Prevention Service (IPS). These services can scan specific traffic types (e.g. SMTP, FTP, etc.) or the whole TCP stream for threats.
While they are very efficient in terms of scanning speed, they do introduce some additional latency (typically at least 1ms), and we've also seen them cause dropped RDS connections when applied to the whole TCP stream.
Assuming that the endpoints are sufficiently trusted, it's worth considering disabling the firewall's scanning services (at least AS and IPS) to obtain the best RDS performance and connection reliability. We would recommend both the RDS server and connecting clients be secured with suitable anti-virus software using the latest definition database.
A combination of optimum TCP timeout, packet fragmentation, PMTU, bandwidth management, and security services settings can ensure outstanding performance and reliability of RDS over SonicWALL site-to-site VPN tunnels.
Our experience tells us that providing the same user experience over GVPNC is more complicated, so we exclusively use SonicWALL SSL VPN services via NetExtender or Mobile Connect for remote/mobile users.
