![]() We already had a VPN server set up on a Windows Server 2012 machine. There were a couple of non-IT users who occasionally remoted into their machine to perform some tasks most of the time because they were at a conference. ![]() The IT department had a lot more experience using VPN due to the nature of the work. The first task was to get a large number of users who never used VPN, or remote desktop technology, connected on their home computers. After about a week of troubleshooting, most of the office had set up VPN connections on their home computers. A server that previously had two to three connections at the most now had user counts of 35 to 40 on a regular basis. We found out quickly that we were ill-prepared for such a user base and that our PPTP tunnel was not very secure. Here's a list of the most challenging problems we encountered after the rollout - and how you can avoid them in the future. We found that some operating systems did not support the PPTP tunnel that our server was using. Several users had MacBooks that ran on a MacOS Sierra operating system. Solution: Use the L2TP/IPsec tunnel instead of PPTP After some research, we found that Apple had dropped support for the PPTP tunnel on the newer versions of their Operating Systems due to security concerns. While researching the MacOS problem, we requested the help of the security team that handles our uplink. The L2TP/IPsec tunnel is fairly simple to set up and it is far more secure." They gave us an emphatic suggestion "Stop using PPTP as soon as possible. We found many articles that discussed the issues with PPTP. It is technically possible to create a PPTP tunnel connection using MacOS by utilizing some third party software. We decided that the better solution would be to switch to L2TP/IPsec as the security team suggested. The Windows Server running the VPN connection was getting overwhelmed by the amount of bandwidth created by all the users. Because the default configuration for a PPTP connection is to tunnel all their traffic through the VPN, everything they accessed was being transported by the server. ![]() This means that if a user was watching a Youtube video, streaming Netflix, or doing just about anything that required a lot of bandwidth, all that traffic had to flow from the VPN server to their machine. Needless to say, when you have 35 users on the same machine this can generate a very large output. At times it was impossible to get anything accomplished because there was too much lag to communicate through Remote Desktop. Our initial response to the network saturation was to instruct our users to stop streaming videos and other tasks that required a lot of bandwidth while connected to our VPN. We sent an email highlighting all the different activities that required a lot of bandwidth - video streaming, viewing high res photos and downloading large files.
0 Comments
Leave a Reply. |