The network shown in Figures 24-1 and 24-2 illustrates this case study. The company in this network has a corporate office, a handful of regional sites, a few dozen branch offices, and hundreds of remote access users that connect via the Internet. The following sections will discuss the necessary requirements for these components.
Figure 24-1. Company Internet Connections
Figure 24-2. Company Campus Network
The detailed IP addressing scheme is not displayed in the two figures; this will be revealed throughout the case study. Also, I've shown redundant components only as they relate to the VPN functions of the VPN design; other redundant components, such as redundant stateful firewalls, redundant application and file services, and others, are not shown, but are implied. Likewise, I'll focus primarily on the VPN configuration and management of the VPN devices, even though other configurations will be necessary, especially on the perimeter routers.
The following sections will discuss the different components contained within the figures.
Of the entire network, the corporate office has the more complex design. The corporate office's VPN design can be broken into these main VPN areas:
The following subsections will discuss each of these areas in more depth.
In this network, two types of authentication devices are employed for VPN services:
Certificates are used for device authentication, given the large number of devices and the need for scalability and flexibility. A flat CA design is used, with a CA and two RAs. If you recall from Chapter 2, "VPN Technologies," a CA provides all certificate services, whereas an RA can be used to validate existing certificates; it provides a backup for the CA. The CA is connected to the DMZ2 segment at the corporate office's network, and two RAs exist at two different regional offices' DMZ segments to provide redundancy. The RA shown in Figure 24-1 at the regional office appears at only two of the regional offices. The CA product is Microsoft's certificate services running on a Windows 2003 server.
Because the CA plays a fundamental and critical role in the VPN implementation, it should be backed up (or imaged) periodically and religiously. Even though RAs provide this function, RAs cannot issue new certificates nor revoke existing certificates. If you don't follow this simple tip and the CA fails, get ready to spend a lot of time rebuilding your CA and issuing new certificates to all of your devices!
There are two AAA RADIUS servers in the corporate office's campus server farm, which is connected to the campus's network backbone. These servers hold the XAUTH user profiles for:
There are two AAA RADIUS servers for redundancy, ensuring that the users can authenticate via XAUTH and connect to the campus network. Users are issued token cards to generate one-time passwords. The actual authentication for these accounts will be done by a back-end token card server not shown in Figure 24-2.
At the perimeter of the campus network are two Cisco 3845 routers, connected to the Internet, with AIM-VPN/HP II-Plus modules installed. They're running 12.3(14)T. Their main function is to terminate VPN site-to-site sessions from the regional offices and provide routing functions between the campus and regional offices. DMVPN is used to provide for both of these functions. The routing protocol used across the network is OSPF. Because redundancy and throughput is critical, two routers are used with a dual-hub/dual-DMVPN design, which I discussed in Chapter 17, "Router Site-to-Site Connections."
Additional security features should be enabled on these routers, such as ACLs for filtering, CBAC for stateful filtering, disabling unnecessary services, QoS, and others; however, the configuration of these is beyond the scope of this book.
On the DMZ2 segment are two 3030 concentrators running version 4.7. They are responsible for terminating remote access sessions from software (Internet users) and hardware clients (branch offices). They use a VPN-on-a-stick approach, where only their public interfaces are used. This design is used when you want to take the protected traffic, verify and decrypt it, and forward it to a firewall before it reaches the campus network, but you don't want to use two interfaces on your firewall to handle these functions. Because the private interface isn't used on the concentrators, you'll need to perform some extra steps on the concentrators to ensure that protected and unprotected traffic can enter and leave the public interface filter. Redundancy is a concern, so VCA will be used.
Using a VPN-on-a-stick approach is not very common. In most scenarios, you would want to use both the private and public interfaces on the concentrators. In this situation, both sets of interfaces would connect to two different interfaces on your perimeter firewall. In Figure 24-2, this would require the firewall to have five interfaces. In my fictitious company, I'm assuming that it is impossible to add an additional interface to the perimeter firewall, and therefore I need to use a VPN-on-a-stick design.
All users' accounts for remote access are defined on the AAA RADIUS servers in the server farm of the corporate office campus network. The token card servers, which are used by both AAA servers, are located on the campus server farm with the two campus AAA servers. The DMZ2 concentrators will assign internal addresses from 10.7.0.0/17 to the remote access clients that are operating in client mode. Here are the addresses that will be assigned to the three remote access groups:
- 3030A: 10.7.0.110.7.7.254
- 3030B: 10.7.8.110.7.15.254
- 3030A: 10.7.16.110.7.23.254
- 3030B: 10.7.24.110.7.31.254
- 3030A: 10.7.32.110.7.39.254
- 3030B: 10.7.40.110.7.47.254
The 10.7.128.0/17 network (the other half of this A-class subnet) is used for the internal wireless users at the campus backbone. As you'll see in the "Campus Concentrators" section shortly, all remote access users have an internal address of 10.7.0.0/16 assigned to them, which makes it easier to assign internal filtering policies to this traffic, if necessary.
Even though Figure 24-2 shows one perimeter firewall, like a PIX or ASA security appliance, at the corporate office network, this network actually uses two firewalls for redundancy. However, because of space constraints in Figure 24-2, only one firewall is shown. The primary functions of the firewalls are:
For example, the internal campus network devices are using private addresses, so the perimeter firewall will need to perform address translation for these devices. The perimeter firewalls also will need to be configured to allow tunneled traffic to the concentrators from the Internet and clear-text traffic to the concentrators from the inside network with filtering statements. Likewise, traffic to the DMZ2 NTP and CA servers needs to be allowed.
Two concentrators, running 4.7, are used inside the campus to secure the wireless LANs that are scattered throughout the campus network. The basic design has all wireless traffic from the access points placed into a VLAN (or VLANs) that the two internal concentrators (3030C and 3030D) are connected to with their public interfaces. Their private interfaces are connected to the campus network. AAA servers in the campus server farm reference the token card servers at the same location for XAUTH password functions. There are currently 1,000 users that connect to the campus backbone via wireless, which is why the 3030 was chosen as a product. The IP addresses used on NICs in the wireless part of the network are from 10.6.0.0/8. Two concentrators are used to provide for redundancy. The wireless users will use Cisco VPN Client software to protect traffic across the wireless network. The auto-initiation feature will be used to make the software client as transparent as possible on their users' desktops. The concentrators will assign addresses from 10.7.128.0/ 17 as internal addresses to the wireless clients. Here are the address assignments for the three wireless groups:
- 3030C: 10.7.128.110.7.135.254
- 3030D: 10.7.136.110.7.143.254
- 3030C: 10.7.144.110.7.151.254
- 3030D: 10.7.152.110.7.159.254
- 3030C: 10.7.160.110.7.167.254
- 3030D: 10.7.168.110.7.175.254
There are eight regional offices in this network, even though Figure 24-1 illustrates just the perimeter of one regional office. Each regional office is very similar, with a perimeter router and firewall. The perimeter routers are 3825s with AIM-VPN/EP II-Plus modules, running IOS 12.3(14)T. The regional perimeter routers use DMVPN to connect to the two DMVPN hubs (perimeter routers) at the corporate office. All traffic meant for the corporate office is sent via this connection. DMVPN was chosen for this design because there is a lot of inter-regional office traffic and I want to minimize the amount of VPN configurations needed on the perimeter routers. Using DMVPN allows a regional office router to set up an IPsec tunnel directly to another regional office router without any additional configuration on my part. Because some of the traffic at the regional offices goes to noncompany sites, a stateful firewall and other services are used to provide additional protection. At two of the regional sites an RA is placed on the DMZ segment to provide for certificate services redundancy of the CA at the corporate office's DMZ2 segment.
There are a few dozen branch offices. Each of these offices has 430 employees. Because I want to simplify my management for these offices, I've decided to use a 3002 hardware client running 4.7 and disable split tunneling. This requires all branch office traffic to go to the DMZ2 concentrators at the corporate site, allowing me to centralize my security functions for the branch offices. Remote network management might be implemented in the future; therefore, I'll use network extension mode for the 3002 hardware client connections.
I easily could have enabled split tunneling for the branch offices, but then I'd have had to put a small-end PIX (501 or 506E) at these locations to provide for additional security services. If bandwidth at the central office was a concern, I definitely would consider the latter approach, because enabling split tunneling would reduce the amount of bandwidth I'd need at the central office. Plus, this company might have a policy that required all Internet traffic to be examined before leaving the network. In this situation, I would disable split tunneling for all remote access (software and hardware) users and have their traffic examined at the corporate site by a URL filtering product such as WebSense or N2H2's Sentian. Because of the amount of traffic at the regional sites, I would place a separate filtering server at each of these locations and allow them to reach the Internet directly without having to go to the corporate site first.
Also, if bandwidth were a concern, I would set up a bandwidth policy for the group of 3002s that would give them a reserved bandwidth value and an upper, policed value; whereas the remote access users would have a general policed bandwidth policy applied to them.
Remote Access Users
For salespeople who travel a lot and the many users who either telecommute or need to work part of the time at home, I've decided to use Cisco VPN Client software, version 4.6, as a solution on Windows 2000 and XP computers. For home users, if I'm concerned about management and maintenance, I might decide to put a hardware client at their location, such as a PIX 501 or a VPN 3002; however, if cost is more of a concern, using the software client is the best approach.
In the current network, there are about 800 users from the Internet that connect to the DMZ2 concentrators at the corporate office periodically, and this number is expected to almost double in the next couple of years, which is why 3030s were chosen for the solution. There are three basic groups of users: sales, administrators, and programmers. Inside the campus network, these people (the wired network) have the following addressing structures, respectively: 10.3.0.0/16, 10.4.0.0/16, 10.5.0.0/16.
Part I: VPNs
Overview of VPNs
PPTP and L2TP
Part II: Concentrators
Concentrator Product Information
Concentrator Remote Access Connections with IPsec
Concentrator Remote Access Connections with PPTP, L2TP, and WebVPN
Concentrator Site-to-Site Connections
Verifying and Troubleshooting Concentrator Connections
Part III: Clients
Cisco VPN Software Client
Windows Software Client
3002 Hardware Client
Part IV: IOS Routers
Router Product Information
Router ISAKMP/IKE Phase 1 Connectivity
Router Site-to-Site Connections
Router Remote Access Connections
Troubleshooting Router Connections
Part V: PIX Firewalls
PIX and ASA Product Information
PIX and ASA Site-to-Site Connections
PIX and ASA Remote Access Connections
Troubleshooting PIX and ASA Connections
Part VI: Case Study