VPNs: Choosing a Solution

Case Study Configuration

Now that I've defined the policies for this network, I'll explain the configuration for the following VPN-enabled devices:

I've broken up the configuration explanation into the following sections:

Perimeter Router Configuration

A dual-DMVPN design with dual hubs is used to interconnect the corporate office and regional sites via IPsec site-to-site sessions. Certificates are used for device authentication. The following sections will discuss the configuration of each device.

Basic VPN Configurations on the Routers

All of the routers will require certain commands that will be similar in their configuration. These commands will perform the following:

This section will discuss the configurations that are common to all the perimeter routers. Example 24-1 shows this base configuration:

Example 24-1. Base Perimeter Router Configuration

perim(config)# access-list 100 remark insert other ACLs here perim(config)# access-list 100 permit udp any any eq 500 perim(config)# access-list 100 permit udp any any eq 4500 perim(config)# access-list 100 permit esp any any perim(config)# access-list 100 permit tcp any host 192.1.2.2 eq 80 perim(config)# access-list 100 permit tcp any host 192.1.2.3 eq 123 perim(config)# access-list 100 permit udp any host 192.1.2.3 eq 123 perim(config)# access-list 100 remark insert other ACLs here perim(config)# interface fastethernet0/0 perim(config-if)# ip access-group 100 in perim(config-if)# exit perim(config)# ntp server 192.1.2.3 key 99 source fastethernet0/1 perim(config)# ntp authenticate perim(config)# ntp authentication-key 99 md5 55ab8971F perim(config)# ntp trusted-key 99 perim(config)# ntp update-calendar perim(config)# access-list 1 permit 192.1.2.3 0.0.0.0 perim(config)# ntp access-group peer 1 perim(config)# crypto isakmp policy 1 perim(config-isakmp)# authentication rsa-sig perim(config-isakmp)# hash sha perim(config-isakmp)# encryption aes 256 perim(config-isakmp)# group 5 perim(config-isakmp)# lifetime 3600 perim(config-isakmp)# exit perim(config)# crypto isakmp keepalive 15 3 perim(config)# ip domain-name company.com perim(config)# crypto key generate rsa general-keys label certkeys The name for the keys will be: perim.company.com Choose the size of the key modulus in the range of 360 to 2048 for your General Purpose Keys. Choosing a key modulus greater than 512 may take a few minutes. How many bits in the modulus [512]: 2048 % Generating 2048 bit RSA keys ...[OK] perim(config)# crypto pki trustpoint caserver perim(ca-trustpoint)# enrollment url http://192.1.2.2/certsrv/mscep/mscep.dll perim(ca-trustpoint)# enrollment mode ra perim(ca-trustpoint)# enrollment retry period 5 perim(ca-trustpoint)# enrollment retry count 5 perim(ca-trustpoint)# rsakeypair certkeys perim(ca-trustpoint)# exit perim(config)# crypto ca authenticate caserver Certificate has the following attributes: Fingerprint MD5: CE9956AA C02D15DF A2309A9C E059BD47 Fingerprint SHA1: 475A5DBA 0283DB43 305E9CF7 A208C8B8 E894C379 % Do you accept this certificate? [yes/no]: yes Trustpoint CA certificate accepted. perim(config)# crypto ca enroll caserver % Start certificate enrollment .. % Create a challenge password. You will need to verbally provide this password to the CA Administrator in order to revoke your certificate. For security reasons your password will not be saved in the configuration. Please make a note of it. Password: cisco123abc789xyz Re-enter password: cisco123abc789xyz % The fully-qualified domain name in the certificate will be: perim.company.com % The subject name in the certificate will be: perim.company.com % Include the router serial number in the subject name? [yes/no]: no % Include an IP address in the subject name? [no]: no Request certificate from CA? [yes/no]: yes % Certificate request sent to Certificate Authority % The certificate request fingerprint will be displayed. % The 'show crypto pki certificate' command will also show the fingerprint. 05:32:29: CRYPTO_PKI: Certificate Request Fingerprint MD5: F9A3574C 09BAC68D 491D0FDA 1EBCE0BC 05:32:29: CRYPTO_PKI: Certificate Request Fingerprint SHA1: 898BDC0B 69F74320 8EECF1FF FD86503F 3DC366BB 05:32:34: %PKI-6-CERTRET: Certificate received from Certificate Authority perim(config)# crypto ipsec transform-set trans1 esp-aes-256 esp-sha-hmac perim(cfg-crypto-trans)# mode transport perim(cfg-crypto-trans)# exit perim(config)# crypto ipsec profile dmvpnprofile perim(ipsec-profile)# set transform-set trans1 perim(ipsec-profile)# exit perim(config# copy running-config startup-config

The first part of Example 24-1 sets up the ACL used to filter traffic from the Internet. Notice that I've included only the commands necessary to allow IPsec traffic, including access to the CA and NTP servers; you'll still need to add ACL statements before or after this to allow or deny other types of traffic (see my book entitled Cisco Router Firewall Security with Cisco Press for more information about this). This ACL is applied inbound on the Internet interface.

Note

Because certificates are being used, you'll need to allow TCP port 80 traffic to the CA on the corporate perimeter routers and the same at the two regional sites that have the RAs; if you forget to do this, Internet devices will not be able to obtain their own or other devices' certificates. Also, at the two regional sites with the RAs, you'll need to change the ACL statement with the 192.1.2.2 address to the address that the RA is using; and for the regional offices that don't have RAs, you'll omit this ACL statement from their configuration.

In 12.3(8)T, you don't need an ACL statement to allow the tunneled traffic: the Crypto Access Check on Clear-Text Packets feature removes the double-ACL processing. However, in IOS versions earlier than this, your perimeter ACL must allow the clear-text traffic between the various sites.

Below the ACL configuration is a set of commands to use NTP to synchronize the time with the NTP server on the DMZ2 segment. The use of NTP is important because certificates are being used. Again, if you have multiple NTP servers, this configuration for a regional office router might be slightly different based on the NTP server the router is using.

Tip

You can create an NTP server easily by buying a GPS and attaching it to a Linux/Unix or Windows 2003 server. You can get a reasonable GPS for under $200 US. And instead of putting it on a separate standalone server, you might want to consider even putting this on the CA server itself. I would not rely on using an external NTP server because you would be opening yourself up to the possibility of a denial-of-service (DoS) attack, where an attacker pretends to be a valid time source and sends you a time that is either before or after a certificate's validation date, invalidating that particular certificate and thus causing authentication to fail.

For the regional office routers, you do not need the ACL statements for the NTP server, because this device is at the corporate office (these are the two ACL statements with the 192.1.2.3 addresses). However, for redundancy, you might want to have other NTP servers in your design, some of which are located at various regional offices.

Below the NTP configuration is an ISAKMP policy that's mirrored on all perimeter routers. Notice that it uses certificates (rsa-sig) for device authentication. Also, I've changed the lifetime of the management connection to one hour to match that of the data SAs. After one hour, both sets of connections are torn down and rebuilt. Following this, the crypto isakmp keepalive command enables DPD.

Because certificates are to be used, the router needs a name and domain name. Once these are configured, the crypto key generate rsa command generates the RSA public/private keys. I used a key label with the keys because the router might have another key pair created and being used for other purposes already; in this example, I want to use 2048-bit RSA keys for the certificates, no matter whatever any existing key pair is using.

Tip

You might want to create exportable keys (and exportable certificates) to ease a recovery process if a perimeter router fails. However, it isn't a requirement in my situation. In my fictitious company, if a perimeter router failed, I'd have to generate new keys and acquire a new identity certificate for the replacement router.

The name of the CA is "caserver" and it has an IP address of 192.1.2.2. Because RAs are being used, I configured the mode as RA. I've also referenced the RSA key pair label to use "certkeys," when creating the identity certificate. The crypto ca authenticate command obtains the root certificate and the crypto ca enroll command obtains the router's identity certificate.

