Topology Considerations

There are several different design options concerning the topology of IPsec connections. You should consider split tunneling for all topologies. This section first outlines split tunneling and then walks through the topology choices and the main design considerations.

Split Tunneling

As discussed earlier in this chapter, IPsec has a notion of a security policy database (SPD). The SPD keeps track of which information should be encrypted and which should not. Typically, an SPD contains a policy that encrypts information between entities of an organization, be they users or sites. Any traffic destined for a network outside the organization (typically the Internet at large) is sent unencrypted. This policy decision is called split tunneling and is shown in Figure 10-10.

Figure 10-10. Split Tunneling

Here you can see that the traffic originating from all sites to the Internet is being sent directly from those locations.

As an alternative, some designs elect to disallow split tunneling from certain IPsec peer types or from all peers. Figure 10-11 shows a mixed deployment in which all remote user VPN traffic is sent through the head end, but remote site traffic is split tunneled.

Figure 10-11. Some Split Tunneling

The two main factors in choosing whether to implement split tunneling are performance and security.

Performance

From a performance standpoint, split tunneling is easily the highest-performing solution with the lowest bandwidth requirements. Traffic destined for the Internet at large is able to travel directly to its intended destination. Without split tunneling, traffic has a much more circuitous route to take, as shown here:

1.	A mobile worker, for example, encrypts all communications to the central site and the Internet at large and sends it to the central site.
2.	The central site decrypts the traffic and sends Internet-bound traffic back out to the Internet through the central site's Internet edge and security solution.
3.	Internet hosts respond to the central site, which then reencrypts the traffic and sends it back across the Internet to the IPsec client that made the original request.

The end result is that the central site sees traffic twice that it wouldn't even see once if split tunneling were enabled. This slows response time for the client, increases the crypto load on the remote router or PC, and increases bandwidth requirements on the central site.

Security

It is the security side of split tunneling that causes many designers to deal with the performance impact. If you refer to Figure 10-10, you see that essentially there is a unique Internet edge at every remote IPsec peer. While connected to the Internet, these remote peers are susceptible to attack, just like any other device on the Internet, unless you secure them appropriately. If such a device is compromised, the attacker can use the compromised system as a conduit to attack the central site over the IPsec VPN. Without split tunneling, the system would not be reachable by any nonauthenticated IPsec device. Dealing with the security issues to enable split tunneling has a capital cost factor and a management factor. Each type of connection has its own unique requirements. The next two sections outline these requirements for mobile workers and remote sites.

Mobile Workers

To ensure that a remote worker does not pose a security risk while connected to a VPN with split tunneling enabled, you must configure all reasonable security measures on the PC. This includes implementing local antivirus, patches, host hardening, and a personal firewall. For the central site to be assured that the device is in compliance, however, the central site must be assured that the firewall and other security controls are running and properly configured. Different remote user VPN providers have their own proprietary methods of making this happen.

It is also worth considering that the mobile worker might spend only a portion of connected time using a VPN connection at the central site. While at home on broadband, at a hotel, or in an airport, the user will be using Internet resources without the organization's VPN. As such, the cost factor for these security controls isn't very significant because you need these controls anyway to protect the device when it is connected to the Internet without the VPN. The decision to use split tunneling doesn't affect this.

Still, by disallowing split tunneling, you force all Internet-bound traffic to flow through a single security edge deployment while the VPN is active. At the central site, you might have a NIDS and content filtering set up, and you hopefully have better monitoring. For this reason, as well as the nontechnical comfort level it provides, many organizations block split tunneling when a remote user is connected.

As mentioned earlier, if you decide to block split tunneling, you still must make sure you have some security controls on your hosts for when they connect to the Internet without the VPN.

Remote Sites

The issues with remote sites and split tunneling are similar, except now you are dealing with more users, and the bandwidth impact on your central site grows. Because an IPsec gateway is required at these remote sites, however, adding basic security to the non-IPsec traffic is fairly easy. Many IPsec gateways support firewalling as well. A configuration that blocks all incoming connections to the remote site from the Internet, but that allows most remote connections from the central site, allows for a reasonably secure remote site. Without any identifiable targets at the remote site, it won't be a very attractive target to an attacker.

However, you still must contend with the management issues. Are you comfortable not reviewing the logs on your remote devices? If you have 1000 or more remotes, not reviewing logs might be the only option. In much smaller deployments, sending Syslog data from each remote is more realistic. Also, if URL filtering is a requirement, you either must ensure you have it installed at each remote site, or you must block split tunneling.

Split Tunneling Recommendations

In the final analysis, it is your security policy that drives you in a particular direction in terms of split tunneling. If you have a deployment option that satisfies the requirements of your security policy and allows for split tunneling, implementing split tunneling is certainly the more common-sense deployment from a networking standpoint. If you are unable to satisfy your requirements or simply are uncomfortable with the idea of having hundreds of dynamic access points with limited security in your organization (I can't say I blame you), opt for no split tunneling. Bandwidth is cheap these days, right?

Topology Choices

It is useful to consider the different topologies used in IPsec VPNs. IPsec VPNs can be deployed in one of four different designs:

• Hub and spoke
• Partial mesh
• Full mesh
• Distributed

Hub and Spoke

By far the most common, scalable, deployable, and cost-effective option, hub and spoke (Figure 10-12) should be your default topology.

Figure 10-12. Hub-and-Spoke IPsec

Hub and spoke has the following design characteristics:

• All traffic between spokes is sent through the hub. Spoke-to-spoke traffic is therefore assumed to be a fairly small percentage of overall traffic. A retailer would be an ideal organization for a hub-and-spoke network.
• The number of bidirectional IPsec tunnels is equal to the number of spokes.
• Routing can either be dynamic or static.
• Scalability is only limited by the number of head-end central-site IPsec gateways you deploy.

Partial Mesh

Partial mesh (Figure 10-13) is a slight variation on hub and spoke for which you identify links with high interspoke traffic and create IPsec tunnels between them. This allows the majority of the design to benefit from the scalability of hub and spoke while allowing the connectivity benefits that full mesh provides where needed.

Figure 10-13. Partial-Mesh IPsec

Here you can see that three spokes have formed a small meshed network, enabling direct communications. Assuming the number of meshed spokes is kept to a minimum, this design scales fairly well. Because of the more complicated connectivity, dynamic routing is recommended instead of static.

Full Mesh

Full mesh (Figure 10-14) becomes a required design only when each connection is truly a peer to other connections and traffic must flow equally to all spokes. A sample application might be IP telephony. If there are a large number of calls between sites, in addition to the rest of the data traffic, a full mesh can be appropriate.

Figure 10-14. Full-Mesh IPsec

Full mesh is clearly the least scalable, most expensive, and most difficult topology from a configuration standpoint. Dynamic routing and digital certificates should be considered requirements for any full-mesh IPsec network greater than approximately five peers. From a hardware standpoint, each site must have the same capabilities in its IPsec gateways. As the number of sites expands, the requirements on the routing protocol grow just like in any other fully meshed network.

Distributed

This design combines two or more separate hub-and-spoke networks by using a fully meshed network between hub locations. As shown in Figure 10-15, this design is typically used to connect distinct elements within an organization. These elements can be separated by geographic bounds or perhaps by business function.

Figure 10-15. Distributed IPsec

Dynamic routing is essential between the hub locations and is desirable in the spokes as well. Digital certificates should be considered a requirement in an IPsec deployment of this magnitude.