You have many options when accessing devices remotely. In this video, you’ll learn about VPN options, transferring files, managing devices remotely, and more.
<< Previous Video: Performance Metrics Next: Policies and Best Practices >>
One of the most popular remote access protocols is IPsec or Internet Protocol Security. IPsec provides security of information at OSI Layer 3, and it gives you an option for authentication and encryption for every packet you send across the network. Because IPsec includes the ability to encrypt and sign each packet, it is effectively providing you both confidentiality and integrity, which prevents anybody from replaying this traffic through the network in order to gain unauthorized access.
IPsec is very popular. And you can find implementations of IPsec in many vendor’s products. That means you could have one vendor on one side of the WAN and another vendor on the other side of the WAN, and they’ll still be able to communicate with each other using IPsec. You may also see the two core protocols that are used in IPsec. One of these is AH or the Authentication Header. And the other one is the Encapsulation Security Payload or ESP.
The common implementation of IPsec is through a site-to-site VPN, where you might have one corporate network on one side of the network, and perhaps a remote site on the other side of the network. You want to be able to communicate between both of these locations, which already have an internet connection. But you don’t want to use the public internet for private company information. Instead, we’ll build a private tunnel between both of these sites so that encrypted information can be sent across the internet. This is commonly done by having a VPN appliance installed on both ends of this connection. Usually this is something that’s integrated into an existing platform. For example, many firewalls will provide IPsec endpoint support within the firewall itself.
At the corporate network, traffic is sent back and forth to the VPN appliance in the clear. There’s no encryption associated with that. But when the VPN appliance does receive that data, it’s going to send it through the internet as an encrypted tunnel. And on the other side, the VPN appliance will decrypt that information and make it available to the other site.
Another VPN type that’s commonly used for end user VPN access is an SSL VPN. An SSL of course, is the Secure Sockets Layer. Instead of using IPsec to provide the encryption, we’re using SSL, which commonly runs over TCP port 443. Since SSL is such a common protocol, most firewalls allow this traffic to pass without any additional configurations.
SSL VPN clients are often built into your operating system. Their thin clients and usually don’t require a lot of resources on your computer. SSL VPN’s can also use a simple username and password to authenticate users. There’s no requirement that you set up shared passwords or digital certificates like you might see in IPsec. And you’ll find support for SSL VPN’s are in many different operating systems and there are many implementations of SSL VPN’s that can run from inside of a browser.
This will be a common configuration to use, an SSL VPN. You may see this also referred to as a client-to-site VPN or a remote access VPN. We would need software to be installed on the remote user’s workstation to be able to use this SSL VPN. And this device will be connecting to a VPN concentrator. This is often a firewall that’s installed somewhere at the remote location.
The user will start their software and authenticate to the VPN concentrator. And from that point forward, everything between the remote user and the VPN concentrator is all using an encrypted channel. Once it hits the VPN concentrator, the data is decrypted and provided in the clear over to the corporate network. When information is sent back to the user from the corporate network, it hits the VPN concentrator. It’s again encrypted across the internet and then decrypted down at the remote user’s workstation.
One of the challenges with SSL or TLS is that it is a TCP-based protocol. That means you’ll get the benefits of TCP, such as reordering of packets if they come in out of order. And of course if any data is lost along the way, TCP will retransmit that data. But a number of the applications we use these days don’t require any type of packet reordering or retransmission. For example, streaming technologies and voice over IP don’t require the use of TCP. In those situations, you may want to use a DTLS VPN, which is a datagram transport layer security.
This is using UDP packets instead of TCP. DTLS would be a good choice for these real-time streaming or voice over IP protocols. If any data is lost along the way, it’s too late to back up and recover that information. Another common remote access technology is remote desktop. It’s one where we can sit at our desk and be able to connect to and see the desktop of another device across the network.
One common protocol for remote desktop is RDP. That stands for Microsoft’s Remote Desktop Protocol. And not only are there clients for Microsoft Windows, there are also RDP clients for Mac OS, Linux, and other operating systems as well. VNC, or Virtual Network Computing, is another remote desktop technology that uses RFB or remote framebuffer protocol.
There are VNC clients for many different operating systems. And many of those clients are free and open source. This remote desktop functionality is very useful if you need to troubleshoot and maintain devices across the network. But we’ve also seen this remote desktop technology used by scammers who will connect to your system, look into your computer, tell you that there is a problem and then ask for your credit card number. But of course, no problem really does exist on your system. But their remote desktop efforts make it appear as if there are problems with your computer.
Another popular remote access technology is SSH, or Secure Shell. This allows us to have a console screen where we can work at the command line. Very commonly, we would use SSH to connect to routers, switches, firewalls, and other devices where we need this terminal session. This is something you would use to encrypt communication over the network. SSH replaces the technology we use with Telnet, which of course provided a very similar terminal screen. But all of the communication with Telnet is in the clear and all of the communication with secure shell is encrypted.
With many devices, you don’t need to use SSH and manage the device at the command line. Instead, you can use your browser and a web-based management console. By using HTTPS, we can ensure that there is an encrypted connection between our browser and this remote device. And we can use all of the management features that have been configured for this browser-based communication. In some cases, you may still need access to the command line to be able to run functions that aren’t available in the web-based front end. But the web-based front end provides you with an easy way to gain access without having to go through the process of connecting through a command line.
Sometimes you don’t need to manage a device from the front end, you simply need to transfer a file. And for those file transfers, you have a number of options available. One of the very early methods of transferring files was through FTP, or the File Transfer Protocol. This was designed for file transfers and it requires that you authenticate with a username and password to gain access. This also provides file system functionality so you can delete files, rename files, add folders, and much more. But FTP is all in the clear. There’s no built in encryption associated with the FTP protocol.
FTPS is a more secure form of FTP, because it’s using FTP over SSL. You may see this also referred to as FTP-SSL. This File Transfer Protocol Secure is a very good way to transfer data without sending information in the clear. There are other ways of transferring data over an encrypted channel using different protocols. This one is FTPS. The other is SFTP. So make sure you know that there is a difference between those two protocols. FTPS is FTP over SSL. SFTP is FTP using SSH for the encryption.
So the same protocol that we’re using to encrypt our terminal sessions we can use to also encrypt our file transfer sessions. SFTP is also full featured. We have access to the file system so we can add and rename files and directories as needed. And another method of transferring files is so basic that we call it TFTP for trivial file transfer protocol. This is a very simple method of transferring files from one place to the other. It is very simply a file transfer mechanism and nothing more. You don’t need any special authentication to be able to transfer a file. And we commonly see TFTP used when we’re turning on something like a voice over IP phone that needs a configuration. The phone will transfer the initial configuration file over TFTP, so you don’t need any special logins or authentications to get that phone up and running.
On many of our switches and routers and other infrastructure devices, we can access those over a terminal or from a web-based front end using the built in IP addresses that are on the network. But what if the network is suddenly not available, but you still need access to that infrastructure device. In those situations, you may want to take advantage of out-of-band management. Out-of-band management as a way to manage these devices without using the external network. Usually this is implemented as a USB interface or a serial interface like the one you have here, where you can connect directly to the device to manage it.
Of course if this device is in another building or another state or another country, you may want to connect a modem to this serial interface so that you can dial in and connect to this device over phone lines. And some organizations may take advantage of a console router or a communication server. You may have a remote site that has a router, a firewall, and multiple switches, and you may connect all of those devices through out-of-band management to the COM server. You would then dial into the COM server, and from there you would specify which of these devices you’d like to communicate with over the out-of-band management interface.