I've only defined one transform set, "trans1," for the DMVPN routers, using ESP with AES 256 as an encryption algorithm and SHA as a hashing function. Notice that because I'm using DMVPN, which uses GRE tunnels, the ESP mode is transport mode (point-to-point tunnel). Last, since DMVPN doesn't use crypto maps, I've created an IPsec profile that references the transform set I've created. This will be referenced on the GRE tunnel interfaces when I set up DMVPN in the "Corporate Office Router Configuration" and "Regional Office Router Configuration" sections.

Note

Even though I'm using Fast Ethernet interfaces for the Internet connections, this is only an example; based on bandwidth and available connection options, this might be an ATM interface, an HSSI interface, or an IMA interface.

 

Corporate Office Router Configurations

Examples 24-2 and 24-3 show the two corporate office routers' configurations. Because DMVPN is being used, I've set up a GRE tunnel interface on both routers and have ensured that the bandwidth metric is the same. This allows the regional routers to load balance traffic on a destination-by-destination basis to the corporate networks, if they chose. The subnet for this DMVPN network is 10.0.0.0/24. OSPF is the routing protocol used in this network and I want to ensure that in this DMVPN network, corpA becomes the designated router (DR). NHRP is set up to implement the dynamic registration and discovery process for DMVPN. Both the NHRP network and GRE tunnel need unique IDs in each of their domainsI used the same number to simplify the configuration. Notice that the tunnel mode for GRE is multipoint, which allows the spoke router to accept multiple tunnel connections on the same logical interface. Last, I specify the IPsec profile, "dmvpnprofile," to use to protect traffic on the GRE tunnel. At the bottom of the configuration, I've set up the interfaces and the OSPF configuration. For OSPF, the GRE tunnel connections and local sites are in the same area, area 0the remote sites' networks are configured in separate areas because of their size.

Example 24-2. Dual-DMVPN Design with Dual Hubs: Corporate Router's, corpA's Configuration

corpA(config)# interface tunnel0 corpA(config-if)# description Connection to regional routers corpA(config-if)# bandwidth 1000 corpA(config-if)# ip address 10.0.0.1 255.255.255.0 corpA(config-if)# ip mtu 1436 corpA(config-if)# tunnel path-mtu-discovery corpA(config-if)# delay 1000 corpA(config-if)# ip ospf network broadcast corpA(config-if)# ip ospf priority 2 corpA(config-if)# ip nhrp authentication cisco123 corpA(config-if)# ip nhrp map multicast dynamic corpA(config-if)# ip nhrp network-id 100000 corpA(config-if)# ip nhrp holdtime 600 corpA(config-if)# tunnel source fastethernet0/0 corpA(config-if)# tunnel mode gre multipoint corpA(config-if)# tunnel key 100000 corpA(config-if)# tunnel protection ipsec profile dmvpnprofile corpA(config-if)# exit corpA(config)# interface fastthernet0/0 corpA(config-if)# description Internet Connection corpA(config-if)# ip address 192.1.1.1 255.255.255.0 corpA(config-if)# exit corpA(config)# interface fastethernet0/1 corpA(config-if)# description Local LAN corpA(config-if)# ip address 10.0.2.1 255.255.255.0 corpA(config-if)# exit corpA(config)# router ospf 1 corpA(config-router)# network 10.0.0.0 0.0.0.255 area 0 corpA(config-router)# network 10.0.2.0.0 0.0.0.255 area 0 corpA(config-router)# exit

 

Example 24-3. Dual-DMVPN Design with Dual Hubs: Corporate Router's, corpB's, Configuration

corpB(config)# interface tunnel0 corpB(config-if)# description Connection to regional routers corpB(config-if)# bandwidth 1000 corpB(config-if)# ip address 10.0.1.1 255.255.255.0 corpB(config-if)# ip mtu 1436 corpB(config-if)# tunnel path-mtu-discovery corpB(config-if)# delay 1000 corpB(config-if)# ip ospf network broadcast corpB(config-if)# ip ospf priority 2 corpB(config-if)# ip nhrp authentication cisco123 corpB(config-if)# ip nhrp map multicast dynamic corpB(config-if)# ip nhrp network-id 100001 corpB(config-if)# ip nhrp holdtime 600 corpB(config-if)# tunnel source fastethernet0/0 corpB(config-if)# tunnel mode gre multipoint corpB(config-if)# tunnel key 100001 corpB(config-if)# tunnel protection ipsec profile dmvpnprofile corpB(config-if)# exit corpB(config)# interface fastethernet0/0 corpB(config-if)# description Internet Connection corpB(config-if)# ip address 192.1.1.2 255.255.255.0 corpB(config-if)# exit corpB(config)# interface Ethernet1 corpB(config-if)# description Local LAN corpB(config-if)# ip address 10.0.2.2 255.255.255.0 corpB(config-if)# exit corpB(config)# router ospf 1 corpB(config-router)# network 10.0.1.0 0.0.0.255 area 1 corpB(config-router)# network 10.0.2.0 0.0.0.255 area 0 corpB(config-router)# exit

Example 24-3 shows corpB's configuration. Its configuration is almost identical to corpA's shown in Example 24-2, except for these three things on its tunnel interface:

Other than these three things, the configuration of the corpB router is similar to that of corpA.

Regional Office Router Configuration

Example 24-4 shows the configuration of the regional routers. Notice that there are two GRE tunnel interfaces, both of which are configured for multipoint mode (tunnel mode gre multipoint). Each tunnel interface has its own unique subnet (10.0.0.0/24 and 10.0.1.0/24), NHRP ID, NHS server (corpA for tunnel0 versus corpB for tunnel1), and its own GRE tunnel ID. For the OSPF configuration, the two tunnel subnets are in area 0 and the local LAN segment is in area 100 + the region number. Using this design, each regional office is its own area, and any routing problems that occur at a regional office are contained, assuming that route summarization has been configured on the regional perimeter routers, which are area border routers (ABRs).

Example 24-4. Dual-DMVPN Design with Dual Hubs: Spoke Configuration

regionX(config)# interface tunnel0 region(config-if)# description Connection to corpA regionX(config-if)# bandwidth 1000 regionX(config-if)# ip address 10.0.0. 255.255.255.0 regionX(config-if)# ip mtu 1436 regionX(config-if)# delay 1000 regionX(config-if)# ip ospf network broadcast regionX(config-if)# ip ospf priority 0 regionX(config-if)# ip nhrp authentication cisco123 regionX(config-if)# ip nhrp map multicast 192.1.1.1 regionX(config-if)# ip nhrp map 10.0.0.1 192.1.1.1 regionX(config-if)# ip nhrp nhs 10.0.0.1 regionX(config-if)# ip nhrp network-id 100000 regionX(config-if)# ip nhrp holdtime 300 regionX(config-if)# tunnel source fastethernet0/0 regionX(config-if)# tunnel destination 192.1.1.1 regionX(config-if)# tunnel mode gre multipoint regionX(config-if)# tunnel key 100000 regionX(config-if)# tunnel protection ipsec profile dmvpnprofile regionX(config-if)# exit regionX(config)# interface tunnel1 regionX(config-if)# description Connection to corpB regionX(config-if)# bandwidth 2000 regionX(config-if)# ip address 10.0.1. 255.255.255.0 regionX(config-if)# ip mtu 1436 regionX(config-if)# tunnel path-mtu-discovery regionX(config-if)# delay 1000 regionX(config-if)# ip ospf network broadcast regionX(config-if)# ip ospf priority 0 regionX(config-if)# ip nhrp authentication cisco123 regionX(config-if)# ip nhrp map multicast 192.1.1.2 regionX(config-if)# ip nhrp map 10.0.1.1 192.1.1.2 regionX(config-if)# ip nhrp nhs 10.0.1.1 regionX(config-if)# ip nhrp network-id 100001 regionX(config-if)# ip nhrp holdtime 300 regionX(config-if)# tunnel source fastethernet0/0 regionX(config-if)# tunnel destination 192.1.1.2 regionX(config-if)# tunnel mode gre multipoint regionX(config-if)# tunnel key 100001 regionX(config-if)# tunnel protection ipsec profile dmvpnprofile regionX(config-if)# exit regionX(config)# interface FastEthernet0/0 regionX(config-if)# description Connection to Internet regionX(config-if)# ip address 192.1.x.1 255.255.255.0 regionX(config-if)# exit regionX(config)# interface FastEthernet0/1 regionX(config-if)# description Local LAN regionX(config-if)# ip address 10.10x.1.1 255.255.255.0 regionX(config-if)# exit regionX(config)# router ospf 1 regionX(config-router)# network 10.0.0.0 0.0.0.255 area 0 regionX(config-router)# network 10.10x.1.0 0.0.0.255 area X+100 regionX(config-router)# exit

