Topic Tag: 601 Ch 4

You must be logged in to view this content.

You must be logged in to view this content.

You must be logged in to view this content.

You must be logged in to view this content.

Site-to-Site VPNs

A site-to-site VPN includes two VPN servers that act as gateways for two networks separated geographically. For example, an organization can have two locations. One is its headquarters, and the other is a remote office. It can use two VPN servers to act as gateways to connect the two locations together, as shown in Figure 4.8.

Figure 4.8: Site-to-site VPN

The site-to-site model’s benefit is that it connects both networks without requiring additional steps on the part of the user. Users in the remote office can connect to servers in the headquarters location as easily as if the servers were in the remote office. Connecting to the remote server might be slower than connecting to a local server, but otherwise, it’s transparent to end users.

In contrast, in a traditional remote access VPN (also called a host-to-gateway model), the end user makes the direct connection to the VPN server and is very much aware of the process.

Always-On VPN

Some VPNs are always-on VPNs. They can be used with both site-to-site VPNs and direct access VPNs. When used with a site-to-site VPN, the two VPN gateways maintain the VPN connection. In contrast, some site-to-site VPNs use an on-demand connection. The VPN connection is established when it’s needed, such as when a user connects to a remote system.

Several vendors have always-on VPNs for direct access VPNs. They attempt to create a VPN connection as soon as the user’s device connects to the Internet. For a home user, this might be right after the user turns on a desktop PC or laptop computer.

When configured on mobile devices, such as cell phones, the device will connect to the always-on VPN anytime the device connects to an Internet connection. For example, if a user visits a coffee shop with free Internet access and the user connects to the network, the device will automatically connect to the always-on VPN.

L2TP as a Tunneling Protocol

Layer 2 Tunneling Protocol (L2TP) is a tunneling protocol that is also used for VPNs. The most recent version is L2TPv3. However, none of the L2TP versions provide any encryption, so it is not used by itself for VPN traffic. Instead, data is encrypted with another protocol, such as IPsec, and then passed to L2TP for transport over the VPN.

HTML5 VPN Portal

Some network devices include the ability to configure an HTML5 VPN portal. An HTML5 VPN allows users to connect to the VPN using their web browser, making it rather simple for the users. It uses TLS to encrypt the session, but it can be very resource-intensive. In general, organizations use it to give one or two users access to limited resources. As an example, if a consultant managed a Voice over IP (VoIP) private branch exchange (PBX), an organization could use an HTML5 VPN to give this consultant access to the PBX. However, the other employees would use a traditional VPN for remote access.

Figure 4.7 shows an example of how users can connect to internal networks from remote locations. You may see this referenced as a remote access VPN or a direct access VPN. The VPN client first connects to the Internet using a broadband connection to an Internet Service Provider (ISP). After connecting to the Internet, the VPN client can then initiate the VPN connection.

Figure 4.7: Connecting to a VPN server

The VPN server is in the screened subnet and reachable through a public IP address. This makes it accessible from any other host on the Internet. A VPN server needs to authenticate clients, and a common method is to use an internal Remote Authentication Dial-in User Service (RADIUS) server. When a user logs on, the VPN server sends the user’s credentials to the RADIUS server.

While the RADIUS server might have a database of users and passwords, it’s more common for it to pass the credentials on to another server to validate them. For example, the RADIUS server can pass the credentials on to a Lightweight Directory Access Protocol (LDAP) server during the authentication process. In a Microsoft domain, the LDAP server is a domain controller.

IPsec as a Tunneling Protocol

Chapter 3 introduces Internet Protocol security (IPsec) as a method of encrypting data in transit. IPsec supports both Tunnel mode and Transport mode.

Tunnel mode encrypts the entire IP packet, including both the payload and the packet headers, and VPNs commonly use Tunnel mode. Packet headers include IP addresses and MAC addresses. A benefit of using Tunnel mode is that the IP addressing used within the internal network is encrypted and not visible to anyone who intercepts the traffic. If attackers do intercept the traffic, they can see the source IP address from the client and the destination address to the VPN server, but the internal IP address information remains hidden.

