Security also includes the packets flowing across the network. In this video, you’ll learn about different VPN technologies, features of SD-WANs, and SASE solutions.
If you’ve ever been away from the office, but you needed to connect back to resources that are on your corporate network, but you needed a secure form of communication, you probably used a VPN or Virtual Private Network. A VPN encrypts all of your private data and sends it across a public network, such as the internet. This is often managed with a VPN concentrator. This is a purpose-built device that is designed to be the endpoint for everyone to connect to using this encrypted link.
On today’s networks we often will use next generation firewalls or a similar type of firewall to provide this VPN endpoint capability. Although it’s very common to find a VPN concentrator integrated into a hardware-based firewall or standalone concentrator appliance, you might also see VPN concentrators built as software solutions. And, very often, there is software that’s installed on the client workstation that is able to connect and authenticate to the VPN concentrator. Often, the software is even integrated into the operating system itself.
Here’s a common description of an encrypted connection using a virtual private network. In this example, we’re using a remote user that is outside of the corporate network. There’s a VPN concentrator that provides that conversion between the outside and the inside network. And, finally, we have the resources available on our corporate network.
The red section of this diagram is the encrypted tunnel itself. All of the traffic sent from the remote user to the VPN concentrator is all encrypted. If someone was able to capture this traffic traversing the internet, they would have no idea what was contained within those packets.
The VPN concentrator is responsible for decrypting all of this traffic and sending it in the clear into our corporate network. But what’s really happening inside of those packets that’s being sent back and forth? And how are we able to encrypt all of this data, yet still find a way for that data to make it across the network to the VPN concentrator? For example, we’d like to send some data into our corporate network. And, of course, over the network we’ll need to include an IP header that describes where this traffic is going.
Obviously, this IP header and data is not encrypted. There’s no security based on that communication. So we need to encrypt that data before sending it over the network. But obviously, if we’re encrypting this original IP header and data, we will need additional headers included with this to be able to point this information to the correct concentrator IP address.
We’ll accomplish this by encrypting our original information and embedding it, or tunneling it, within other headers. In this example, we’re encrypting the IP header and the data. To be able to tell where this encrypted data begins and ends, we will wrap around this an IPsec header and an IPsec trailer. And, of course, to be able to point all of this information to the appropriate IPsec concentrator, we’ll add a new IP header that provides that information to the routers along the way.
So in this example, we have now encrypted all of our private information. But we’ve wrapped around it the details necessary to send it across this IPsec tunnel. Once this packet is received by the IPsec concentrator on the other side, the concentrator removes the IP header, the IPsec header, the IPsec trailer, and then decrypts the IP header and data and sends the traffic on its way.
If you’re using a laptop, a desktop, or some other type of mobile device to be able to communicate across this VPN, you’re probably using an SSL or TLS VPN. This, of course, stands for Secure Sockets Layer or Transport Layer Security. This is the same protocol that we use to encrypt web server traffic so it runs over TCP port 443. And because we’re using the same port numbers that are commonly used for encrypted web communication, it very easily passes through the existing firewalls that we have on our networks.
An SSL VPN is commonly used for remote access communication from a single device. This is usually a VPN client that’s installed onto the workstation or is included as part of the operating system. To log into the VPN we would use the login credentials that we might normally use. We’re not forced into using certain types of credentials, such as digital certificates or shared passwords. But we can use those for an SSL VPN if we’d like. And there are even VPN clients that can run inside of a browser itself. So you wouldn’t even need to install additional software to be able to take advantage of VPN connectivity.
An SSL VPN is the type of VPN that you’d commonly use to communicate from a laptop over a public network like the internet to a VPN concentrator. That VPN concentrator would then decrypt the traffic and send it into our corporate network. Some SSL VPNs can be configured as always on. So when you start up your laptop, it is automatically connecting to the VPN concentrator. And any time you send any traffic from the laptop, it will always be secured using this SSL VPN.
Some organizations will build an encrypted tunnel between remote locations so everyone at a remote site will be able to communicate back to the corporate network over an encrypted channel that is provided automatically through firewalls acting as VPN concentrators.
In this scenario, it’s the firewalls that act as the VPN endpoints. So you don’t need any additional software or configurations on any of the devices on either side. You simply send traffic normally to the remote site. And, in between, the encryption process occurs automatically. You’ll often hear of SSL VPNs referred to as remote access VPNs, and these types of IPsec VPNs as site-to-site VPNs.
A relatively new form of wide area networks is called an SD-WAN. That stands for software defined networking in a wide area network. This was specifically designed to address some of the challenges we have with connecting to cloud-based applications. Over the years, things have changed from very large data centers within our own buildings to data centers that are in the cloud and can be located anywhere.
SD-WAN is designed to address some of these changes. Instead of having all of our users communicating to a set of servers within our building in our data center, we now have wide area networks that are designed to be flexible enough to allow application access from wherever we happen to be.
Here is the traditional design of our data centers. There would commonly be a large data center that contained all of our applications– web services, email, databases, and everything else. And we would have wide area network connections from all of our remote sites that allowed us to communicate back and forth that centralized data center.
But, obviously, the cloud has changed where we access those applications. So instead of having that centralized data center, we’ve moved our databases, our web servers, and our email into the cloud, and in some cases into multiple clouds with different services in each one of those clouds.
This certainly creates a challenge from a network engineering perspective, because all of these remote sites would therefore need to communicate to the data center but then from the data center out to the cloud. This obviously creates a network inefficiency because it takes multiple hops to get access to those centralized applications.
With SD-WAN we are, of course, still able to communicate to the data center. But now we can build out dynamic networks that are able to communicate to our web-based applications. Now individuals at a remote site that are communicating to databases or web-based applications can use the appropriate network connection over the SD-WAN.
So now we have more efficient ways to communicate to these web-based applications. But how can we integrate our secure VPN technologies which normally would only communicate to a single concentrator, and somehow expand those to be able to use these cloud-based infrastructures? Well, we do that by using Secure Access Service Edge or SASE. You can think of SASE as the next generation of VPN that allows us much more efficient ways to communicate to these web-based applications.
Along with our applications, all of our security technologies are now also going to be based in the cloud. And they’re generally going to be next to the services that we’re planning to use. We would then install SASE clients on all of our devices so that we’re able to communicate into the cloud securely and protect all of the data traversing our networks. So if you are a corporate office, a home user, or a mobile user, you would simply use that SASE connection into the cloud. And from there we’re able to securely jump to any cloud-based service that we might need.
Deciding on a secure communication method and the implementation of that technology can be challenging. And some organizations will use one or more of these together. They might use remote access VPNs or SSL VPNs for end user communication, and continue to use IPsec site-to-site VPNs for all of their remote locations. To provide a seamless connection for cloud based applications, an organization might implement SD-WAN. And to provide security for all of this communication over the SD-WAN, an organization can implement SASE.
There are, of course, advantages and disadvantages to all of these different communication technologies, but depending on the implementation of the application and the connectivity that’s being used, a security administrator might choose to use one or more of these to protect network traffic.