Tip

In the configuration in Example 24-4, the bandwidth metric for the two GRE tunnel interfaces is different: tunnel0 uses 1000 and tunnel1 uses 2000. Based on this, the regional office will prefer the corpA router. However, you probably don't want all of your routers using the same corporate router; so on half of them, switch the bandwidth metrics on the two tunnel interfaces. By doing so, half your regional office routers will use corpA and the other half corpB. Optionally, you can set the metrics the same, which will then cause a regional router to use per-destination load balancing to the two corporate office routers; however, the downside of this is that a misconfiguration on your part could lead to a routing loop when spokes bring up connections to other spokes.

Note

If you recall from Chapter 17, "Router Site-to-Site Connections," the spoke routers will need two public IP addresses if they will be setting up spoke-to-spoke connections, where the tunnel source address for each interface will need to reference a different public IP address.

 

Internet Remote Access Configuration

In this next section I'll discuss how to set up the Easy VPN Servers and Remotes to provide a secure remote access solution using the Internet to connect the software and hardware clients to the corporate network. I've broken this part into three sections:

DMZ2 Concentrators

The configuration of the two DMZ2 concentrators is mostly the same, with the exception of the IP addressing information. Therefore, I'll discuss the configuration of one of the concentrators, 3030A. Part of the configuration will require the use of the CLI, but most of it will involve the GUI.

DMZ2 CLI Quick Configuration

First, boot up the 3030A and log in to its console using admin and admin as the username and password. When performing quick configuration, accept all the defaults. Because the private interface is not being used, also accept the defaults for it (0.0.0.0 for the address and 255.255.255.255 for the subnet mask). When you see the screen where it asks you to modify the IP address of either the public or private interface, save the changes, and exit (enter h to take you to the main menu). I'll bypass quick configuration and do everything from the main menus of the CLI.

DMZ2 IP Addressing

To assign the IP address to the public interface and allow HTTPS management access, perform the following from the concentrator's CLI:

Step 1.

Enter 1, Configuration.

 

Step 2.

Enter 2, Interface Configuration.

 

Step 3.

Enter 2, Configure Ethernet #2 (Public).

 

Step 4.

Enter 1, Interface Setting (Disable, DHCP or Static IP).

 

Step 5.

Enter 3, Enable using Static IP Addressing.

 

Step 6.

Enter 192.1.2.10.

 

Step 7.

Enter 255.255.255.0.

 

Step 8.

Enter 10, Set Interface WebVPN Parameters.

 

Step 9.

Enter 1, Enable/Disable HTTP and HTTPS Management.

 

Step 10.

Enter 1, Enable HTTP and HTTPS Management.

 

Step 11.

Enter h to return to the main menu.

 

Step 12.

Enter 1, Configuration.

 

Step 13.

Enter 1, Interface Configuration.

 

Step 14.

Enter 1, Configure Ethernet #1 (Private).

 

Step 15.

Enter 1, Interface Setting (Disable, DHCP, or Static IP).

 

Step 16.

Enter 1, Disable.

 

Step 17.

Enter h to return to the main menu.

 

Note

You must disable the private interface when implementing a VPN-on-a-stick, otherwise the public interface won't come up.

 

DMZ2 Default Route

Now you need to set up a default route so that from the campus network, you can reach and manage the 3030A using a web browser:

Step 1.

Enter 1, Configuration.

 

Step 2.

Enter 2, System Management.

 

Step 3.

Enter 3, IP Routing (static routes, OSPF, etc.).

 

Step 4.

Enter 2, Default Gateways.

 

Step 5.

Enter 1, Set Default Gateway.

 

Step 6.

Enter 192.1.2.254.

 

Step 7.

Enter h to return to the main menu.

 

Step 8.

Enter 4, Save changes to Config file.

 

Step 9.

Enter 6, Exit.

 

DMZ2 Access the Concentrator using a Web Browser

Now that you've put a very basic configuration on the 3030A, you should be able to access from the campus using a web browser, assuming you've configured your stateful firewall (192.1.2.254) correctly.

Step 1.

From your PC in the campus network, open a web browser and enter https://192.1.2.10/admin in the web browser's address bar.

 

Step 2.

Accept the certificate by clicking the OK button.

 

Step 3.

Enter admin and admin for the username and password and click the Login button.

 

Step 4.

Click the Click here to go to the Main Menu hyperlink to go to the main menu and skip quick configuration.

 

DMZ2 Basic Administration

Now that you've logged in to the 3030A, you're ready to use your web browser to complete the concentrator's configuration. This and the following sections discuss some common and necessary steps you would perform to complete this process:

Step 1.

Go to Configuration > System > General > Identification; in the System Name field, enter 3030A; click the Apply button.

 

Step 2.

Go to Configuration > System > Servers > NTP Servers > Hosts; click the Add button; enter 192.1.2.3; click the Add button.

 

Step 3.

Go to Configuration > System > Servers > DNS Servers; in the Domain field, enter the domain name (company.com); click the Apply button.

 

Step 4.

Go to Administration > Access Rights > Administrators; click the Modify button for the admin account; change the password for the account in both password fields; click the Apply button.

 

Step 5.

Go to Configuration > System > Address Management > Assignment; click the Use Address Pools check box; click the Apply button.

 

Note

At some point in time, don't forget to change the password for the concentrator's admin account!

 

DMZ2 Certificate Enrollment

Because certificates are used for device authentication, you'll need to install a root and identity certificate on the 3030A. I'll use SCEP for this process, where the CA is a Microsoft 2003 server with certificate services and SCEP installed:

Step 1.

Go to Administration > Certificate Management; click the Click here to install a CA certificate hyperlink; click the SCEP (Simple Certificate Enrollment Protocol) hyperlink.

 

Step 2.

In the URL field, enter the URL of the CA, like http://192.1.2.2/certsrv/mscep/mscep.dll for Microsoft's Certificate Authority; in the CA Descriptor field, enter the name of the CA (I used caserver, but you'll need to obtain this information from the CA administrator); click the Retrieve button.

 

Step 3.

From the Administration > Certificate Management screen, click the Click here to enroll with a Certificate Authority hyperlink; click the Enroll via SCEP at caserver hyperlink (the name of the CA appears in the hyperlink).

 

Step 4.

In the Common Name field, enter 3030A; in the Organizational Unit field, enter dmz2; in the Organization field, enter the company name; in the challenge password field, enter a password that will be used to revoke the certificate, if needed, like boson123456; change the Key Size to RSA 2048 bits; click the Enroll button (this may take some time, based on the large key size, so be patient).

 

Step 5.

Click the Go to Certificate Management hyperlink and examine your 3030A's identity certificate.

 

DMZ2 ISAKMP/IKE Configuration

Once you have both certificates, you'll need to set up ISAKMP/IKE:

Step 1.

Because some of the clients might have to go through an address translation device, you'll need to enable NAT-T: Go to Configuration > Tunneling and Security > IPsec > NAT Transparency; click the IPsec over NAT-T check box; click the Apply button.

 

Step 2.

Set up an ISAKMP/IKE Phase 1 proposal for certificates: Go to Configuration > Tunneling and Security > IPsec > IKE Proposals.

 

Step 3.

In the Active Proposals column, deactivate all possible proposals except for "CiscoVPNClient-AES128-SHA" by clicking the name of the proposal and then clicking the Deactivate button.

 

Step 4.

Click the CiscoVPNClient-AES128-SHA proposal name under the Active Proposals column and click the Copy button; enter CiscoVPNClient-AES128-SHA-RSA for the Proposal Name; for the Authentication Mode drop-down selector, choose RSA Digital Certificate (XAUTH) and click the Apply button.

 