Transport mode only encrypts the payload and is commonly used in private networks, but not with VPNs. If traffic is transmitted and used only within a private network, there isn’t any need to hide the IP addresses by encrypting them.

IPsec provides security in two ways:

• Authentication. IPsec includes an Authentication Header (AH) to allow each of the IPsec conversation hosts to authenticate with each other before exchanging data. AH provides authentication and integrity. AH uses protocol number 51.
• Encryption. IPsec includes Encapsulating Security Payload (ESP) to encrypt the data and provide confidentiality. ESP includes AH so it provides confidentiality, authentication, and integrity. ESP uses protocol number 50.

The term protocol number might look like a typo, but it isn’t. AH and ESP are identified with protocol numbers, not port numbers. Chapter 3 discusses routers and firewalls. You may remember from Chapter 3 that a basic packet-filtering firewall can filter packets based on IP addresses, ports, and some protocols, such as Internet Control Message Protocol (ICMP) and IPsec. Packet filters use the protocol numbers to identify AH and ESP traffic.

IPsec uses Internet Key Exchange (IKE) over port 500 to authenticate clients in the IPsec conversation. IKE creates security associations (SAs) for the VPN and uses these to set up a secure channel between the client and the VPN server.

SSL/TLS as a Tunneling Protocol

Some tunneling protocols use Transport Layer Security (TLS) to secure the VPN channel. As an example, Secure Socket Tunneling Protocol (SSTP) encrypts VPN traffic using TLS over port 443. Using port 443 provides a lot of flexibility for many administrators and rarely requires opening additional firewall ports. It is a useful alternative when the VPN tunnel must go through a device using NAT, and IPsec is not feasible. OpenVPN and OpenConnect are two open source applications that can use TLS to create a secure channel.

While this can also use Secure Sockets Layer (SSL), SSL has known weaknesses, and TLS is the designated replacement. Even though SSL is rarely, if ever, used today, you’ll still see it referenced. For example, SSTP indicates it uses SSL, but it actually uses TLS.

Split Tunnel Versus Full Tunnel

Imagine that Lisa connects to a company VPN server using IPsec from her home computer. The VPN is using ESP, so all traffic in the tunnel is encrypted. Now, Lisa wants to do an Internet search on saxophones. Will her computer connect directly to the Internet for her search? Or will her computer make a connection through the VPN server first? It depends on the VPN’s configuration.

In a split tunnel, a VPN administrator determines what traffic should use the encrypted tunnel. For example, it’s possible to configure the tunnel to encrypt only the traffic going to private IP addresses used within the private network. If Lisa did an Internet search with the VPN server configured in a split tunnel configuration, her Internet search traffic would not go through the encrypted tunnel. Instead, her search would go directly to Internet sites via her ISP.

In a full tunnel, all traffic goes through the encrypted tunnel while the user is connected to the VPN. If Lisa was connected to the VPN and then tried to connect to a public website, the traffic would first go through the encrypted tunnel and then out to the public website from within the private network. If the private network routed Internet traffic through a unified threat management (UTM) device, Lisa’s traffic would go through the organization’s UTM device. The website would send webpages back to the UTM device, and the VPN server would encrypt it and send it back to Lisa via the encrypted tunnel.

Chapter 3 discusses UTM devices. A UTM device can perform URL filtering, malware inspection, and content inspection of all traffic sent through it. This is one reason why an organization may choose to use a full tunnel for users connected to a VPN server. A disadvantage is that it can be slow. Not only is the Internet traffic taking an indirect route through the VPN server, but it’s also being encrypted and decrypted a couple of times.

You must be logged in to view this content.

You must be logged in to view this content.

You must be logged in to view this content.

You must be logged in to view this content.