Step 5.

Under the Inactive Proposals column, select the CiscoVPNClient-AES128-SHA-RSA proposal name and click the < button.

 

Step 6.

Click the CiscoVPNClient-AES128-SHA proposal name under the Active Proposals column and click the Deactivate button.

 

In the above sequence, I want to have only the "CiscoVPNClient-AES-128-SHA-RSA" proposal activated, which forces all IPsec clients to use the one I configured for certificates.

DMZ2 Data SA Configuration

Next, you'll need to set up a data SA to use the ISAKMP/IKE proposal:

Step 1.

Go to Configuration > Policy Management > Traffic Management > SAs; click the Add button.

 

Step 2.

For the SA Name parameter, enter ESP-AES128-SHA-RSA; under the IPsec parameters section, change the Authentication Algorithm to ESP/SHA/HMAC-160; change the Encryption Algorithm to AES-128; change the Time Lifetime parameter to 3600 seconds.

 

Step 3.

Under the IKE Parameters section, for the Digital Certificate parameter, use the drop-down selector and select 3030A; For the IKE Proposal parameter, use the drop-down selector and select CiscoVPNClient-AES128-SHA-RSA; then click the Apply button.

 

DMZ2 VPN-On-A-Stick, Rules, and Filters

I'm using a VPN-on-a-stick implementation with the DMZ2 corporate office concentrators. A VPN-on-a-stick uses a single interface for both protected and unprotected traffic. Because I'm using only the public interface on the DMZ2 concentrators, certain kinds of traffic are being dropped that I will need to allow, including OSPF routing updates, VCA messages, and the local campus traffic that wants to access remote access clients. There already are existing rules for the first two, but you'll need to add a set of rules for the local campus traffic. Once you have created the necessary rules, you'll need to activate these for the public interface filter. Here are the steps you'll need to perform:

Step 1.

Go to Configuration > Policy Management > Traffic Management > Rules and click the Add button.

 

Step 2.

In the Rule Name parameter, enter Campus 10.0.0.0/8 In; for the Direction drop-down selector, choose Inbound; for the Action drop-down selector, choose Forward; in the Source Address section, enter 10.0.0.0 for the IP Address parameter and 0.255.255.255 for the Wildcard-mask parameter; in the Destination Address section, enter 10.0.0.0 for the IP Address parameter and 0.255.255.255 for the Wildcard-mask parameter; click the Add button (this creates a rule that will allow traffic from and between 10.0.0.0/8, the corporate network, to enter the interface and reach the remote access clients.

 

Step 3.

In the Rule Name parameter, enter Remote Access 10.0.0.0/8 Out; for the Direction drop-down selector, choose Outbound; for the Action drop-down selector, choose Forward; in the Source Address section, enter 10.0.0.0 for the IP Address parameter and 0.255.255.255 for the Wildcard-mask parameter; in the Destination Address section, enter 0.0.0.0 for the IP Address parameter and 255.255.255.255 for the Wildcard-mask parameter; click the Add button (this allows all traffic from the remote access clients with an internal address of 10.0.0.0/8 to leave the interface and go anywhere once their packets are verified and decrypted).

 

Step 4.

In the Rule Name parameter, enter Campus 192.1.2.0/24 In; for the Direction drop-down selector, choose Inbound; for the Action drop-down selector, choose Forward; in the Source Address section, enter 192.1.2.0 for the IP Address parameter and 0.0.0.255 for the Wildcard-mask parameter; in the Destination Address section, enter 10.0.0.0 for the IP Address parameter and 0.255.255.255 for the Wildcard-mask parameter; click the Add button (this creates a rule that will allow traffic from 192.1.2.0/24 to 10.0.0.0/8the remote access clientsto enter the interface).

 

Step 5.

Next you'll need to assign these rules to the public interface filter: Go to Configuration > Policy Management > Traffic Management > Filters; click the Public (Default) filter and then click the Assign Rules to Filter button.

 

Step 6.

Under the Available Rules column, select the following rules individually and click the < button: OSPF In (forward/in), OSPF Out (forward/out), VCA In (forward/in), VCA Out (forward/out), Campus 10.0.0.0/8 In (forward in), Remote Access 10.0.0.0/8 Out (forward out), and Campus 192.1.2.0/24 In (forward in); click the Done button.

 

Step 7.

Go to Configuration > Interfaces; click the Ethernet 2 (Public) hyperlink; make sure that the Filter parameter is set to 2. Public (Default). Click the Apply button.

 

DMZ2 AAA

As mentioned earlier in the chapter, the user accounts will be defined on AAA RADIUS servers located in the corporate office's server farm. If you want to store accounting information about remote access connections, also define your AAA RADIUS servers as both authentication and accounting servers:

Step 1.

Because I skipped quick configuration, no internal server exists to allow for the remote access groups to be defined locally. To do this, go to Configuration > System > Servers > Authentication; click the Add button; for the Server Type drop-down selector, choose Internal Server; click the Add button.

 

Step 2.

Next, add the two RADIUS servers: go to Configuration > System > Servers > Authentication; click the Add button; for the Server Type drop-down selector, choose RADIUS or RADIUS with Expiry, depending on whether or not your AAA server supports changing of users' passwords when accounts expire; in the Authentication Server parameter, enter the IP address of the first AAA server, 10.1.1.1; if it's a Cisco Secure ACS server, leave the port number as 0, which defaults to UDP port 1645, otherwise you might have to change the port number to 1812 in the Server Port field depending on your server's RADIUS implementation; in the Server Secret and Verify fields, enter the encryption key for RADIUS communications (this must match what is configured on the AAA server; click the Add button.

 

Step 3.

From the Configuration > System > Servers > Authentication screen, select the newly added AAA RADIUS server and click the Test button; enter a username and password that exists on the AAA server and click the OK button; if you set everything up correctly on the concentrator and AAA RADIUS server, the authentication should be successful.

 

Step 4.

Repeat the last two steps for the second AAA RADIUS server in the server farm on the campus backbone, 10.1.2.1.

 

Step 5.

Go to the Configuration > System > Servers > Accounting screen and add the same two sets of AAA RADIUS servers again, but this time list them as places to store AAA accounting records; click the Add button; in the Accounting Server field, enter 10.1.1.1; in the Server Port field, change it to either 1,646 or 1,813 depending on what your AAA server uses for receiving accounting records; enter the same encryption key used when adding the server as an authentication server; click the Add button.

 

Step 6.

Repeat the last step for the second AAA RADIUS server, 10.1.2.1.

 

DMZ2 Base Group Configuration

Now that the basic configuration is done, you're ready to set up your group configuration. I'll start with the base group first. If you recall from earlier in the chapter, there are three groups of Internet userssales, administrators, and programmersand one group of hardware clients for the branch offices. For the most part, the configuration of these groups is the same, with some minor differences. Therefore, I'll start with the Base group configuration first and define all of the parameters that are the same among all groups:

Step 1.

Go to Configuration > User Management > Base Group.

 

Step 2.

Under the General tab, set the primary and secondary DNS servers to 10.1.1.3 and 10.1.1.4, respectively (these servers are located in the campus server farm along with the AAA RADIUS servers); set the primary and secondary WINS servers to 10.1.1.5 and 10.1.1.6 respectively; for the Tunneling Protocols parameter, uncheck PPTP, L2TP, and WebVPN only IPsec should be allowed.

 

Step 3.

Under the IPsec tab, use the drop-down selector to change the IPsec SA parameter to ESP-AES128-SHA-RSA; change the IKE Peer Identity Validation drop-down selector to Required, which forces the use of certificates for authentication; use the drop-down selector to change the Authentication parameter to either RADIUS or RADIUS with Expiry.

 

Step 4.

Under the Client FW tab, set the Firewall Setting parameter to Required; set the Firewall parameter to Cisco Integrated Client; set the Firewall Policy parameter to Policy Pushed (CPP) (the firewall policy will need to be disabled for the hardware client group); in the drop-down selector, choose Firewall Filter for VPN Client (Default).

 

Step 5.

Click the Apply button at the bottom of the screen.

 

DMZ2 Specific Hardware Client Group Configuration

Once you've configured the base group, you're ready to set up the specific groups. I'll start first with the hardware clients used by the branch offices. Perform the following to create and set up the branch office group:

Step 1.

Go to Configuration > User Management > Groups and click the Add Group button.

 

Step 2.

Under the Identity tab, set the Group Name attribute to Branch Office; set the password to cisco123 or something like this and re-enter it (you are required to do this even if you'll only be using certificates).

 

Step 3.

Under the Client Config tab, set the check the Allow Password Storage on Client parameter to allow the 3002s to store their username and password locally.

 

Step 4.

Under the Client FW tab, set the Firewall Setting parameter to No Firewall.

 

Step 5.

Under the Hw Client tab, check the check box for the Allow Network Extension Mode parameter.

 

Step 6.

Click the Add button.

 

DMZ2 Specific Software Client Group Configuration

Once I've created the branch office group, I'm ready to create the specific groups for the remote access users: sales, administration, and programming. Each group is by and large the same, except that I want to apply a filter to them to restrict each group's access, as follows:

The actual filtering will be done by the stateful firewall; however, to enforce these rules, the remote access users must be assigned addresses that will allow the stateful firewall to implement its filtering policies easily. Therefore, the following address pools will be used to assign internal addresses to the Internet clients:

Here is the configuration to set this up:

Step 1.

Go to Configuration > User Management > Group and click the Add Group button; under the Identity tab, set the Group Name parameter to Sales; set the password to something like cisco123 or something harder to guess (even though pre-shared keys aren't used in this design, they're required when adding a group); click the Add button.

 

Step 2.

On the Group screen, select the Sales group and click the Address Pools button; click the Add button; for the Range Start parameter, enter 10.7.0.1 for the 3030A concentrator; for the Range End parameter enter 10.7.7.254 for the 3030A concentrator; for the Subnet Mask parameter, enter 255.255.248.0; click the Add button; click the Done button.

 

Step 3.

Go to Configuration > User Management > Group and click the Add Group button; under the Identity tab, set the Group Name parameter to Administrators; set the password to something like cisco123 or something harder to guess (even though pre-shared keys aren't used in this design, they're required when adding a group); click the Add button.

 

Step 4.

On the Group screen, select the Administrators group and click the Address Pools button; click the Add button; for the Range Start parameter, enter 10.7.16.1 for the 3030A concentrator; for the Range End parameter enter 10.7.23.254 for the 3030A concentrator; for the Subnet Mask parameter, enter 255.255.248.0; click the Add button; click the Done button.

 

Step 5.

Go to Configuration > User Management > Group and click the Add Group button; under the Identity tab, set the Group Name parameter to Programmers; set the password to something like cisco123 or something harder to guess (even though pre-shared keys aren't used in this design, they're required when adding a group); click the Add button.

 

Step 6.

On the Group screen, select the Programmers group and click the Address Pools button; click the Add button; for the Range Start parameter, enter 10.7.32.1 for the 3030A concentrator; for the Range End parameter enter 10.7.39.254 for the 3030A concentrator; for the Subnet Mask parameter, enter 255.255.248.0; click the Add button; click the Done button.

 

Note

For the 3030B, be sure to use the other sets of addresses for the group assignment.

 

DMZ2 VCA

For IPsec remote access redundancy, I'll implement VCA to allow for both load balancing and redundancy. I've already allowed VCA messages to be transmitted and received on the public interface in the "VPN-On-A-Stick, Rules, and Filters" section. Only VCA needs to be enabled. Here are the steps to do this:

Step 1.

Go to Configuration > System > Load Balancing; enter 192.1.2.12 for the VPN Virtual Cluster IP Address parameter; for the IPsec Shared Secret and Verify Shared Secret, enter the same encryption password, like cisco123; check the check box for the Load Balancing Enable parameter; click the Apply button.

 

Note

You'll need to use the 192.1.2.12 address for the Easy VPN Server address on your clients.

Step 2.

When using VCA, you'll need to enable RRI and OSPF to allow the stateful firewalls to know which concentrator the appropriate hardware/ software client is connected to. To enable RRI, go to Configuration > System > IP Routing > Reverse Route Injection; click the check boxes for both the Client Reverse Route Injection and Network Extension Reverse Route Injection parameters; click the Apply button.

 

Step 3.

Go to Configuration > System > IP Routing > OSPF; click the Enabled check box; enter 192.1.1.10 on 3030A (or 192.1.1.11 on 3030B) for the Router ID parameter; click the Apply button.

 

Step 4.

Go to Configuration > System > IP Routing > OSPF Areas; click the Add button; in the Area ID parameter, enter 0.0.0.7 for the area ID; click the Add button.

 

Tip

You'll want to put the RRI routing information, that is, the concentrators, in a different area than the backbone (0.0.0.0) to reduce the effect of address updates from the concentrators disturbing the backbone OSPF devices; therefore, the DMZ2 interface on the stateful firewall will need to be in OSPF area 0.0.0.7.

Step 5.

Go to Configuration > Interfaces; click the Ethernet 2 (Public) hyperlink; click the OSPF tab; select the OSPF Enable check box; in the OSPF Area ID parameter, enter 0.0.0.7; click the Apply button.

 

Tip

Based on the internal IP addressing used for the remote access software client groups, you could configure static routes on your stateful firewall to point to the correct concentrator instead of using RRI with OSPF:

Based on this implementation the concentrator doesn't need to advertise host-specific routes, reducing the size of the routing table for the stateful firewall(s); however, you'll still need to enable OSPF and RRI on the concentrator to advertise the 3002s' network RRI routes. In this situation, be sure that client RRI is disabled on both concentrators!

Note

Once you've configured 3030A, you'll need to configure the 3030B. The configuration is essentially the same, with the exception of the IP addressing of the interfaces, the IP address groups for the internal addresses of the remote access users, the certificate CN field, and the OSPF routing ID.

 

Branch Office 3002 Hardware Clients

The 3002s will need to be configured for each branch office. Because certificates are being used, you'll need to perform the following steps:

The following sections will discuss this configuration for the 3002s at the branch offices.

Note

You might want to pre-configure the 3002s at the corporate office network and then drop-ship them at the branch offices. Then, all the branch office needs to do is to cable up the 3002 and turn it on.

 

3002 Quick Configuration

Here are the steps to access and configure the 3002 at a branch office:

Step 1.

Connect your PC to the 3002's private interface; set up your PC's IP address to 192.168.10.2; open a web browser to http://192.168.10.1; log in as admin and admin; click the Login button.

 

Step 2.

Click the Click here to start Quick Configuration hyperlink.

 

Step 3.

On the Time screen, make sure the date and time are correct and click the Continue button.

 

Step 4.

On the Upload Config screen, click the No button to continue with quick configuration.

 

Step 5.

On the Private Intf screen, choose the Yes option for Do you want to configure the IP address of the Private Interface? For the Do you want to use the DHCP server on Interface 1 to provide addresses for the local LAN? question, choose Yes, and configure the DHCP server parameters; click the Continue button.

 

Step 6.

For the Interface IP Address parameter, enter 10.200.x.," where x is the branch number; for the DHCP Address Pool Start parameter, enter 10.200.x.100 and for the DHCP Address Pool End parameter, enter 10.200.x.250; click the Continue button.

 

Step 7.

You'll lose your access to the 3002; set up your PC's IP address to 10.200.x.2; open up a web browser to http://10.200.x.1; log in as admin and admin; click the Login button.

 

Step 8.

Click the Click here to start Quick Configuration hyperlink; click the Public Intf hyperlink at the top of the web page; in the System Name field, enter BranchOfficeX, where X is the branch office number; depending on how your 3002 will obtain its address, either set it up as a DHCP client, as a PPoE client, or statically configure the IP address; click the Continue button.

 

Step 9.

On the IPsec screen, enter the virtual IP address of 192.1.2.12 for the Remote Server parameter; in the group name field, enter Branch Office and in the password field, enter the password for this group; in the Username and Password field, enter the XAUTH username of the 3002 (I typically use something like "3002br1," which needs to be configured on the AAA RADIUS Servers in the corporate office server farm); click the Continue button.

 

Note

You can't add a certificate during quick configuration on the VPN 3002s, so I'll temporarily go through quick configuration using pre-shared keys, obtain a certificate, and then change the configuration to use certificates for device authentication.

Step 10.

On the PAT screen, choose the radio button labeled No, use Network Extension mode; click the Continue button.

 

Step 11.

On the DNS screen, enter a domain name of company.com (your company name); click the Continue button; click the Continue button on the Static Routes screen; on the Admin screen, change the administrator account's password; click the Continue button, taking you back to the Main access window.

 

3002 Certificate Enrollment

To obtain a certificate for the 3002, perform the following steps:

Step 1.

From the main access screen, go to Administration > Certificate Management.

 

Step 2.

Obtain a root certificate: click the Click here to install a CA certificate hyperlink; click the SCEP (Simple Certificate Enrollment Protocol) hyperlink; in the URL field, enter the URL of the CA, like http://192.1.2.2/certsrv/mscep/mscep.dll; in the CA Descriptor field, enter the name of the CA, like caserver(this will be different for every CA); click the Retrieve button.

 

Step 3.

From the Administration > Certificate Management screen, click the Click here to enroll with a Certificate Authority hyperlink; click the Enroll via SCEP at caserver hyperlink (the name of the CA appears in the hyperlink).

 

Step 4.

In the Common Name field, enter 3002brX, where X is the branch office number; in the Organizational Unit field, enter Branch Office, the name of the group on the DMZ2 concentrators; in the Organization field, enter the company name; in the challenge password field, enter a password that will be used to revoke the certificate, if needed, like boson123456; change the Key Size to RSA 2048 bits; click the Enroll button (this may take some time, based on the large key size, so be patient).

 

Step 5.

Click the Go to Certificate Management hyperlink and examine your 3030A's identity certificate.

 

Caution

Unfortunately, the 3002s currently don't support NTP. Therefore, you'll want to check the date and time on the 3002s to periodically ensure that they are correct.

 

3002 Quick Configuration Again

Once you've installed the 3002's root and identity certificate, you can go back to quick configuration and change the device authentication to certificates:

Step 1.

Go to Configuration > Quick Configuration.

 

Step 2.

Click the IPsec hyperlink; check the check box labeled Use Certificate.

 

Step 3.

Click the Continue button; click the Done hyperlink at the top of the page.

 

Step 4.

Go to Monitoring > System Status and make sure the IPsec tunnel comes up you've installed the 3002's identity certificate.

 

Remote Access User Configuration

Once the 3002s are configured, the last part of the VPN Internet connectivity is to configure the Cisco VPN Client software on the Internet users' desktops. I'll assume that the users are using either Windows 2000 or XP and that the client will be the 4.6 version, which I'll assume is already installed on the users' desktops. Here are the steps you'll need to perform to prepare the users' configuration:

Step 1.

From your desktop, go to Start > Programs > Cisco Systems VPN Client > VPN Client.

 

Step 2.

Install your certificates first: click the Certificates tab; click the Enroll button.

 

Step 3.

Click the Online radio button; in the CA URL field, enter http://192.1.2.2/certsrv/mscep/mscep.dll; in the CA Domain parameter, enter caserver; for the Challenge Password, enter the value given to you by the CA administrator, if one exists, or one that you'll use to revoke the certificate; click the Next button.

 

Step 4.

In the Name field, enter the user's XAUTH username; in the Department field, enter the name of the group (either Sales, Administrators, or Programmers); in the Company field, enter the name of the company; in the ST field, enter the name of the state; in the Country field, enter the name of the country; click the Enroll button; verify your certificate by double-clicking it.

 

Step 5.

Next, add the connection profile to connect to the concentrator cluster on the DMZ2 segment; click the Connection Entries tab; click the New button; in the Connection Entry field, enter Corporate Office; in the Host field, enter the virtual address of the cluster (192.1.2.12); click the Certificate Authentication radio button; make sure the identity certificate with the user's CN value appears; click the Save button.

 

Step 6.

From the main menu, click Options > Stateful Firewall (Always On); from the main menu click Options and make sure that a check mark appears next to "Stateful Firewall (Always On)."

 

Step 7.

Test the new profile by selecting it and clicking the Connect button; enter the username and password: for token cards, you'll need to generate the one-time password (OTP) first and then enter the password.

 

Tip

Before enabling the use of token cards on the AAA RADIUS server, first I would test it with a static password defined for the users' accounts. Once this works on a handful of accounts, I would migrate to the use of token cards by the users.

Note

You'll want to install an NTP client on your user's computers and have it use the NTP server on the DMZ2 segment (this is beyond the scope of this book).

 

Main Campus Wireless Configuration

I've decided to use IPsec over the wireless transmission between the campus users' desktops and the campus network for added security, as you can see from Figure 24-2. The setup of the concentrators and software clients is similar to that done for the Internet remote access setup. However, there are some differences. For instance, I'll be using both interfaces on the two redundant concentrators and I'll enable auto-initiation on the software clients. Plus, the VPN Client needs to bring up the connection first before the users log in to the Microsoft domain/directory structure. The following sections will discuss the configuration of both of these platforms.

Wireless Concentrators

There are two concentrators handling the wireless access users. The users connect to an access pointthere are manyand are assigned a DHCP address from a DHCP server (for their wireless NICs). This is an address from 10.6.0.0/16; however, to access any campus resource, the users also must establish an IPsec tunnel to one of the two concentrators 3030C or 3030Dto access resources on the campus backbone or other locations, like the Internet or other offices. The following sections will discuss the configuration of the concentrators.

Wireless CLI Quick Configuration

First, boot up the 3030C and log in to its console using admin and admin as the username and password. When using quick configuration from the CLI, perform the following:

Step 1.

Accept all the defaults until you get to the private interface configuration prompt, Quick Ethernet 1 -> [0.0.0.0]. Then enter 10.6.1.1 for 3030C (or 10.6.1.2 for 3030D).

 

Step 2.

When prompted for the subnet mask of the private interface, enter 255.255.255.0.

 

Step 3.

Accept the defaults for the speed, duplexing, and MTU; then choose option 3, Save changes to Config file, and exit the CLI; the rest of the configuration can now be done using a web browser; therefore, enter h to remain to the main menu and log out.

 

Wireless Base Configuration

Now you can use a web browser to complete the configuration of the wireless campus concentrator by following these steps:

Step 1.

From your PC in the campus network, open a web browser and enter http://10.6.1.1/admin in the address bar.

 

Step 2.

Enter admin and admin for the username and password and click the Login button.

 

Step 3.

Click the Click here to go to the Main Menu hyperlink to go to the main menu and skip quick configuration.

 

Step 4.

Go to Configuration > System > General > Identification; in the System Name field, enter 3030C; click the Apply button.

 

Step 5.

Go to Configuration > System > Servers > NTP Servers > Hosts; click the Add button; enter 192.1.2.3; click the Add button.

 

Step 6.

Go to Configuration > System > Servers > DNS Servers; in the Domain field, enter the domain name (company.com); click the Apply button.

 

Step 7.

Go to Administration > Access Rights > Administrators; click the Modify button for the admin account; change the password for the account in both password fields; click the Apply button.

 

Step 8.

Go to Configuration > System > Address Management > Assignment; click the Use Address Pools check box; click the Apply button.

 

Step 9.

Go to Configuration > Interfaces; click the Ethernet 2 (Public) hyperlink; select the Static IP Addressing radio button; in the IP Address parameter, enter 10.6.2.1 for the 3030C or 10.6.2.2 for the 3030D concentrator; make sure the Subnet Mask parameter is 255.255.255.0; click the Apply button.

 

Step 10.

Go to Configuration > System > IP Routing > Default Gateways; enter the IP address of the Layer-3 device connected to the campus backbone, like 10.6.1.254.

 

Note

At some point in time, remember to change the password for the admin account on the "wireless" concentrators!

Tip

You'll probably want to use HSRP or VRRP to provide default gateway redundancy for your concentrators; otherwise, you'll need to configure a dynamic routing protocol, like OSPF, on the concentrators and connected Layer-3 devices.

 

Wireless Certificate Enrollment

Because certificates are used for device authentication, you'll need to install a root and identity certificate on the 3030C (and 3030D). This is almost the identical process I described earlier for the 3030A and 3030B:

Step 1.

Go to Administration > Certificate Management; click the Click here to install a CA certificate hyperlink; click the SCEP (Simple Certificate Enrollment Protocol) hyperlink.

 

Step 2.

In the URL field, enter the URL of the CA, like http://192.1.2.2/certsrv/mscep/mscep.dll; in the CA Descriptor field, enter the name of the CA, like caserver; click the Retrieve button.

 

Step 3.

From the Administration > Certificate Management screen, click the Click here to enroll with a Certificate Authority hyperlink; click the Enroll via SCEP at caserver hyperlink (the name of the CA appears in the hyperlink).

 

Step 4.

In the Common Name field, enter 3030C; in the Organizational Unit field, enter wireless; in the Organization field, enter the company name; in the challenge password field, enter a password that will be used to revoke the certificate, if needed, like boson123456; change the Key Size to RSA 2048 bits; click the Enroll button (this may take some time, based on the large key size, so be patient).

 

Step 5.

Click the Go to Certificate Management hyperlink and examine your 3030C's identity certificate.

 

Note

The only difference between this and the 3030D's certificate enrollment process is the CN value on the identity certificate.

 

Wireless ISAKMP/IKE Configuration

Once you have a certificate on the 3030C and 3030D, you'll need to set up ISAKMP/IKE. Unlike the Internet connectivity for remote access users, your wireless users don't need NAT-T, so it won't be enabled. However, an ISAKMP/IKE policy that uses certificates still needs to be set up:

Step 1.

Set up an ISAKMP/IKE Phase 1 proposal for certificates: Go to Configuration > Tunneling and Security > IPsec > IKE Proposals.

 

Step 2.

In the Active Proposals column, deactivate all possible proposals except for CiscoVPNClient-AES128-SHA by clicking the name of the proposal and then clicking the Deactivate button.

 

Step 3.

Click the CiscoVPNClient-AES128-SHA proposal name under the Active Proposals column and click the Copy button; enter CiscoVPNClient-AES128-SHA-RSA for the Proposal Name; for the Authentication Mode drop-down selector, choose RSA Digital Certificate (XAUTH) and click the Apply button.

 

Step 4.

Under the Inactive Proposals column, select the "CiscoVPNClient-AES128-SHA-RSA" proposal name and click the < button.

 

Step 5.

Select the CiscoVPNClient-AES128-SHA proposal name under the Active Proposals column and click the Deactivate button.

 

In the above sequence, I want to have only the "CiscoVPNClient-AES-128-SHA-RSA" proposal activated. This forces all IPsec wireless clients to use the one I configured for certificates.

Wireless Data SA Configuration

Next, you'll need to set up a data SA to use the ISAKMP/IKE proposal, like so:

Step 1.

Go to Configuration > Policy Management > Traffic Management > SAs; click the Add button.

 

Step 2.

For the SA Name parameter, enter ESP-AES128-SHA-RSA; under the IPsec parameters section, change the Authentication Algorithm to ESP/ SHA/HMAC-160; change the Encryption Algorithm to AES-128; change the Time Lifetime parameter to 3600 seconds.

 

Step 3.

Under the IKE Parameters section, for the Digital Certificate parameter, use the drop-down selector and select 3030C (or 3030D for the other concentrator); For the IKE Proposal parameter, use the drop-down selector and select CiscoVPNClient-AES128-SHA-RSA; then click the Apply button.

 

Wireless AAA

As mentioned earlier in the chapter, the user accounts will be defined on AAA RADIUS servers located on the campus server farm segment. If you want to store accounting information about wireless remote access sessions, also define your AAA RADIUS servers as both authentication and accounting servers by using the following steps:

Step 1.

Because I skipped quick configuration, no internal server exists to allow for the groups to be defined locally. To do this, go to Configuration > System > Servers > Authentication; click the Add button; for the Server Type drop-down selector, choose Internal Server; click the Add button.

 

Step 2.

Next add the two RADIUS servers: go to Configuration > System > Servers > Authentication; click the Add button; for the Server Type drop-down selector, choose RADIUS or RADIUS with Expiry, depending on whether or not your AAA server supports changing of users' passwords when accounts expire; in the Authentication Server parameter, enter the IP address of the first AAA server, 10.1.1.1; if it's a Cisco Secure ACS server, leave the port number as 0, which defaults to UDP port 1645, otherwise you might have to change the port number of 1812 in the Server Port field depending on your server's RADIUS implementation; in the Server Secret and Verify fields, enter the encryption key for RADIUS communications (this must match what is configured on the AAA server); click the Add button.

 

Step 3.

From the Configuration > System > Servers > Authentication screen, select the newly added AAA RADIUS server and click the Test button; enter a username and password that exists on the AAA server and click the OK button; if you set everything up correctly on the concentrator and AAA RADIUS server, the authentication should be successful.

 

Step 4.

Repeat the last two steps for the second AAA RADIUS server on the DMZ2 segment, 10.1.2.1.

 

Step 5.

Go to the Configuration > System > Servers > Accounting screen and add the same two sets of DMZ2 AAA RADIUS servers again, but this time list them as places to store AAA accounting records; click the Add button; in the Accounting Server field, enter 10.1.1.1; in the Server Port field, change it to either 1646 or 1813 depending on what your AAA server uses for receiving accounting records; enter the same encryption key used when adding the server as an authentication server; click the Add button.

 

Step 6.

Repeat the last step for the second AAA RADIUS server, 10.1.2.1.

 

Wireless Base Group Configuration

Now that the basic configuration is done, you're ready to set up your group configuration. I'll start with the base group first. If you recall from earlier in the chapter, there are three groups of users: sales, administrators, and programmers. Unlike the Internet remote access devices, I don't have to worry about any hardware clientsjust the desktop software clients. For the most part, the configuration of these groups is the same, with some minor differences. Therefore, I'll start with the base group configuration first and define all of the parameters that are the same among all groups:

Step 1.

Go to Configuration > User Management > Base Group.

 

Step 2.

Under the General tab, set the primary and secondary DNS servers to 10.1.1.3 and 10.1.1.4, respectively (these servers are located in the campus server farm along with the AAA RADIUS servers); set the primary and secondary WINS servers to 10.1.1.5 and 10.1.1.6, respectively; for the Tunneling Protocols parameter, uncheck PPTP, L2TP, and WebVPNonly IPsec should be allowed.

 

Step 3.

Under the IPsec tab, use the drop-down selector to change the IPsec SA parameter to ESP-AES128-SHA-RSA; change the IKE Peer Identity Validation drop-down selector to Required, which forces the use of certificates for authentication; use the drop-down selector to change the Authentication parameter to either RADIUS or RADIUS with Expiry.

 

Step 4.

Under the Client FW tab, set the Firewall Setting parameter to Required; set the Firewall parameter to Cisco Integrated Client; set the Firewall Policy parameter to Policy Pushed (CPP); in the drop-down selector, choose Firewall Filter for VPN Client (Default).

 

Step 5.

Click the Apply button at the bottom of the screen.

 

Wireless Specific Software Client Group Configuration

Once I've configured the base group policies, I'm ready to create the specific groups for the wireless users: sales, administration, and programming. These are the same three groups I defined on the DMZ2 concentrators. The following address pools will be used to assign internal addresses to the clients:

Based on this addressing implementation, I could easily apply additional filtering policies inside the campus network Layer-3 devices to restrict access to various locations. Here is the configuration to set this address configuration policy on the campus concentrators:

Step 1.

Go to Configuration > User Management > Group and click the Add Group button; under the Identity tab, set the Group Name parameter to Sales; set the password to something like cisco123 or something harder to guess (even though pre-shared keys aren't used in this design, they're required when adding a group); click the Add button.

 

Step 2.

On the Group screen, click the Sales group and click the Address Pools button; click the Add button; for the Range Start parameter, enter 10.7.128.1 for the 3030C concentrator; for the Range End parameter enter 10.7.135.254 for the 3030C concentrator; for the Subnet Mask parameter, enter 255.255.248.0; click the Add button; click the Done button.

 

Step 3.

Go to Configuration > User Management > Group and click the Add Group button; under the Identity tab, set the Group Name parameter to Administrators; set the password to something like cisco123 or something harder to guess (even though pre-shared keys aren't used in this design, they're required when adding a group); click the Add button.

 

Step 4.

On the Group screen, click the Administrators group and click the Address Pools button; click the Add button; for the Range Start parameter, enter 10.7.144.1 for the 3030C concentrator; for the Range End parameter enter 10.7.151.254 for the 3030C concentrator; for the Subnet Mask parameter, enter 255.255.248.0; click the Add button; click the Done button.

 

Step 5.

Go to Configuration > User Management > Group and click the Add Group button; under the Identity tab, set the Group Name parameter to Programmers; set the password to something like cisco123 or something harder to guess (even though pre-shared keys aren't used in this design, they're required when adding a group); click the Add button.

 

Step 6.

On the Group screen, click the Programmers group and click the Address Pools button; click the Add button; for the Range Start parameter, enter 10.7.160.1 for the 3030C concentrator; for the Range End parameter enter 10.7.167.254 for the 3030C concentrator; for the Subnet Mask parameter, enter 255.255.248.0; click the Add button; click the Done button.

 

Note

For the 3030D, be sure to use the other sets of addresses for the group assignment listed in the above bullet points.

 

Wireless VCA

I'll implement VCA on the 3030C and 3030D to allow for both load balancing and redundancy. Here are the steps to do this:

Step 1.

You need to allow VCA messages on the public interface: Go to Configuration > Policy Management > Traffic Management > Filters; select the Public (Default) filter and click the Assigns Rules to Filter button; under the Available Rules column, select VCA In (forward/in) and click the < button; under the Available Rules column, select VCA Out (forward/out) and click the < button; click the Done button; repeat the same process for the physical interface filter.

 

Step 2.

Go to Configuration > System > Load Balancing; enter 10.6.2.5 for the VPN Virtual Cluster IP Address parameter; for the IPsec Shared Secret and Verify Shared Secret, enter the same encryption password, like cisco123; check the check box for the Load Balancing Enable parameter; click the Apply button.

 

Note

You'll need to use the 10.6.2.5 address for the Easy VPN Server address on your clients.

Step 3.

When using VCA, you'll need to enable RRI and OSPF to allow the stateful firewalls to know which concentrator the appropriate hardware/software client is connected to. To enable RRI, go to Configuration > System > IP Routing > Reverse Route Injection; click the check boxes for only the Client Reverse Route Injection parameter (Network Extension mode isn't used and therefore is not necessary); click the Apply button.

 

Step 4.

Go to Configuration > System > IP Routing > OSPF; click the Enabled check box; enter 10.6.1.1 on 3030C (or 10.6.1.2 on 3030D) for the Router ID parameter; click the Apply button.

 

Step 5.

Go to Configuration > System > IP Routing > OSPF Areas; click the Add button; in the Area ID parameter, enter 7.7.7.128 for the area ID; click the Add button.

 

Tip

You'll want to put the RRI routing information, that is, the concentrators, in a different area than the backbone (0.0.0.0) to reduce the effect of address updates from the concentrators disturbing the backbone OSPF devices; therefore, the DMZ2 interface on the stateful firewall will need to be in OSPF area 0.0.7.128.

Step 6.

Go to Configuration > Interfaces; click the Ethernet 2 (Private) hyperlink; click the OSPF tab; select the OSPF Enable check box; in the OSPF Area ID parameter, enter 0.0.7.128; click the Apply button.

 

TIP

Based on the internal IP addressing used for the wireless software client groups, you could configure static routes on your Layer-3 campus device to point to the correct concentrator:

Based on this implementation, the concentrator doesn't need to advertise host-specific routes, reducing the size of the routing table for the stateful firewall(s); and because there are no 3002s, you don't need to advertise any network extension mode network numbers. If you decide to implement this solution, be sure that client RRI is disabled on both concentrators.

Note

Once you've configured 3030C, you'll need to configure the 3030D. The configuration is essentially the same, with the exception of the IP addressing of the interfaces, the IP address groups for the internal addresses of the wireless users, the certificate CN field, and the OSPF routing ID.

 

Wireless User Configuration

The last part of the discussion on wireless campus connectivity is how to configure the Cisco VPN Client software on the wireless users' desktops. I'll assume that the users either are using Windows 2000 or XP and that the client will be the 4.6 version, which I'll assume is installed already on the users' desktops. Here are the steps you'll need to perform to prepare the users' configuration:

Step 1.

From your desktop, go to Start > Programs > Cisco Systems VPN Client > VPN Client.

 

Step 2.

Install your certificates first: click the Certificates tab; click the Enroll button.

 

Step 3.

Click the Online radio button; in the CA URL field, enter http://192.1.2.2/certsrv/mscep/mscep.dll; in the CA Domain parameter, enter caserver; for the Challenge Password, enter the value given to you by the CA administrator, if one exists, or one that you'll use to revoke the certificate; click the Next button.

 

Step 4.

In the Name field, enter the user's XAUTH username; in the Department field, enter the name of the group (either Sales, Administrators, or Programmers); in the Company field, enter the name of the company; in the ST, field, enter the name of the state; in the Country field, enter the name of the country; click the Enroll button; verify your certificate by double-clicking it.

 

Step 5.

Next, add the connection profile to connect to the concentrator cluster on the wireless segment: click the Connection Entries tab; click the New button; in the Connection Entry field, enter Corporate Wireless; in the Host field, enter the virtual address of the cluster (10.6.2.5); click the Certificate Authentication radio button; make sure the identity certificate with the user's CN value appears; click the Save button.

 

Step 6.

From the main menu, click Options > Stateful Firewall (Always On); from the main menu click Options and make sure that a check mark appears next to "Stateful Firewall (Always On)."

 

Step 7.

From the main menu, click Options > Windows Logon Properties; click the check box labeled Enable start before logon, which allows the VPN Client to start up before the user logs in to a Microsoft domain or directory structure; click the OK button.

 

Step 8.

Test the new profile by selecting it and clicking the Connect button; enter the username and password. For token cards, you'll need to generate the OTP first and then enter the password.

 

Step 9.

Once the connection works, you can now change the vpnclient.ini file to allow for auto-initiation: open the vpnclient.ini file with a text editor and place the entries in Example 24-5 at the end of the "[Main]" section; at the bottom of the vpnclient.ini file, add section information listed in Example 24-6 (for the ConnectionEntry parameter in this example, use the name of the group previously defined in Step 5); close the VPN Client, if open, and when re-opened, verify that you see the Automatic VPN Initiation option from the Options menu.

 

Note

Notice that in Example 24-6, the section for the WLAN profile specifies an address and mask of 0.0.0.0/0, which means that any address assigned to the wireless client will cause auto-initiation to take place.

Step 10.

Based on a 30-second retry interval, the wireless client should bring up a tunnel to the 3030 cluster within 30 seconds.

 

Example 24-5. vpnclient.ini File for Wireless Users' Auto-Initiation

[Main] not;output omittedimages/U2192.jpg border=0> AutoInitiationEnable=1 AutoInitiationRetryIntervalType=1 AutoInitationRetryInterval=30 AutoInitiationRetryLimit=20 AutoInitiationList=WLAN

 

Example 24-6. vpnclient.ini File for Wireless User's Connection Profile Information

[WLAN] Network=0.0.0.0 Mask=0.0.0.0 ConnectionEntry=Sales Connect=1

Tip

To simplify the client configuration, I would pre-configure the vpnclient.ini with the auto-initiation parameters and the .pcf files for the connection profiles and then test them. Once I had auto-initiation working for each profile, I would then place these in the client installation package and install the client software. Once installed, the only thing you would need to do is to go through the certificate enrollment process to obtain a certificate.

Related

Категории