August 2008
Purpose and Scope of this Document
The main objective of the document is to outline the architectural and design specifications for the Cisco Virtual Office solution.
This document serves as a case study about Cisco IT's deployment of Cisco Virtual Office. Please visit http://www.cisco.com/go/cvo for the comprehensive set of Cisco Virtual Office white papers, which show how to deploy Cisco Virtual Office in a guided, step-by-step format.
The case study provided here goes beyond the standard concept of design specifications and addresses some of the services offered as part of the Cisco Virtual Office framework and includes service-oriented architectural components such as provisioning, management, TCO and business requirements, and lessons learned from Cisco IT implementation of Cisco Virtual Office.
1. Cisco Virtual Office Solution Design Guide Introduction
The Cisco Virtual OfficeVirtual solution is designed to provide full office replica and near office user experience for day extenders, part-time teleworkers, and full-time teleworkers in their home offices. It provides Wireless Service@Home for both Cisco employees and spouses and kids. It also provides IP telephony (IPT) @Home and Video@Home for Cisco employees-in other words, Cisco Virtual Office extends Cisco Unified Communications all the way to the home, thus providing global reach and full access to collaboration tools. Cisco Virtual Office enables businesses to offer new services, maintaining manageable TCO.
Cisco Virtual Office is built on four pillars: end-to-end layered security, end-to-end connectivity, end-to-end provisioning, and end-to-end management. The production offering is based on a single piece of Customer Premises Equipment (CPE) for the home-in the past the Cisco 831 Router.Now it is based on the Cisco 870 Series, which takes advantage of Dynamic Multipoint VPN (DMVPN)1 as an underlying VPN technology and architecture. For Field Sales Offices (FSOs), larger platforms are used; for example, Cisco 1800, 2800, or 3800 Series Integrated Services Routers.
The four pillars constitute the network platform, which is a basis for the service-oriented architecture capable of delivering a variety of services and business models, eventually enhancing service availability and performance and improving the overall user experience and increasing workforce productivity.
With Cisco Virtual Office, companies can take advantage of all the best in their network, and benefit from the framework of services that Cisco Virtual Office provides, as shown in Figure 1.
Figure 1. Cisco Virtual Office Framework
1.1. Business Strategy
Cisco Virtual Office takes advantage of the exploding broadband offering, where more than 225 million home users worldwide are already using broadband to connect to the Internet2. The trend is expected to accelerate the volume of users and the resulting demand for more bandwidth. Additionally, these users are expected to purchase more new services on the top of the FTTN, Wi-Fi, and WiMax broadband connections and take advantage of new broadband technology offerings.
The demand for video from Small Office, Home Office (SOHO) users, and Small and Medium-sized Business (SMB) users, will require Internet Service Providers (ISPs) to offer 15-25 Mbps at the access layer of their networks. Some service providers have already announced plans to offer next-generation networks for their customers. The expected Differentiated Services (DifServ) standard3 and offering at the access layer and edges of the provider's network and the Internetwork Services (InterServ)4 between peers will allow Enterprises to prioritize their traffic and applications and provide differentiated services for their users with committed Internet Protocol Service-Level Agreements (IP SLAs).
The expected increase in the number of telecommuters and workforce disruptions (caused by pandemics and natural disasters) creates opportunities for the Cisco Virtual Office type of managed security services solutions, enabling several categories of users to conduct business away from permanent offices and owned and leased corporate facilities for extended periods of time.
Continued globalization of the workforce requires more and more business activities to take place outside of normal business hours, affecting employees' well-being and work-life balance. New technologies and services offered by Cisco Virtual Office enable employees to keep flexible hours and work on business activities independent of their location, thereby enabling Enterprises to maintain and retain talent, giving employees the tools to maintain a work-life balance even during changing circumstances in employees' personal or work life.
Offering an end-to-end manageable, secure, easily deployed solution helps Cisco customers implement effective access control mechanisms and improves the overall security protection of an Enterprise's intellectual property.
1.2. Business Continuity-Disater Recovery and Pandemic
The Cisco Virtual Office solution is positioned as one of the major Cisco technologies for crisis management and business continuity management. Based on industry studies, only 13 percent of enterprises are prepared for workforce disruptions. With Cisco Virtual Office as a business enabler, a company can quickly relocate its workforce because of the Cisco Virtual Office `Zero Touch' deployment model, scalability, redundancy, and resiliency. Therefore Cisco Virtual Office greatly increases employee productivity and improves the user experience today, and sets the foundations for business continuity and increased business resiliency (Figure 2).
Figure 2. Increase Workforce Resiliency
1.3. Cisco IT Strategy
The Cisco Virtual Office is the next-generation remote-access solution from Cisco. Its primary goal is to improve the overall security of intellectual property. A critical strategy for achieving this goal is to implement effective access control mechanisms to ensure the workforce has access to the network by individuals with appropriate security credentials. As a result, IT must be able to continuously manage all end devices to ensure they are running with the latest Cisco IOS® Software updates, patches, and policies, yet allow the users of the devices to retrieve data and use Cisco services securely. Other goals include reduction of operating expenses, while increasing revenue.
Cisco Virtual Office allows Cisco customers to take advantage of the latest Cisco VPN technologies, Cisco IT best deployment and management practices, and lessons learned. It includes some industry-leading practices such as Secure Device Provisioning for CPE (SDP), Zero Touch Deployment (ZTD) for IPT, industry-leading VPN technology such as DMVPN, and management and provisioning practices, which add value to Cisco products, allow Cisco to offer end-to-end solutions and professional practices for SOHO and SMB Enterprise and ISP market segments, and expand IT business effect beyond the boundaries of showcasing technologies, increasing the overall productivity. Cisco Virtual Office achieves the following goals common to all IT organizations:
• Design and build supportable and scalable Internet-based VPN solutions, improving accessibility to corporate information resources from virtually everywhere.
• Offer a rapid ordering and deployment solution for a VPN service and other bundled services to the home with minimal installation and configuration effort for our clients. Expand the existing zero touch model (ZTD) for deploying CPE devices into a Secure Device Provisioning model for CPE. Expand the ZTD to all services, expanding the existing ZTD for CPE into IPT, Wi-Fi, and video services deployments.
– Extend the footprint of the full-service workplace beyond traditional corporate owned and leased facilities, extending virtually all workplace services to any user's location.
– Enable a readily available Business Continuity option for mission-critical business functions, permitting users to support Cisco business when Cisco owned and leased office space is unreachable.
2. Cisco Virtual Office Overview
Cisco Virtual Office is introducing a managed secure end-to-end solution for bringing enterprise-quality services-voice, video, wireless, and data-into the home offices. It is designed to provide time- and location-agnostic service availability for employees' home offices, increase their flexibility and user satisfaction, improve overall productivity, and enable unified communications. Based on industry analysis, in Cisco Virtual Office type solutions the TCO comprises 20 percent acquisition cost, 35 percent initial install and deployment cost, and 45 percent day-to-day operations and management cost.
Figure 3 shows the Cisco deployment of Cisco Virtual Office as it expands to all theaters as shown in.
Figure 3. The Existing Cisco IT Global Cisco Virtual Office Deployment
The management of the remote routers is performed over management tunnels, terminated to Secure Management Gateways (SMGs) located in San Jose, RTP, Amsterdam, Hong Kong, and Bangalore. This deployment is designed to host more then 30,000 users globally.
From an architectural point of view, the current Cisco Virtual Office architecture is built on the concept of integrated managed security and encompasses the following major pillars:
• End-to-end security
• End-to-end connectivity
• End-to-end provisioning
• End-to-end management
The existing architecture allows reduction of the deployment and management cost, effectively reducing the TCO of the solution.
Following are the Cisco Virtual Office major achievements that result in a lower TCO:
• Use of integrated devices, such as Cisco integrated services router II generation, combing VPN, firewall, QoS, Wireless, and threat defense mechanisms
• Use of DMVPN and the dynamic routing protocols integration as the technology framework of the solution for full resiliency with failover, load balancing, and server load balancing (SLB)
• Deployment of end-to-end models for security, connectivity, deployment, and management
• Use of ZTD models to lower the cost of the initial installation and deployment
• Automation of the deployment and management framework
• Integration of the solution into the existing management system in order to use the existing management components and develop reusable ones
• Enabling of a self-adaptable network changes to dynamically update its routing tables from end-to-end
• Adding of on-demand tunnels for bandwidth preservation and least-possible latency
Figure 4. Cisco Virtual Office Is Built on an End-to-End Model
These pillars hold the foundations for rapid deployment of today's critical IP applications:
• Data
• VoIP
• QoS
• Wi-Fi
• Multicast
• Video
From an architectural point of view, the end-to-end architecture approach will inherit and expand the existing foundation and framework to allow more services to be supported as part of the program and become an enabler for service-oriented architectures, much more suitable for end-to-end, easily deployed, secure, managed service-oriented solutions.
Many of the management tasks can be automated and integrated with existing IT tools. These task include: adding device profiles to a AAA; adding DNS router name and respective IP address to the corporate DNS server; terminating employees; running IP SLA probes; and collecting performance data.
3. Cisco Virtual Office End-to-End Security Design and Configuration
As stated earlier, the Cisco IOS Software end-to-end security solution is integrated into the connectivity, provisioning, and management framework. The following chapter addresses the end-to-end security of Cisco Virtual Office in its architectural and design aspects and it provides configurations examples based on the architecture provided in Chapter 2.
The end-to-end security in Cisco Virtual Office is based on the Cisco IOS Software concept of security, available for Cisco IOS Software Release 12.4 and later. The existing layered security model includes the security of Cisco IOS Software, password protection, hostname protection, and digital certificates for authentication, encryption, and nonrepudiation. Based on a Cisco Virtual Office configuration, a CPE device has two kinds of ports: trusted port and nontrusted port. Every user who tries to connect to the trusted port of the CPE router is prompted for valid user credentials. Typically 802.1x is used to automatically assign the corrected VLAN to a user (trusted, or nontrusted, often called guest VLAN). When users are successfully authenticated, they are granted access to corporate resources; when users fail the authentication, their traffic is sent to the corporate gateways, but based on ACLs, those users are denied access to the corporate resources and granted access only to the Internet. User who are connected to the nontrusted port of the router can access only the Internet.
Cisco IP phones are automatically detected and placed in a specific voice VLAN.
The end-to-end security in Cisco Virtual Office requires a continuum of security features and all its layers and components. The end-to-end security of Cisco Virtual Office in essence provides collaborative security that is typically associated with the so-called triad of trust and includes authorization, authentication, and posture.
Figure 5. Cisco Virtual Office Architecture
3.1. Loss of RSA Private Key
If a router is stolen, or password recovery is attempted, the router private keys are erased. Without the private keys, the spoke router cannot successfully negotiate IPsec connectivity with the Management or Data gateways. The feature prevents the user from downgrading the Cisco IOS Software on the spoke router, performing password recovery, restoring the spoke router to the initially deployed image, and maintaining the capabilities of the router to establish the VPN tunnels to the Management and Data gateways because the RSA private key is destroyed.
3.2. Disabling Password Recovery
Cisco IOS Software routers provide the facility to recover from a forgotten password. A Cisco IOS Software savvy end user may be able to look at the router configuration using this method. This action can be prevented by disabling password recovery by configuring "no service password-recovery" on global configuration:
Config terminal
test-router(config)#no service password-recovery
WARNING:
Executing this command will disable password recovery mechanism.
Do not execute this command without another plan for
password recovery.
Are you sure you want to continue? [yes/no]:yes
test-router(config)#
3.3. Restricting Console Access
Security policy of some customers may require controlling the access to the console port. There are two ways to control the console access: password protection and locking down.
Enabling console access authentication password protects the console access. Users will be prompted for username and password. Access is granted only if the correct credentials are entered. The router can be configured to verify with the local credentials configured on the router or with a RADIUS or TACACS server. Doing local authentication will ensure that console access is possible even if the network connectivity is down.
3.4. Locking the Console Port
This method completely locks down the console. When it is enabled, the only way to access the router will be with network-based mechanisms such as SSH or Telnet, meaning when the network access is gone the router becomes inaccessible. Therefore caution should be taken when locking the console portion routers which can loose network access often. For example, when users who change their ISP to a different IP address assignment, such as from DHCP to static. (On Cisco 870 platforms users can press the reset button for 6 to 10 seconds to reset the router configuration to factory default. Other platforms do not give that option.) Here is the simple sequence to configure the feature:
menu disable clear-screen
menu disable title %Console Disabled%
line con 0
autocommand menu disable
! "clear line 0" will clear the console connection if a connection
! is active. But this needs to be done from a ssh or telnet window.
If these commands are entered from Telnet or the console prompt, we might need a "clear line 0" command at the end of the configuration.
3.5. Authentication Proxy
Authentication Proxy is configured on all CPE devices. When the user connects a computer to a particular port of the router, or associates with the trusted wireless connection, the authentication proxy mechanism prompts the user for valid user credentials. Upon success, the computer is granted access to the corporate resources. If the user connects a computer to the nontrusted port of the router, the PC is granted access to the Internet without being challenged for credentials. The authentication proxy authenticates an IP address, which after the successful event is stored in the authentication proxy cache memory. The only exception is IPT traffic, which is allowed to pass even if a user has not successfully authenticated against the auth-proxy mechanism on the device terminating the IPT. The authentication proxy first checks to see if the user has been authenticated. If a valid authentication entry exists for the user, the connection is completed with no further intervention by the authentication proxy. If no entry exists, the authentication proxy responds to the request, forcing the user's device to open a browser window and prompting the user for a username and password. The login page is shown in Figure 6. Users must successfully authenticate in order to access the Cisco internal network resources. Otherwise, users can access only the Internet.
Figure 6. Authentication Proxy Login Page
In the Cisco Virtual Office deployment, user authentication requests are sourced from the IP address from the BVI1 subnet. User access is authenticated against the Active Directory servers maintained by Cisco IT. If the authentication succeeds, the user's authorization profile is retrieved from the AAA server. Authentication Proxy uses the information in this profile to create dynamic access control entries (ACEs) and add them to the inbound (input) access control list (ACL) of an input interface and to the outbound (output) ACL of an output interface-if an output ACL exists at the interface. For the Cisco Virtual Office CPE devices, the ACL is on trusted ports.
Upon successful user authentication, dynamic access-control-list entry ACEs are added to the interface configuration. The authentication proxy customizes each of the access-list entries in the user profile by replacing the source IP addresses in the downloaded access list with the source IP address of the authenticated host. The authentication proxy sends a message to the user confirming that the login was successful and the device is then given immediate access to the Cisco internal network resource. An inactivity timer is set to 1440 minutes. As a result, if there is no traffic to a device with an IP address that has already successfully authenticated against the authentication proxy, then the dynamic ACEs are deleted, and any user trying to access internal Cisco network resources from a device using the same IP address, including the original device, will have to reauthenticate.
If the authentication fails, the authentication proxy reports the failure to the user and prompts the user with multiple retries. If the user fails to authenticate after a preconfigured number of attempts, the user must wait 2 minutes and initiate another HTTP session to trigger authentication proxy. The login page is refreshed each time the user makes requests to access information from a web server.
The initial Cisco Virtual Office Authentication Proxy configuration enables users to make and receive calls over their IP phones, bypassing the authentication proxy. There are several configuration components of auth-proxy:
• Configuring AAA
• Configuring the HTTP server
• Configuring the Authentication Proxy ACLs
3.6. Configuring Authentication Proxy
aaa new-model
aaa group server radius authproxy
server-private <ip address> auth-port 1812 acct-port 1813 key 0 <key>
ip radius source-interface BVI1
!
aaa authorization auth-proxy default group authproxy
!
ip inspect name fw tcp
ip inspect name fw udp
ip inspect name fw rtsp
ip inspect name fw tftp
ip inspect name fw skinny
ip inspect name fw esmtp
ip inspect name fw sip
ip inspect name fw sip-tls
!
ip admission auth-proxy-banner file http://10.99.99.2/customized-authpproxy-page.htm
ip admission auth-proxy-banner http ^
Please login now to get connected to the corporate network
^
ip admission max-login-attempts 5
! Configure 1440 minutes of inactivity timeout.
! proxy_acl is the intercept ACL
ip admission name pxy proxy http inactivity-time 1440 list proxy_acl
!
ip admission name test_proxy proxy http list proxy_acl
interface BVI1
description inside interface
ip inspect fw in
ip access-group proxy_inbound_acl in
ip admission test_proxy
!...
ip access-list extended proxy_acl
remark --- Auth-Proxy ACL -----------
! Deny lines are used to bypass auth-proxy
deny tcp any host 10.10.200.1 eq www
! auth-proxy will intercept http access matching the below permit lines
permit tcp any 10.10.30.0 0.0.255 eq www
...
!
ip access-list extended proxy_inbound_acl
remark --- Auth-Proxy Inbound ACL which blocks the traffic ---
! Allow access to certain protcols
permit udp any any eq domain
permit udp any any eq netbios-ns
permit udp any any eq netbios-dgm
permit udp any any eq 5445
permit tcp any any eq 5060
permit tcp any any eq 5061
permit tcp any any eq 2000
permit tcp any any eq 2443
permit udp any any eq tftp
! Block corporate subnets. If split tunneling is not enabled denying
! all traffic using
! "deny any any" is sufficient
deny ip any 10.0.0.0 0.255.255.255
...
...
! if split tunneling is enabled
permit ip any any
!
3.7. IP Phone Consideration
IP phones cannot display authentication proxy prompt. Therefore it cannot be authenticated using auth-proxy. One solution is to use the Cisco IOS Deep Firewall Inspection mechanism. IP phones usually download the initial configuration using TFTP. In that case TFTP needs to be opened in the inbound ACL. If the IP phone is using Skinny Client Control Protocol (SCCP), then UDP port 2000 needs to be opened. IP inspection will dynamically open holes for RTP streams when a phone call is made. By opening only UDP 2000, access control is not diluted much and IP phones work without doing auth-proxy. The same thing works for SIP phones. For SIP phones, open UDP 5060 and 5061.
UDP port 5445 needs to be opened if Cisco Unified Video Advantage (UVA) is enabled on the IP phone.
Important Authentication Proxy Diagnostics Commands:
3.8. IEEE 802.1x Port Authentication
The IEEE 802.1x and its Layer 2 and Layer 3 extensions provide IP device-level security for both the switch-port and routed-port CPE devices. Deploying this feature in Cisco Virtual Office ensures that only authenticated devices get access to the VPN network5. Nonauthenticated devices are assigned to "auth-failed VLAN" and get only Internet access. This setup is particularly helpful for separating "spouse and kids" computers from an employee's computer. Following is a list of important functions provided by this feature:
• User Authentication and Port Security: Only authorized users gets access to the VLAN.
• Automatic VLAN Assignment: Port is assigned the appropriate VLAN based on the user credentials.
• Guest VLAN: Clientless devices can be assigned to a separate VLAN designated as Guest VLAN.
• Single host/Multi host mode (the Cisco 871 supports only multihost mode)
Using 802.1x, all IP devices connecting to the router are subject to 802.1x-based credential validation-only on the switch ports of the integrated services router platforms. The device will not get an IP address until the credentials are validated. When validated, the port becomes active and the device gets network access. If the validation fails the port is shut down.
This authentication requires an 802.1x client (called supplicant) running on the device. Many devices such as IP phones do have 802.1 x supplicants. In order to accommodate a clientless device, the guest VLAN feature can be enabled. Guest VLAN typically has fewer access privileges than the primary VLAN. In the case of Cisco Virtual Office, the guest VLAN is part of BVI2.
Cisco IP Phones have the capability to request a voice VLAN. If voice VLAN is enabled on the router, the Cisco IP Phone is automatically placed in that VLAN and bypasses 802.1x authentication.
If just user authentication is the goal, then auth-proxy is sufficient. The following table gives a brief comparison of Authentication Proxy and the 802.1x authentication feature.
3.9. Authentication Proxy Vs. 802.1x Comparison
Table 1 shows how authentication proxy and 802.1x protocols compare.
Table 1. Relationship between authentication proxy and 802.1x
For more information about this feature and its configuration on Cisco Virtual Office, refer to the deployment guide "Deploying 802.1x-Based Port Authentication on the Cisco Cisco Virtual Office Solution". All Cisco Virtual Office deployment guides can be found at http://www.cisco.com/go/cvo.
The CPE can be configured following a trusted subnet-nontrusted subnet concept, which achieves the goal of the split tunneling of separating the traffic in a different way. When a user connects a PC, IP Phone, or another type of device to any port of the router, this device associates with the respective interface (trusted or nontrusted). The user is prompted for 802.1x credentials. Upon successful or unsuccessful authentication, a trusted or nontrusted IP address is assigned and routed, respectively.
The IPT is automatically assigned to a voice VLAN as it is discovered using Cisco Discovery Protocol (CDP). The voice VLAN is still router back to the corporate network to reach the Cisco Unified Communications Manager, but it is filter by a access list which only allows the respective voice related traffic for Skinny or Session Initiation Protocol (SIP) to go though.
This is a configuration sample for adding 802.1x to a Cisco Virtual Office spoke:
aaa new-model
!
aaa group server radius dot1x
server-private 10.99.99.2 auth-port 1812 acct-port 1813 key 0 <key>
ip radius source-interface BVI1
!
aaa authentication dot1x default local group dot1x
!
! Enable dot1x feature globally
dot1x system-auth-control
!
interface FastEthernet0
switchport access vlan 10
switchport voice vlan 11
dot1x pae authenticator
dot1x port-control auto
dot1x reauthentication
dot1x guest-vlan 20
spanning-tree portfast
!
interface FastEthernet1
switchport access vlan 10
switchport voice vlan 11
dot1x pae authenticator
dot1x port-control auto
dot1x reauthentication
dot1x guest-vlan 20
spanning-tree portfast
!
interface FastEthernet2
switchport access vlan 10
switchport voice vlan 11
dot1x pae authenticator
dot1x port-control auto
dot1x reauthentication
dot1x guest-vlan 20
spanning-tree portfast
!
interface FastEthernet3
switchport access vlan 10
switchport voice vlan 11
dot1x pae authenticator
dot1x port-control auto
dot1x reauthentication
dot1x guest-vlan 20
spanning-tree portfast
!
ip access-list extended allow_skinny_acl
permit udp any any range bootps bootpc
permit udp any host 206.13.28.12 eq domain
permit udp any host 171.70.147.60 eq tftp
permit udp any host 171.68.196.70 eq tftp
permit tcp any any eq 2000
permit udp any any range 24576 24656
permit udp any any eq 5445
permit udp any any range 2326 2373
!! Permit the ip phones services to go through
permit tcp any host 172.16.147.59 eq www
deny ip any any log
interface vlan 11
description Voice VLAN
ip unnumbered BVI1
ip access-group allow_skinny_acl in
ip inspect fw in
no autostate
3.10. Secure-ARP (in DHCP)
The DHCP Authorized ARP feature enhances the Dynamic Host Configuration Protocol (DHCP) and Address Resolution Protocol (ARP) components of the Cisco IOS Software to limit the leasing of IP addresses to authorized hosts or devices When configured, ARP table entries and their corresponding DHCP leases are secured automatically for all new leases and DHCP bindings. When the lease is renewed, it is treated as a new lease and is secured automatically. If not used, all existing secured ARP table entries automatically change to dynamic ARP entries.
3.11. Network Admission Control
NAC is enabled at the headend side using the Cisco NAC appliance.
Please visit http://cisco.com/go/nac for more information about how to deploy the Cisco NAC appliance.
The Cisco Virtual Office router does not need any additional configuration to allow NAC to function.
3.12. Split Tunneling
The CPE routers can be configured in split-tunneling or non-split-tunneling mode. In split-tunneling mode, only the traffic destined for the corporate network is routed to the VPN tunnel; the remaining traffic is routed directly to the Internet service provider (ISP). In non-split-tunneling mode, all the traffic is routed through the corporate network regardless of the destination.
Split tunneling is controlled by the server side (the DMVPN hub). It can be enabled or disabled at any point in time. It will depend on the routing protocol in use. For non-split-tunnel configuration, the DMVPN hub passes a default route to the spokes.
3.13. Cisco IOS Software-Based PKI Overview and Architecture
The device authorization in Cisco Virtual Office is based on a PKI and AAA framework. Every device is authorized to be part of Cisco Virtual Office infrastructure based on hostname accounts created in the AAA Server. Every device uses a pair of digital certificates to build three encrypted tunnels6, two for data and one for management and digital certificates. The PKI environment serves the purposes of device authorization, PKI rollover, and Secure Device Provisioning. This section includes information about the design and the configuration of the following components of PKI and AAA:
• Certificate Servers
• Multiple Trustpoints
• Certificate Lifetimes and Auto Enroll
• Certificate Rollover
• Backup of the Certificate Server Public and Private Keys
Public Key Infrastructure provides a hierarchical framework for managing the digital security attributes of entities that will be engaging in secured communications. Each participant in a PKI holds a digital certificate that has been issued by a Certificate Authority (CA). The certificate contains numerous attributes that will be used when parties are negotiating a secure connection. These attributes include at least the certificate validity period, end-host identity information, encryption keys that will be used for secure communications, and the signature of the issuing Certificate Authority. Other attributes may be included in the certificate as well, depending on the requirements and capability of the PKI. In general, the PKI infrastructure allows Cisco IT to realize several benefits:
• Simplified management of the security infrastructure through automation
• Increased security through difficulty of compromising certificate-based security
• Improved integration of management for all secured services
• Tighter control of secure access to business resources
In Cisco Virtual Office, Public Key Infrastructure (PKI) is used to validate the identity of the CPE devices in order to authorize the establishment of the IPsec data tunnels with the DG. The CPE and the DG present their certificates to the other party during the ISAKMP negotiation. Before the DG and CPE successfully complete the tunnel negotiation, the routers must confirm that the certificate presented by the specified device is valid. In the Cisco Virtual Office deployment, the CPE devices and the DGs are enrolled in the same certificate servers, simplifying the validation procedure because the routers do not have to query certificate authorities as a part of validation. Also as part of the validation process the DGs are configured to authorize CPE devices using PKI-AAA integration.
3.14. Configuring the Cisco IOS Certificate Server
The first step in PKI deployment is to bring up the Cisco IOS Certificate Server, which is a router running Cisco IOS Software with IP connectivity enabled to reach resources such as Network Time Protocol (NTP), Trivial File Transfer Protocol (TFTP), and Domain Name System (DNS) servers necessary for proper functioning. Cisco IOS Certificate Server must be configured with ip http server to support enrollments done through the Simple Certificate Enrollment Protocol (SCEP). This section describes only configurations relevant to Cisco IOS Certificate Server.
! hostname and domain name form a fully qualified domain name in certificates
ip hostname cvo-pki-cs
ip domain name cisco.com
! clock must be in sync between Cisco IOS Certificate Server and the clients, including timezone !!!
clock timezone PST -8
clock summer-time PDT recurring
ntp server 10.1.1.101
!!! FTP access configuration for storing .crt,.cnm,and .crl files in external FTP server !!!
ip ftp username <user>
ip ftp password <password>
ip host ftpserver 10.1.1.100
!!! To process enrollment requests and issue certificates !!!
ip http server
!!! RSA key pair is generated automatically when enabling Cisco IOS Certificate Server using 1024 bits. Optionally, RSA keys with the rsakeypair name matching the certificate server can be generated manually with different options such as higher modulus,exportable, etc. Keys must be generated with the exportable option to export them for later restoration in case of certificate server failure. However, the user needs to take the utmost care to store keys securely as it would be easy for someone to get access with
the keys. !!!
ect-pki-cs(config)#crypto key generate rsa general-keys label cvo-pki-cs modulus 1024 exportable
!!! The following Cisco IOS Certificate Server configuration uses a complete database that stores separate .crt and .cnm files for each certificate it issues.
In general,router flash memory has less capacity to store all these files; hence, only essential files should be stored in router flash memory, and all other files can be stored on anexternal FTP server. The lifetime values shown here are for illustration purposes only. !!!
!!! pki server name must match rsakeypair name !!!
crypto pki server cvo-pki cs
database level complete
database archive pkcs12 password 0 <password>
!!! Keys can be auto archived !!!
!!! Identification of the PKI server within Cisco CVO !!!
issuer-name cn=ect-pki-cs,ou=ect
! Certificate server automatically grants enrollment requests from router
grant auto
!!! Every 24 hours the crl database is renewed and published !!!
lifetime crl 24
!!! Issued router (client) certificates are valid for 60 days !!!
lifetime certificate 60
!!! Root (certificate server) certificate is valid for 75 days !!!
lifetime ca certificate 75
cdp-url http://10.1.1.100/ect-pki-cs.crl
!!! PKI clients get CRL from this ftp location !!!
database url ftp://10.1.1.100/pki
!!! The following trustpoint configuration is autogenerated when Cisco IOS Certificate server is enabled.
Optionally, this trustpoint configuration can be created manually before enabling Cisco IOS Certificate Server. !!!
!!
crypto pki trustpoint cvo-pki-cs
enrollment url http://ect-pki-cs:80
serial-number
revocation-check crl
!! rsakeypair name must match pki server name !!!
rsakeypair cvo-pki-cs
3.15. PKI Authentication and Authorization Integrated with the AAA
The hub router can be configured to do certificate-revocation-list (CRL) validation for each peer certificate. PKI-AAA authorization is an alternative way to validate the peer certificates. This AAA validation can also work as an additional check along with CRL validation. The router extracts a specified field (usually the router hostname and domain name, which make the Fully Qualified Domain Name (FQDN) of the router) from the peer certificate subject and sends it to a RADIUS server. The FQDN of the router is then sent to the AAA as the authentication username, and the password is fixed as "cisco". Which field should be sent as the username is specified in the trustpoint configuration.
If the RADIUS server has an entry for this username with password set as "cisco", the AAA authentication request will be returned to the head-end router with success along with the following Cisco AV pairs configured for that username:
• Certificate usage (cert-application)
• Certificate trustpoint (cert-trustpoint)
• Serial number (cert-serial)
• Certificate lifetime (cert-lifetime-end)
Following is a sample Cisco AV pair configuration that can be configured on a Cisco Secure Access Control Server (ACS):
cisco-avpair = "pki:cert-application=all"
cisco-avpair = "pki:cert-trustpoint=msca"
cisco-avpair = "pki:cert-serial=16318DB7000100001671"
cisco-avpair = "pki:cert-lifetime-end=1:00 jan 1, 2003"
The RADIUS server returns failure if the record is not found or the password is not "cisco". The peer certificate is not accepted if the RADIUS request fails.
Among these AV pairs only cert-application is mandatory. If this AV pair is not returned or the value of the AV pair is "none", then the certificate is rejected. For the certificate to be accepted, the value of the cert-application should be "all" (more specific key words may be supported in the future; "all" means the certificate can be used for any purpose, including PKI).
If any or both of "cert-trustpoint" and "cert-serial" are specified, the router compares these values with the trust-point name and serial number extracted from the peer certificate. The certificate is accepted only if these fields match.
The "cert-lifetime-end" value can be used to bypass the actual expiry date of the certificate. This action is useful if an expired peer certificate needs to be accepted. A different date can be specified in the AV pair, and the router uses this date for the expiry date calculation.
With the PKI-AAA feature, the hub accepts a certificate only if it has an entry on the RADIUS server. The certificate can be temporarily disabled by setting the "cert-application" value to "none". The simple PKI-AAA configuration follows:
aaa new-model
aaa group server radius pki-aaa-server
secure-server <ip addr> auth-port 1812 acct-port 1813 key 0 <key>
!
aaa authorization network pkiaaa group pki-aaa-server
!
crypto pki trustpoint trustpoint1
enrollment mode ra
enrollment url http://test-ca:80
authorization list pkiaaa
authorization username subjectname commonname
3.16. Certificate Servers
The naming convention of certificate servers is site_code-cvo-pki-certserver#, so in the datacenter in San Jose, California, the device names of the certificate servers are sjc-cvo-access-pki-server1 and sjc-cvo-pki-certserver2. These servers are referred to as PKI-SERVER1 and CERT2. In addition, the SDP Registrar implemented at each DG site is also configured as a PKI server. The SDP Registrar naming convention is site_code-cvo-pki-server2, so in San Jose the SDP registrar is named sjc-cvo-pki-server2.
The SJ PKI-SERVER1 and PKI-SERVER2 servers are configured as certificate authorities for the respective certificate servers in other Cisco Virtual Office security domains, such as RTP or Amsterdam, Hong Kong, and Bangalore. The PKI-SERVER1 and PKI-SERVER2 servers in other security domains are configured in sub-CA mode. Operating the other security domain PKI-SERVER1 and PKI-SERVER2 servers in sub-CA mode is preferred to RA mode. The reason is that the fast enroll process is not available for RA mode, which requires the RA server to request the CA to sing the certificate upon every new request. For clarification, in sub-CA (sub-CS) mode the certificates are issued by the local certificate server, whereas in RA mode, the local certificate server acts as a proxy to the CA certificate server.
The SDP Registrar certificate server in each DG location operates autonomously and is configured as CA.
3.17. Multiple Trustpoints
CPE devices are configured with two trustpoints, and enrolled in two different PKI servers in the security domain. The specific certificate servers that enroll the router depend upon the method used to provision the router. CPE devices provisioned by SDP are enrolled in the SDP Registrar certificate server, as well as in the PKI-SERVER2 server. PKI-SERVER1 is reserved for additional provisions in the future. All DGs are enrolled in the PKI-SERVER2 certificate server. With this arrangement, the certificates issued by PKI-SERVER2 authenticate the data tunnel.
3.17.1. Certificate Lifetimes and Auto Enroll
All CPE devices are configured with 1024-bit RSA keys. Certificates issued to CPE devices from the PKI-SERVER1 and PKI-SERVER2 servers have a lifetime of 1 year. The CPE devices are configured to auto-enroll certificates from these PKI servers after 70 percent of the certificate lifetime has expired. Certificates issued from the SDP Registrar have a lifetime of 3 years. The SDP certificate server is not configured to permit auto-enroll because of concerns it is accessible through the firewall.
3.17.2. Certificate Rollover
CAs-root CAs, subordinate CAs, and RA-mode CAs-like their clients, have certificates and key pairs with expiration dates that need to be reissued when the current certificate and key pair are about to expire. When a root CA certificate and key pair are expiring, it must generate a self-signed rollover certificate and key pair. If a subordinate CA or an RA-mode CA certificate and key pair are expiring, it requests a rollover certificate and key pair from its superior CA, obtaining the new self-signed rollover certificates of the superior CA at the same time. The CA must distribute the new CA rollover certificate and keys to all its peers. This process, called rollover, allows for continuous operation of the network while the CAs and their clients are switching from an expiring CA certificate and key pair to a new CA certificate and key pair.
3.17.3. Backup of the Certificate Server Public and Private Keys
The keys for the PKI certificate servers are exported in the respective certificate server directory in the primary datacenter on Cisco Security Manager host as well as in the respective certificate server directory on the Cisco Security Manager host in the local management subnet.
3.18. PKI Server and CPE Configurations
In order to authenticate and enroll a device with a certificate server, the device must generate its own RSA key pair. Next, a trustpoint must be set on the CPE, which identifies the certificate server in which the router will enroll. Then the CPE must authenticate with the certificate server in order to obtain the CA certificate, and finally enroll in the certificate server to obtain its own device certificate that is issued by the same certificate server.
To generate the RSA key pair on a Cisco router, the conventional method is to run the required command in configuration mode on the router. This method is not employed in the SDP model:
Router-name(config)#crypto key generate rsa
The name for the keys will be: sjc-diacobac-vpn.cisco.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]: 1024 ! To set the number of bits in the key modulus
% Generating 1024 bit RSA keys ...[OK]
In the SDP method the RSA key pair is generated under the trustpoint configuration with the rsakeypair command, which is the next step. Configuring the trustpoint is traditionally basically a matter of pasting the commands in the CPE configuration. In the SDP method, the trustpoint for the certificate server that generates the certificate for authenticating the management tunnel (the SDP Registrar) is configured automatically by the SDP template, will pastes the commands to the router.
The trustpoint configuration requires that the hostname be defined and, to prevent possible DNS problems from affecting the authentication and enrollment processes, the IP address is mapped to the hostname of the certificate server on the router for the enrollment URL.
hostname <site-username-871>
crypto pki trustpoint <site- cvo-pki-server2>
! site reg2 server for management hub; for example sjc-cvo-pki-certserver1
enrollment url http://<site-cvo-pki-server2>:80
! PKI-SERVER1 ! site reg2 server for management hub; for example sjc-cvo-pki-server2
serial-number
revocation-check none
source interface BVI1
! The source interface is not specified until after the initial certificate enrollment. Only used for re-enrollment.
auto-enroll 70
!
The certificates to authenticate the data tunnels are generated by the regional management hub PKI-SERVER2 server. Under the SDP method, the trustpoint commands and the CA certificate for the PKI-SERVER2 server are pasted into the CPE configurations through the SDP template.
crypto pki trustpoint sjc-cvo-pki-certserver2
enrollment url http://sjc-cvo-pki-certserver2:80
serial-number
revocation-check none
source interface BVI1
auto-enroll 70
3.19. PKI Configuration of the Cisco Virtual Office Data Headends and in a High-Concentration Hub Format
The SDGs and SLB hub routers at a Data Hub are enrolled in the respective PKI-SERVER2 certificate server. When a specific SDG or SLB hub router has network connectivity, it is enrolled in the PKI-SERVER2 server by:
• Generating the RSA key pair
• Configuring the PKI-SERVER2 server as a trustpoint on the router
• Authenticating the router with the PKI-SERVER2 server to obtain the CA certificate
• Enrolling the router with the PKI-SERVER2 server to obtain its device certificate
hostname <site- access-sdg#(hub#)> ! # for a respective data hub
!
aaa new-model
!
!
aaa authorization network pkiaaa group radius ! authorization list pkiaaa
radius-server host <IP-address-ACS-server> auth-port 1812 acct-port 1813 key <removed>
! IP address of CISCO IT ACS servers
crypto pki trustpoint <site-cvo-access-cer#>
! hostname of CERT# server at respective Management Hub, for example sjc-cvo-pki-certserver2
enrollment url http:// <site-cvo-pki-certserver#>:80
!hostname of CERT# server at respective Management Hub, for example sjc-cvo-pki-certserver2
serial-number
crl optional
auto-enroll 70
authorization list pkiaaa
! the list pkiaaa forces authorization of CPEs that present root and device certificates issued by the certificate server sjc-cvo-pki-certserver2
!
radius-server host <IP-address-CISCO IT-ACS-server> auth-port 1812 acct-port 1813 key <removed>
The ACSs authenticate the CPE authorizing the negotiation of the IPsec tunnel. The SDG or SLB hub router verifies the certificate offered by the CPE against the configured AAA server (in Cisco Virtual Office these are the local director addresses for the the ACSs). If the device does not have an account on the AAA server that is a member of the group Cisco Virtual Office, then the certificate is rejected. On the ACS, the group Cisco Virtual Office has the reply attribute pki:cert-application=all in the AAA server group profile.
3.20. Configuration of the AAA Server Cisco Virtual Office Group Profile
All Cisco Virtual Office devices need to have a FQDN (Fully Qualified Domain Name) in a AAA and have the Cisco AV-Pair reading its value as shown in Figure 7.
cisco-avpair = "pki:cert-application=all"
Figure 7. PKI-AAA Integration
3.21. PKI Configuration of the SMG
hostname <site-cvo-access-smg1>
! SMG for Management Hub such as sjc-cvo-access-smg1
aaa new-model
aaa authorization network pkiaaa group radius
!
crypto pki trustpoint <site-cvo-pki-certserver1>
! PKI-SERVER1 server for management hub; for example sjc-cvo-pki-certserver1
enrollment mode ra
enrollment url http:// <site-cvo-pki-certserver1>:80
! PKI-SERVER1 server for management hub; for example sjc-cvo-pki-certserver1
!
crypto pki trustpoint <site-cvo-pki-server2>
! SDP Registrar for a DG Hub for example sjc-cvo-pki-server2
enrollment url http:// <site-cvo-pki-server2>:8000
! enrollment is over TCP port 8000
!
crypto pki certificate chain <site-cvo-pki-certserver1>
! PKI-SERVER1 server for management hub; for example sjc-cvo-pki-certserver1
certificate XXXX
! the certificate number is shown in HEX (this number is unique for each CPE enrolled in the same PKI-SERVER1 server)
certificate ca XXXX
! the CA certificate number shown in HEX (this is common for each CPE enrolled in the same PKI-SERVER1 server)
crypto pki certificate chain <site-cvo-pki-server2>
certificate XXXX
! the CA certificate number shown in HEX (this is common for each CPE enrolled in the same SDP Registrar server)
certificate ca XXXX
! the CA certificate number shown in HEX (this is common for each CPE enrolled in the same SDP Registrar server)
radius-server host <IP-address-CISCO IT-ACS-server> auth-port 1812 acct-port 1813 key <removed>
Cisco IT ACS servers authenticate the CPE authorizing the negotiation of the IPsec tunnel. The DG checks the certificate offered by the CPE against the configured AAA server (in Cisco Virtual Office these are the local director addresses for the Cisco IT ACSs). If the device does not have an account on the AAA server that is a member of the group Cisco Virtual Office, then the certificate is rejected. On the ACS, the group Cisco Virtual Office has the reply attribute pki:cert-application=all in the AAA server group profile.
3.22. PKI Configuration of the Certificate Server
Before configuring the certificate server function on the Cisco IOS Software-based certificate server, there must be network connectivity between the certificate server and the storage location for the certificates. In Cisco Virtual Office we use the Management Hub CNS tftpboot/<IP-address-cer#> such as tftpboot/sjc-cvo-access-pki-server1 directory and ensure that the certificate server has write access to this directory. Without write access the certificate server canno start and maintain operations.
hostname <site-cvo-pki-certserver#>
! CERT# server for management hub; for example sjc-cvo-pki-certserver1
!
crypto pki server <site-cvo-pki-certserver#>
! PKI Server configuration for certificate server, for example sjc-cvo-pki-certserver1
database level complete
! specifies that each certificate includes the most complete information available so that: the new certificates can be issued without conflict, the serial number and subject name of each certificate is stored in the certificate, and each certificate is written to a database
database url tftp://<IP-address-ISC1>/<site-cvo-pki-certserver#>
! Directory location where the certificates are saved via TFTP (in CVO it is the tftpboot directory on the CSM server
grant auto
! automatically grants certificate upon initial and renewal requests
mode sub-cs
The standalone certificate servers (not including the SDP registrars) are operated as sub-CS (subordinate Certificate Server) mode except San Jose Certificate servers that are the root certificate servers for each respective group of servers. For example, sjc-cvo-access-pki-server1 is the root certificate server for all PKI-SERVER1 certificate servers, and sjc-cvo-access-pki-server2 is the root certificate server for all PKI-SERVER2 servers.
When the no shut command is issued on the crypto pki server SDP server, the pki server tries to write its CA certificate to the database URL. Failure to write this data causes the PKI server startup to fail and the server to shut down. The following commands will appear in the router configuration after the command; the no shut command is issued under the pki server on the SDP when the PKI server is successfully started.
crypto pki trustpoint <site-cvo-pki-certserver#>
!The PKI server reasserts itself as the certificate server
revocation-check crl
! though configured not actively being used for now
rsakeypair <site-cvo-pki-certserver#>
! automatically enrolls the IOS-based certificate server in the certificate server configured on the same device
crypto pki trustpoint SDPhttps
! SDPhttps is the label for a trustpoint, which obtains a device certificate from the PKI server SDPserver
enrollment url http:// <site-building-cvo-pki-certserver#>:80
! Specifies the URL of the certificate authority on which your router should send certificate requests
serial-number none
! do not use the serial number in the certificate
fqdn none
! do not use the fully qualified domain name in the certificate request
ip-address none
! do not use the IP address in the certificate request
subject-name CN=<site-cvo-pki-certserver#.cisco.com>
This command specifies the requested subject name that is used in the certificate request. If the x-500-name argument is not specified, the FQDN, which is the default subject name, is used. In the Cisco Virtual Office certificate servers, it is the certificate server hostname, such as sjc-cvo-pki-certserver1.
crypto pki certificate chain <site-cvo-pki-certserver#>
certificate ca XX
! the certificate server will authenticate with itself and maintain the CA certificate
certificate XX
! this is the device certificate issued by the certificate server
crypto pki certificate chain SDPhttps
certificateXX
! this is the device certificate issued to by the SDP Registrar
certificate ca XX
! this is the same CA certificate as listed under the chain SDPserver
3.23. PKI Configuration of the SDP Registrar PKI Server
The naming convention used for the PKI server configured on the SDP Registrar at each data hub is consistently named SDPserver.
crypto pki server <site-cvo-pki-server2>
! specifies the name of the PKI server and contains its configuration information
database level complete
! specifies that each certificate includes the most complete information available so that: the new certificates can be issued without conflict, the serial number and subject name of each certificate is stored in the certificate, and each certificate is written to a database
database url tftp://<DNS-name-CNS>/<site-cvo-pki-server2>
! Directory location where the certificates are saved via TFTP (in CVO it is the tftpboot directory on the CSM server)
no shut
! When the no shut command is issued on the crypto pki server SDPserver, the pki server will try to write its CA certificate to the database URL. Failure to write this data, will cause the PKI server startup to fail and to shut down. The following commands will appear in the router configuration after the command, no shut is issued under the pki server SDPserver when the pki server is successfully started.
crypto pki trustpoint < site-cvo-pki-server2> ! the trustpoint specifies info related to the certificate server that the router will enroll-in this case the SDP Registrar is enrolling with itself
revocation-check crl
! CRL checking is not employed so this command is ignored
rsakeypair <site-cvo-pki-server2>
! Auto-enrolls the trustpoint in the certificate server
!
crypto pki trustpoint <hub_name-ezsddhttp>
! hub_name-ezsddhttp is the label for a trustpoint, which obtains a device certificate from the PKI server SDPserver
enrollment url http:// <site-cvo-pki-server2>:18000
! Specifies the URL of the certificate authority on which your router should send certificate requests; in CVO TCP port 18000 is selected instead of using port 80 to address security concerns of using port 80 on a device behind the FW with a hole to permit traffic on port 80
serial-number none
! do not use the serial number in the certificate
fqdn none ! do not use the fully qualified domain name in the certificate request
ip-address none
! do not use the IP address in the certificate request
subject-name CN=<site-cvo-pki-server2>.cisco.com !
revocation-check crl
! a CRL does not exist and this command is ignored
!
3.24. Cisco IOS Stateful Firewall
The spoke router and the network behind the spoke should be considered as part of the corporate network, so an attempt should be made to provide the same level of security as for the corporate firewall.
An access list is configured on the outside interface (which is connected to the ISP network) such that no traffic initiated from outside (Internet) is permitted into the network. Only VPN traffic and some basic traffic such as ICMP, DHCP, NTP, and so on are permitted into the router.
PAT is configured on the outside interface such that all traffic originated from inside the network to the Internet is translated into a single public IP address. PAT is configured so that multiple devices behind the router can share the same IP address assigned by the ISP.
IP inspection (context-based access control, or Cisco IOS Stateful Firewall) is configured on the inside interface. When traffic is originated from inside toward the public network, Cisco IOS Stateful Firewall selectively opens holes in the firewall ACL for the return traffic.
Cisco IOS Stateful Firewall and PAT are needed on the spoke router only if split tunneling is allowed. Otherwise all traffic is directed through the corporate network. No firewall or address translation is configured between the corporate network and the home network (which is the tunnel interface).
3.24.1. Stateful Firewall Configuration
ip inspect name fw tcp
ip inspect name fw udp
ip inspect name fw realaudio
ip inspect name fw rtsp
ip inspect name fw tftp
ip inspect name fw ftp
ip inspect name fw h323
ip inspect name fw smtp
ip inspect name fw skinny
ip inspect name fw sip
!
interface BVI1
description inside interface-Secure network with corporate access
ip address 10.10.100.1 255.255.255.240
ip nat inside
ip inspect fw in
!
interface BVI2
description inside interface-Gust network without corporate access
ip address 10.10.200.1 255.255.255.240
ip nat inside
ip inspect fw in
!
interface FastEthernet4
description outside interface
ip address dhcp
ip access-group fw_acl in
ip nat outside
!
ip nat inside source list nat_acl interface Fastethernet4 overload
ip access-list extended nat_acl
permit ip 10.100.100.0 0.0.0.15 any
permit ip 10.100.200.0 0.0.0.15 any
!
3.24.2. Firewall Diagnostics
3.25. CPE Intrusion Prevention System
An Intrusion Prevention System (IPS) alerts the network administrator about the attacks happening to the network in real time. The traffic is inspected for known signatures, and if any are detected, alerts are generated. Alerts can be captured on a syslog server or a management tool with the appropriate support. Apart from detecting an attack, it can also block many of the attacks.
IPS is configured globally on the router and then applied on the necessary interfaces. The traffic can be inspected in any direction that is configurable.
Cisco IOS Software has built-in signatures that are loaded by default. The loaded signatures can be overwritten or appended. Cisco IOS Software can load the signatures from a Cisco IOS Software file system or a published site that can be accessed from a URL (using FTP, TFTP, HTTP, and so on). Automatic updates are possible by either setting a Cisco IOS Software Kron job or using a management tool that supports pushing signatures to Cisco IOS Software routers.
Note: Older versions of Cisco IOS IPS are not compatible with Cisco IOS Software Release 12.4(15)T and later. When upgrading to 12.4(15)T or later, the old Cisco IOS Software configuration needs to be removed and replaced with the new configuration. The signature format is also different in IPS 5.0.
IPS is enabled with four basic steps.
Step 1. Download the latest signature file and public key file from Cisco.com and host the signature file in a local TFTP server. The public key needs to be set up only once. The signature file can be updated as and when new signature files appear on Cisco.com. A valid Cisco.com account is needed to download the files.
• Signature files location: http://www.cisco.com/pcgi-bin/tablebuild.pl/ios-v5sigup
• Signature File: IOS-Sxxx-CLI.pkg, where xxx is the release number. Pick the latest release.
• Public Key File: realm-cisco.pub.key.txt
Step 2. Create a directory on the router flash memory to save the IPS signatures.
• At the enable prompt type "cd flash:/" and press <RETURN> key. The dir command can be used to check the current directory. (On some Cisco IOS Software platforms primary disk space may not be called "flash". In that case use the appropriate the disk name.)
• Execute mkdir ipsstore at the enable prompt. A directory named "ipsstore" is created now. Use the dir command to verify.
myrouter#cd flash:/
myrouter#
myrouter#mkdir ipsstore
Create directory filename [ipsstore]?
Created dir flash:ipsstore
myrouter#
myrouter#dir
Directory of flash:/
2 -rwx 18850232 Dec 12 2007 20:39:48 -08:00 c870-advipservicesk9-mz.124-15.T1
3 drwx 384 Dec 21 2007 18:15:55 -08:00 ipsstore
52383744 bytes total (9826304 bytes free)
myrouter#
Step 3. Configure the Cisco IOS IPS Crypto Public Key.
At the enable prompt, go to the configuration mode by executing config terminal. At the configuration prompt, copy and paste the contents of the file "realm-cisco.pub.key.txt", which was downloaded at Step 1. This step configures the IPS public key on the router. Save the router configuration.
myrouter#config terminal
Enter configuration commands, one per line. End with CNTL/Z.
myrouter(config)#crypto key pubkey-chain rsa
myrouter(config-pubkey-chain)# named-key realm-cisco.pub signature
Translating "realm-cisco.pub"...domain server (172.16.226.120)
myrouter(config-pubkey-key)# key-string
Enter a public key as a hexidecimal number ....
myrouter(config-pubkey)#$2A864886 F70D0101 01050003 82010F00 3082010A 02820101
<lines deleted>
myrouter(config-pubkey)# F3020301 0001
myrouter(config-pubkey)# quit
myrouter(config-pubkey-key)# exit
myrouter(config-pubkey-chain)# exit
myrouter(config)#end
myrouter#
Step 4. Configure Cisco IOS IPS on the router.
The following configuration enables IPS on the router. The example enables the basic signature category and specifies the mitigation action for the detected signatures. There are many signature categories apart from "all" and "basic". Users can enable any of those categories individually. The all command enables the entire signature set, which may affect performance on low-end platforms such as the Cisco 870.
! Create the IPS rule name.
ip ips name ips5
! Configure the signature storage location
ip ips config location flash:ipsstore
! Configure the report notification method. SDEE or log (for syslog)
! are supported.
ip ips notify SDEE
! Enable the basic signature set.
ip ips signature-category
category all
! Disable the full signature category.
retired true
category ios_ips basic
! Enable the "basic" category.
retired false
! Configure TCP reset and traffic blocking as the mitigation
! actions for this category.
event-action reset-tcp-connection deny-packet-inline
!
! Enable the IPS policy on the desired interfaces. On CVO spoke
! router IPS is enabled on the traffic from home network to
! corporate network. It can also be enabled on other interfaces
! to inspect more traffic.
!
interface BVI1
! Enable IPS on incoming traffic.
ip ips ips5 in
end
! Save the configuration by doing "write mem".
Load the signatures to the router. This step is done at the enable prompt. It is done as and when a new signature set is available to be loaded.
myrouter# copy tftp://<ip address of tftp server>/IOS-S312-CLI.pkg idconf
Loading stealth/IOS-S312-CLI.pkg from <ip address> (via Tunnel13): !!OO!!!!!!!!!!!!!!!O!!!!!!!!!!!!!!
[OK-7686949 bytes]
Refer to the "Cisco IOS Software IPS resource page", which describes IPS 5.0 deployment in more detail.
3.25.1. Setting a Kron Job to Load Signatures Periodically
This is used if the signature is periodically downloaded from Cisco.com and saved in a fixed TFTP location and with the same name. In the below example, the signature is loaded once in every week.
kron occurrence one at 12:00 recurring
policy-list one
!
kron policy-list one
cli copy copy tftp://<ip address of tftp server>/<package name> idconf
3.25.2. IPS Diagnostics
4. Cisco Virtual Office End-to-End Connectivity Design and Configuration
The end-to-end connectivity in the Cisco Virtual Office will be based on the latest developments of the DMPVN Phase 3, where the technology allows the headend to support Server Load Balancing (SLB) and includes QoS enhancements for CPE-to-CPE connectivity and for marking and queuing the outbound (from the point of view of the hub) traffic. The SLB design provides better scalability among all existing design solutions of DMVPN, provides full-mesh and partial-mesh architectures, provides better redundancy, and has no known limitations in terms of the maximum number of users.
4.1. Dynamic Multipoint VPN and Server Load Balancing
The traditional site-to-site VPN solutions are based on RFC 24017. They are typically configured with cryptography maps applied to the physical interfaces and require configuration of both ends of the connection in order to define the interesting traffic and the peer-to-peer routing. Cisco IOS DMVPN8,9 is taking the VPN one step further by incorporating Cisco routing protocols framework into the IPsec VPN framework. It transforms the secure peer-to-peer model into an end-to-end VPN model and delivers effective networking and security integration. From a design prospective, DMVPN offers great flexibility, allows dynamic multipoint Hub-to-Spoke and virtual full-mesh architectures. (Note that large full-mesh architectures can be expensive and difficult to manage in TDM and Frame Relay environments.) From a deployment prospective, DMVPN simplifies the burden of headend management and thus significantly reduces the TCO.
In hub-to-spoke designs, all the data traffic terminates to a redundant but central location, even if two users' routers have to communicate with each other. Every router is configured with 3 cryptography tunnels. One of the tunnels is called the management tunnel, which terminates on a SMG, and it is designated for management data, control data, image upgrades, collecting logs, and monitoring and auditing the end user's device. The standard DMPVN design supports two data tunnels per remote router, which terminate on SDGs. Both data tunnels are active, allowing the terminating equipment to perform an active failover when any of the end user's tunnels fail. From the user's perspective there is less then 10 seconds of service interruption when the primary tunnel fails, and no interruption when the secondary tunnel fails because the primary tunnel takes over if it is up.
As stated earlier, DMPVN is a VPN solution that incorporates Cisco routing protocols into the IPsec VPN framework. As a technology solution, DMVPN comprises the IP Security (IPsec), Next Hop Resolution Protocol (NHRP), and multipoint generic routing encapsulation (mGRE)10 protocols. The detailed technical descriptions of IPsec, NHRP, and GRE and details about the Cisco IT implementation can be found in Appendix A.
The end-to-end connectivity in the Cisco Virtual Office is enhanced based on the latest developments of the DMPVN Phase 3, where the technology allows the headend to be deployed based on a new design, called Server Load Balancing11 (SLB). Server Load Balancing is based on a server-farm design and provides the DMVPN functions based on two different designs:
Design One
• IPsec Termination: Typically the Cisco 6500 Cisco Catalyst® 6500 Switch acts like a primary tunnel termination Hub and performs encryption and decryption functions, effectively becoming an IPsec Termination device.
• NHRP and mGRE Servers: A farm of Cisco 7200 Series Routers is associated with the IPsec termination device and handles all tasks related to Next-Hop Resolution Protocol (NHRP) and multipoint generic routing encapsulation (MGRE).
Design Two
• The front device: Typically a Cisco 7200 or Cisco 6500 Series Router performs the role of Load Balancer.
• IPsec, NHRP, mGRE, and Routing Servers: A farm of Cisco 7200 Series Routers is associated with the load balancer and handles all the tasks related to Next-Hop Resolution Protocol (NHRP) and multipoint generic routing encapsulation (MGRE) and IPsec encryption and decryption.
Figure 8. DMVPN SLB Design
Both design solutions have their advantages and disadvantages; based on the existing documentation and lessons learned, the SLB design provides the following advanced enhancements for DMVPN:
• The encryption decryption is an expensive operation. Even though the Cisco 7200 is a faster processor than the Multilayer Switch Feature Card (MSFC), encryption and decryption can slow it down considerably. By taking the burden of encryption and decryption off of the Cisco 7200 Series Router, SLB allows the Cisco 7200 to perform slightly better in routing protocol and NHRP handling.
• Secondly, the early phases of the DMPVN and Cisco IOS Software Release 12.4(15)T use the VSA. The Cisco 7200VXRs farm servers have to be equipped with VSA encryption modules because the IPsec encryption and decryption is done on the farm servers.
• To increase the scalability of routing protocols, hubs can be configured in daisy chains. The traffic between hubs is configured to traverse a back-end LAN for added bandwidth.
In one of the early tested implementations, the Cisco 6500 Series Service Selection Gateway is configured with IPsec and server-load-balancer (SLB) configuration12 to balance GRE traffic to the Cisco 7301 Routers. The Cisco 6500 is configured with a dynamic cryptography configuration to accept any spoke with any proxies. When using tunnel protection on spokes, these proxies are automatically set to match GRE traffic. The public IP address of the Cisco 6500 is configured as the loopback interfaces on the Cisco 7301 Series Router and as the virtual address for load-balancing purposes. These loopbacks on Cisco 7301 Routers are used to source GRE traffic. On the Cisco 6500, after decryption the GRE packet is exposed and is load balanced using the SLB configuration. The Cisco 7301 terminating a GRE session picks up the packet and performs the necessary operation.
From A management perspective, Cisco Security Manager 3.1 supports the DMPVN with SLB design, where Cisco Security Manager allows a separate IPSec termination device and set of Data Gateways (part of the Hub farm) to be defined. The deployment and management advantages of THE SLB design over the existing (called "standard DMVPN design") follow:
• SLB is much easier to configure and support because the configuration of the peer tunnel IP is always the same no matter how large the deployment. The peer IPsec IP (the termination-device tunnel IP) acts like a cluster IP and does not change because of design or scalability considerations.
• SLB scales higher because the EIGRP-based scalability restrictions are mitigated and the number of tunnels is virtually limitless.
• SLB provides a higher tunnel-creation rate, recovers faster when the cluster node dies, and provides spoke-to-spoke functions as the standard DMVPN does.
• SLB provides better redundancy. The existing design provides redundancy in pairs-the dual-tunnel, single layout design (from CPE) perspective actually terminates the CPE to two separate SDGs, maintaining active-active status of the cryptography tunnel connections. In that case, the number of the primary hubs is actually equal to the number of the backup hubs, and the total number is 2N. Everything equal, if we assume the same number of CPE devices per Hub (pair of hubs), the number of Hubs in the SLB design should be N+1.
Each CPE device is configured with a separate, plain IPsec management tunnel and one or two DMVPN-based IPsec data tunnels, depending on the DG architecture at the respective hub. The tunnels terminate on a SMG and one or two DGs at a corporate site with an Internet POP. There are two types of DG architectures: the SLB and hub router architecture and the primary or failover SDG architecture. The SLB and hub router architecture is deployed to sites with large-scale CPE devices, and the primary or failover SDG architecture is deployed to smaller-scale hubs. The SMG for a specific CPE does not have to be located at the same corporate site as the DGs. All CPE devices run EIGRP in Autonomous System (AS 109) Failover for CPE devices between hub routers in the primary or failover SDG architecture is controlled by the EIGRP routing process. CPE devices that loose connectivity with a hub router in the SLB and hub router architecture negotiate a new tunnel with a potentially different hub router if the stickyness timer on the SLB router expires.
4.2. Plain IPsec-Based Management Tunnel
A plain IPsec tunnel is established between the CPE and the SMG. On the CPE, the management tunnel is implemented using a static cryptography map configured so that CPE devices must initiate the negotiation for establishing the IPsec tunnel. The SMG is configured with a dynamic cryptography map. Cisco Networking Services traffic from the CPE devices destined to the management subnet should initiate the ISAKMP negotiation between the CPE and the SMG, leading to the establishment of an IPsec tunnel between the two devices and providing connectivity for the SMG, ISC, Cisco Security Manager, CE, and certificate servers.
Certificates issued by the trustpoints of the certificate server 1 in each management hub are used to authenticate the appropriate CPE management tunnel. For CPE devices configured with SDP, the management tunnel is authorized using the SDP Registrar trustpoint.
This plain IPsec tunnel is configured to use tunnel mode, AES 256 data encryption, and the SHA for message authentication. IKE parameters are negotiated using AES 256 encryption with all other parameters set at default, including hash (SHA), group (768-bit Diffie-Hellman), and lifetime (86,400 seconds = 1 day).
4.2.1. Cisco 871 Management Tunnel Configuration
crypto isakmp policy 10
! Defines IKE policy and sets it to the highest priority
encr aes 256
! Sets encryption to aes 256 for IKE negotiation
crypto isakmp keepalive 15 5
! Default-Number of seconds between DPD messages
crypto isakmp nat keepalive 10
! Default-Number of seconds between NAT keepalives, which are sent if IPSec does not send or receive a packet within a specified period.
!
crypto ipsec transform-set t1 esp-aes 256 esp-sha-hmac
!
crypto map CSM_CME 1 ipsec-isakmp
description Management Tunnel-SMG
set peer < IP address of loopback interface of SMG>
set security-association lifetime kilobytes 530000000
set security-association lifetime seconds 39600
set transform-set t1
! transform-set t1 to be used for IPSec encryption for management tunnel
match address smg_acl
! traffic that should trigger crypto-map
interface FastEthernet4
crypto map CSM_CME
!
ip access-list extended smg_acl
! ACL that is matched to established management tunnel
permit ip host <ip address of CPE BVI1 interface> <management hub subnet> <wildcard mask for management hub subnet>
Only traffic sourced from a trusted port of the CPE Cisco 871 Router can initiate and traverse the management tunnel.
4.2.2. SMG Configuration
crypto isakmp policy 1
encr aes 256
crypto isakmp keepalive 45 5
! 45 seconds between maximum of 5 DPD retries
!
crypto ipsec transform-set t1 esp-aes 256 esp-sha-hmac
!
crypto dynamic-map dmap 10
! dynamic crypto map "dmap"
set transform-set t1
!
crypto map ibv local-address Loopback0
! specifies IP address of Loopback 0 to be used with the crypto map "ibv"
crypto map ibv 1 ipsec-isakmp dynamic dmap
! the first sequence of the ibv crypto map should negotiate IPSEC parameters using ISAKMP as a dynamic crypto map dmap
!
interface Loopback0
ip address <SMG routable loopback interface ip address> 255.255.255.255
interface Vlan101
crypto map ibv
4.3. DMVPN-Based Data Tunnels
DMVPN uses the concepts of "IPsec Profiles" and "Tunnel Protection" that are applied to the tunnel interface instead of the physical interface. ACLs do not have to be defined for the tunnel configuration. An important advantage of DMVPN is that in a plain IPsec environment, removing a cryptograhy map from the physical interface or modifying the access lists carries the risk of losing connectivity with the remote CPE. In a DMVPN environment, cryptography maps or IPsec policies are not applied to the physical interface. As a result, it becomes easier to manage the network because changes of policy can be performed while minimizing the risk of connectivity loss.
The SDGs and SLB hub routers use the dynamic property of NHRP to allow all of the DMVPN CPE devices to register with it. The CPE joins the NHRP domain or database transparently and establishes an IPsec SA with the SDG or SLB hub router, without any modification to the SDG or SLB hub router DMVPN Tunnel configuration. This dynamic NHRP mapping is similar in function to the "dynamic crypto map" feature in plain IPsec.
Similar to the plain IPsec Management VPN tunnel, the DMVPN-Based IPsec Data tunnels are configured using AES 256 encryption, with SHA the preferred hash. IKE parameters are also negotiated using AES 256 encryption, with all other parameters set at default, including hash (SHA), group (768-bit Diffie-Hellman), and lifetime (86,400 seconds = 1 day). However, IPsec transport mode is implemented for the data VPN tunnels in order to permit users to install their CPE in a PAT environment13. Because the data is first encrypted in GRE prior to the IPsec encryption, the IP address of the true endpoints is not revealed in the IP header. As a result no additional security risk is incurred by implementing transport vs. tunnel mode The SDGs and SLB hub routers are configured with the PKI-AAA integration to authorize the data tunnels using the certificate server 2 in each management hub (sjc-cvo-pki-certserver2, ams-cvo-pki-certserver2, rtp-cvo-pki-certserver2, hk-cvo-access-pki-server2, and bgl-cvo-pki-certserver2).
4.3.1. mGRE Tunnel Interface
Because it uses multilink mode of GRE, DMVPN requires one tunnel definition on the SDGs, SLB hub routers, and the CPE device(s). As a result, a single multilink GRE interface supports multiple IPsec tunnels and simplifies the size and complexity of the configuration on the SDGs, SLB hub routers, and CPE devices. All of the EIGRP neighbors across all of the mGRE interfaces can be configured in the same EIGRP AS. However, the number of CPE devices that can connect to a specific SDG or SLB hub router is limited to the maximum number of neighbors EIGRP can accommodate, which is estimated to be around 800-1000 routers.
The SDG hubs are limited by EIGRP, whereas the SLB hub router hubs are limited by the mGRE interface subnet size. As a result, the subnets were deliberately sized to accommodate growth in the service. If capacity is constrained at an SDG hub, either a new SDG pair can be added or a new SLB hub can be implemented.
For a specific mGRE instance, the CPE and SDGs or SLB hub routers are configured with a tunnel interface in the same subnet and mask. In Cisco Virtual Office, nonroutable address blocks are assigned to the tunnel subnets.
The Cisco 7206VXR Router has to be upgraded or deployed with the Cisco 7200 Series NPE-G2 Network Processing Engine and VSAs for the SDGs and SLB hub routers, increasing throughput and multicast capacity; however, multicast will continue to be disabled by default on all CPE devices. Clients can request multicast service by opening a case with the GTRC.
4.3.2. NHRP
NHRP is a client-server protocol in which the hub is the server and the CPE devices are the clients. The hub maintains an NHRP database of the public interface addresses of each CPE device. Each client registers its public IP address with the server after establishing the IPsec tunnel, and could be configured to query the NHRP database for public IP addresses of the destination CPE devices in order to build direct tunnels between the CPE devices. Note that the SLB hub router architecture does not accommodate spoke-to-spoke tunnels because spokes cannot be configured for mGRE encapsulation for the tunnel interface. By default, the interesting traffic for NHRP is all non-NHRP packets, and this traffic initiates NHRP packets so a client will try to join the NHRP fabric upon startup.
4.3.3. DMVPN Configurations
The CPE GRE tunnel interface is preconfigured with information about the SDGs and SLB hub routers using NHRP commands.
4.3.4. CPE DMVPN Configuration with SDG Architecture
crypto ipsec transform-set t1 esp-aes 256 esp-sha-hmac
crypto ipsec transform-set CSM_TS_1 esp-aes 256 esp-sha-hmac
mode transport
! Transport mode is required to accommodate CPEs operating in a PAT environment where multiple CPEs may be assigned the same IP address on the Ethernet 1 (Public) interface.
crypto ipsec profile CSM_IPSEC_PROFILE1
! An IPSec profile abstracts the IPSec policy settings into a single profile that can be used in other parts of IOS configuration.
set security-association lifetime kilobytes 530000000
set security-association lifetime seconds 39600
set transform-set CSM_TS_1
interface Tunnel0
description Provisioned by CSM: Peer location = AMS-office device = ams-cvo-access-DG1
bandwidth 2000
ip address <ip-address-mGRE-tunnel-interface> <subnet-mask-mGRE-tunnel-interface>
! the mGRE tunnel interface on the CPEs and the associated mGRE tunnel interface on the DG's are on the same IP subnet.
no ip redirects
ip mtu 1400
ip nhrp map <primary-SDG-mGRE-tunnel-interface-IP-address> <primary-SDG -routable-loopback-interface-IP-address>
! Statically maps routable IP address of Primary SDG to the Primary SDG Tunnel (mGRE) Interface IP address for NHRP.
ip nhrp map multicast <primary-SDG -routable-loopback-interface-IP-address>
! Configures the primary SDG as a destination for broadcast and multicast packets sent over the mGRE tunnel interface.
ip nhrp map <failover-SDG-mGRE-tunnel-interface-IP-address> <failover-SDG-routable-loopback-interface-IP-address>
! Statically maps routable IP address of the failover SDG to the ip address of the failover SDG tunnel (mGRE) interface.
ip nhrp map multicast <failover SDG-routable-loopback-interface-IP-address> ! Configures the failover SDG as a destination for broadcast or multicast packets sent over the mGRE tunnel interface.
ip nhrp network-id <network-identifier>
! Enables NHRP on this interface. All CPEs and backup hub routers in the same logical NHRP fabric must use the same network identifier. For CVO the same network identifier on the same interface on each router comprising a an SDG primary/failover pair is maintained.
ip nhrp holdtime 500
! Specifies how many seconds the NHRP clients should maintain the addresses provided in NHRP responses.
ip nhrp nhs <IP address of mGRE interface of Primary SDG or hub router>
! IP Address of Primary SDG mGRE Interface IP address.
ip nhrp nhs <IP address of mGRE interface of Failover SDG>
! IP Address of Failover SDG mGRE Interface IP address.
ip nhrp server-only
! CPE cannot initiate NHRP requests or set up NHRP shortcut SVCs but can only respond to NHRP requests.
ip nhrp registration no-unique
! If a CPE receives a new IP address, NHS can override the old registration information
qos pre-classify
! Allows CPE to classify traffic before encryption
tunnel source FastEthernet4
! FastEthernet4 is the WAN interface of the 871 router
tunnel mode gre multipoint
! Enables GRE tunneling in multipoint fashion by specifying mGRE as the encapsulation mode for the tunnel interface. The mGRE interface with all its CPEs and SDGs forms an NBMA network.
tunnel key <removed>
! Must match the tunnel key identifier on the hub to differentiate the traffic for each mGRE interface (DMVPN instance)
tunnel protection ipsec profile CSM_IPSEC_PROFILE_1
! Associates the GRE interface with the IPSec profile CSM_IPSEC_PROFILE_1. It specifies that the IPSec encryption will be completed after the GRE encapsulation has been added to the packet
ip hello-interval eigrp 109 30
ip hold-time eigrp 109 90
4.3.5. CPE Configuration in a SLB Hub Router Architecture
crypto ipsec transform-set t1 esp-aes 256 esp-sha-hmac
crypto ipsec transform-set CSM_TS_1 esp-aes 256 esp-sha-hmac
mode transport
! Transport mode is required to accommodate CPEs operating in a PAT environment where multiple CPEs may be assigned the same IP address on the Ethernet 1 Public interface.
crypto ipsec fragmentation after-encryption
crypto ipsec profile CSM_IPSEC_PROFILE_1
! An IPSec profile abstracts the IPSec policy settings into a single profile that can be used in other parts of the IOS configuration.
set security-association lifetime kilobytes 530000000
set security-association lifetime seconds 39600
set transform-set CSM_TS_1
description Provisioned by CSM: Peer location = AMS-office device = ams-cvo-access-DG1
bandwidth 2000
ip address <ip-address-mGRE-tunnel-interface> <subnet-mask-mGRE-tunnel-interface>
! The mGRE tunnel interface on the CPEs and the associated mGRE tunnel interface on the hub routers are on the same IP subnet.
no ip redirects
ip mtu 1400
ip nhrp map <primary-SDG-mGRE-tunnel-interface-IP-address> <primary-SDG -routable-loopback-interface-IP-address>
! Statically maps routable IP address of Primary SDG to the Primary SDG Tunnel (mGRE) Interface IP address for NHRP.
ip nhrp map multicast <SLB-hub-router-routable-loopback-interface-IP-address>
! Configures the SLB hub router as a destination for broadcast and multicast packets sent over the mGRE tunnel interface.
ip nhrp network-id <network-identifier>
! Enables NHRP on this interface. All CPEs and SLB hub routers in the same logical NHRP fabric must use the same network identifier. For CVO all SLB hub router mGRE interfaces will start with 9x01 (see Table-XY) for the first mGRE interface and increment by one when starting the next mGRE interface.
ip nhrp holdtime 500! Specifies how many seconds the NHRP clients should maintain the addresses provided in NHRP responses.
ip nhrp nhs <IP address of mGRE interface of the SLB hub router>
! IP Address of Primary SDG mGRE Interface IP address.
ip nhrp server-only
! CPE cannot initiate NHRP requests or set up NHRP shortcut SVCs but can only respond to NHRP requests.
ip nhrp registration no-unique
! If a CPE receives a new IP address, NHS can override the old registration information
qos pre-classify
! Allows CPE to classify traffic before encryption
tunnel source FastEthernet4
! FastEthernet4 is the WAN interface of the 871 router
tunnel key <removed>
! Must match the tunnel key identifier on the hub to differentiate the traffic for each mGRE interface (DMVPN instance). All SLB hubs will use 9x09 for the tunnel key and nhrp
tunnel protection ipsec profile CSM_IPSEC_PROFILE_1
! Associates the GRE interface with the IPSec profile CSM_IPSEC_PROFILE_1. It specifies that the IPSec encryption will be completed after the GRE encapsulation has been added to the packet
ip hello-interval eigrp 109 30
ip hold-time eigrp 109 90
ip nhrp redirtect
ip nhrp shortcut
!! Allows CPE to establish spoke-to-spoke tunnels if permitted by DMVPN SLB hubs. CPE can query the NHRP hub and connection requests are then redirected by the hub to the other spoke. Not available until 12.4(6)T. Hub DMVPN interfaces require "ip nhrp redirect" for this feature to work.
4.3.6. DVMPN Hub Configuration
crypto isakmp policy 1
encr aes 256
crypto isakmp keepalive 45 5
crypto ipsec transform-set t1 esp-aes 256 esp-sha-hmac
mode transport require
crypto ipsec transform-set t2 esp-aes 256 esp-sha-hmac
!
crypto ipsec profile cvo-profile-1
set transform-set t1 t2
!Only the loopback 1 interface on the SDG is accessible from the Internet, with holes in the corporate FW for ESP, ISAMKP and UDP port 4500 (NAT-T).
interface Loopback0
ip address <routable IP address of loopback interface of SDG> 255.255.255.255
interface Tunnel <Tunnel-interface-number>
! mGRE Tunnel Interface, initial number is 10, next is 20, and currently cannot exceed 800-1000 CPEs per SDG.
description DMVPN w/o ST
bandwidth 10000
ip address <IP-address-tunnel-interface> <subnet-mask-tunnel-interface>
! Subnet for tunnel interfaces on both SDG's and all CPEs in DMVPN cloud. For most cases the mask will be a /23 as the number of CPEs per mGRE interface is limited to about 600.
no ip redirects
ip mtu 1400
ip hello-interval eigrp 109 30
ip hold-time eigrp 109 90
no ip next-hop-self eigrp 109 ! Normally the eigrp process advertises itself as the next hop unless this command is specified-however required only if spoke-to-spoke tunnels are implemented.
ip pim nbma-mode ! PIM configured for NBMA mode for the mGRE interface
ip pim sparse-dense-mode
ip multicast rate-limit out 768
ip nhrp map multicast dynamic
! NHRP will automatically create a broadcast/multicast mapping for CPEs when they register with the NHRP server
ip nhrp network-id 9x01 ! as specified for the specific SDG and tunnel interface
ip nhrp holdtime 500
ip nhrp server-only
! Prevents the hub from initiating and NHRP requests, as a result, the hub can only respond to NHRP requests
ip nhrp cache non-authoritative
! turns off default behavior on the SDG when it receives authoritative NHRP requests from NHRP clients for other NHRP clients it will forward to the appropriate client.
ip tcp adjust-mss 1360
! Defines the maximum amount of data that the hub router is willing to accept in a single TCP/IP datagram.
no ip split-horizon eigrp 109
! Split horizon on the mGRE tunnel interface must be disabled; otherwise, EIGRP will not advertise routes learned via the mGRE interface back out that interface-not required now but will be if split-tunneling is enabled.
delay 2000
tunnel source Loopback0
tunnel mode gre multipoint
! Enables a GRE tunnel to be used in multipoint fashion.
Multipoint tunnels require that you configure a tunnel key. Otherwise, unexpected GRE traffic could easily be received by the tunnel interface. For simplicity, we recommend that the tunnel key correspond to the NHRP network
tunnel key <removed>
! The tunnel key will be the same as the ip nhrp network-id.
tunnel protection ipsec profile cvo-profile-1 shared
! Associates this tunnel interface with the IPSec profile cvo-profile-1
hold-queue 2000 in
hold-queue 2000 out
4.3.7. SLB Hub Router DVMPN Configuration
crypto isakmp policy 1
encr aes 256
crypto isakmp keepalive 45 5
crypto ipsec transform-set t1 esp-aes 256 esp-sha-hmac
mode transport require
crypto ipsec profile cvo-profile-1
set transform-set t1
!Only the ip address assigned to the loopback 1 interface on all of the SLB hub routers is accessible from the Internet, with holes in the corporate FW for ESP, ISAMKP and UDP port 4500 (NAT-T). All of the hub routers in a SLB DMVPN hub share the same ip address for Loopback1 and the mGRE interface, Tunnel 10.
interface Loopback1
description DMVPN mGRE interface
ip address <routable IP address of loopback interface of the SLB hub router> 255.255.255.255
interface Tunnel <Tunnel-interface-number>
! mGRE Tunnel Interface currently cannot exceed 800-1000 CPEs per SLB hub router
description DMVPN w/o ST
bandwidth 10000
ip address <IP-address-tunnel-interface> <subnet-mask-tunnel-interface>
no ip redirects
ip mtu 1400
ip hello-interval eigrp 109 30
ip hold-time eigrp 109 90
no ip next-hop-self eigrp 109
! Normally the eigrp process advertises itself as the next hop unless this command is specified-however required only if spoke-to-spoke tunnels are implemented. Configured to standardize with SDG's.
ip pim nbma-mode
! PIM configured for NBMA mode for the mGRE interface
ip pim sparse-dense-mode
ip multicast rate-limit out 768
ip nhrp map multicast dynamic
! NHRP will automatically create a broadcast/multicast mapping for CPEs when they register with the NHRP server
ip nhrp network-id <key>
! as specified for the specific SLB hub router tunnel interface
ip nhrp holdtime 500
ip nhrp server-only
! Prevents the hub from initiating and NHRP requests, as a result, the hub can only respond to NHRP requests
ip nhrp cache non-authoritative
! turns off default behavior on the SDG when it receives authoritative NHRP requests from NHRP clients for other NHRP clients it will forward to the appropriate client.
no ip split-horizon eigrp 109
! Split horizon on the mGRE tunnel interface must be disabled; otherwise, EIGRP will not advertise routes learned via the mGRE interface back out that interface-not required now but will be if split-tunneling is enabled.
delay 2000
tunnel source Loopback1
tunnel mode gre multipoint
! Enables a GRE tunnel to be used in multipoint fashion.
Multipoint tunnels require that you configure a tunnel key. Otherwise, unexpected GRE traffic could easily be received by the tunnel interface.
tunnel key <removed>
! The tunnel key will be the same as the ip nhrp network-id.
tunnel protection ipsec profile cvo-profile-1 shared
! Associates this tunnel interface with the IPSec profile cvo-profile-1
hold-queue 2000 in
hold-queue 2000 out
ip nhrp redirect
! Indicates that the current path to the destination is not optimal. Generates a NHRP redirect traffic indication message if the incoming and outgoing interface is part of the same DMVPN network. Required if spoke-to-spoke CPE connections are enabled.
4.4. IP Connectivity
IP Connectivity for the CPE devices and all core equipment is covered in the following sections:
• Cisco 871 connectivity
• SMG connectivity
• SDGs connectivity
• Large-scale data hubs configurations
4.4.1. Cisco 871 Connectivity
Based on the trusted-non-trusted concept of the new-generation CPE device configurations, only the traffic originated from trusted sources of the user's CPE is routed to the corporate network over the encrypted tunnel. The nontrusted traffic is routed directly to the ISP's gateway, reducing the demand for inbound capacity on Cisco POPs. Two VLANs are defined on the Cisco 871, the trusted subnet, VLAN 1, and the nontrusted subnet, VLAN 2. The trusted subnet is routable in the internal Cisco network. A bridge virtual interface (BVI1) is assigned a unique /28 RFC 1918 address and subnet and allows this /28 to be used for both wired and wireless devices on the trusted subnet. Interfaces FastEthernet0, FastEthernet1, and Dot11Radio0.1 (WLAN) of each CPE device are assigned to the trusted subnet. Traffic to and from these interfaces is routed across the VPN tunnels This subnet is part of a larger address block that is configured on the ISG NAT infrastructure to allow access to the Internet. The CPE devices are configured to run EIGRP in the EIGRP Autonomous System (AS) 109. Their only EIGRP neighbors are the SDGs or SLB hub routers, depending upon the architecture deployed at the data hub. The CPE interfaces Tunnel 0 and BVI1 are configured as EIGRP interfaces in AS 109, and CPE devices are configured to advertise only subnets assigned to this interface.
The interfaces FastEthernet2 and FastEthernet3 of each CPE are designated nontrusted ports. These interfaces are assigned to VLAN 2. A bridge virtual interface, BVI2, is configured with 10.0.2.0/24 on all CPE devices. Traffic generated by devices on the nontrusted subnet are routed directly to the outside interface using policy routing. Similar to devices connected to the trusted interfaces, devices on the nontrusted subnet are protected using the Cisco IOS Stateful Firewall. The CPE devices are configured to allow devices on the trusted subnet to access devices on the nontrusted subnet using TCP, but traffic is blocked in the reverse direction.
Wireless access on the trusted subnet uses the standard credentials employed on the corporate network for user authentication.
CPE devices are configured with one of three methods to assign or obtain an IP address on the FastEthernet4 interface-DHCP, Static, and PPPoE. Users are required to correctly configure their FastEthernet4 interface. By default, FastEthernet4 of the Cisco 871 Routers in Cisco Virtual Office are configured as DHCP clients, totaling about 90 percent of all the first-phase Cisco Virtual Office clients. Each CPE device is configured with static routes pointing out the outside interface for the following destinations:
• Management subnet for the CPE
• Loopback address of the SMG
• Loopback addresses of the SDGs, SDG subnet, or SLB hub router
• Public NTP servers
CPE devices with interface FastEthernet4 addresses assigned statically or through PPPoE require an additional floating static default route that is superseded by the default route learned through EIGRP after routing is established between the CPE and the SDGs or SLB hub router.
4.4.2. Cisco 871 IP Configuration
bridge irb
interface Tunnel0
bandwidth 2000
ip address <ip-address-mGRE-tunnel-interface> <subnet-mask-mGRE-tunnel-interface>
no ip redirects
ip mtu 1400
ip nhrp map <SLB-hub-router-mGRE-tunnel-interface-IP-address> <SLB-hub-router-routable-loopback-interface-IP-address>
ip nhrp map multicast <SLB-hub-router-routable-loopback-interface-IP-address>
ip nhrp network-id <network-identifier>
ip nhrp holdtime 500
ip nhrp nhs <IP address of mGRE interface of SLB hub router>
ip nhrp server-only
ip nhrp registration no-unique
qos pre-classify
tunnel source FastEthernet4
tunnel destination <routable IP address of hub router loopback interface used for mGRE tunnel>
tunnel key <tunnel-key>
tunnel protection ipsec profile CSM_IPSEC_PROFILE_1
ip hello-interval eigrp 109 30
ip hold-time eigrp 109 90
ip nhrp shortcut
ip nhrp redirect
! Allows CPE to establish spoke-to-spoke tunnels, when CPE participate in a SLB DMVPN hub-available from 12.4(6)T
interface FastEthernet0
description Provisioned by CSM (Corporate Interface)
speed 100
spanning-tree portfast
interface FastEthernet1
description Provisioned by CSM (Corporate Interface)
speed 100
spanning-tree portfast
interface FastEthernet2
description Provisioned by CSM (Home Interface)
switchport access vlan 2
no cdp enable
spanning-tree portfast
interface FastEthernet3
description Provisioned by CSM (Home Interface)
switchport access vlan 2
no cdp enable
spanning-tree portfast
interface FastEthernet4
description Provisioned by CSM (public interface)
no ip dhcp client request tftp-server-address
ip address dhcp client-id FastEthernet4
! IP Address on public interface assigned via DHCP
ip access-group FIREWALL_outside_inbound_1 in
ip nat outside
ip virtual-reassembly
load-interval 30
duplex auto
speed auto
no cdp enable
crypto map CSM_CME
service-policy output CSM_POLICY_MAP_HR_0
interface Dot11Radio0
no ip address
broadcast-key vlan 1 change 50
encryption vlan 1 mode ciphers tkip
encryption mode ciphers tkip
ssid corporate-ssid
vlan 1
authentication open eap eap_methods
authentication network-eap eap_methods
authentication key-management wpa
speed basic-1.0 basic-2.0 basic-5.5 6.0 9.0 basic-11.0 12.0 18.0 24.0 36.0 48.0 54.0
rts threshold 2312
rts retries 50
packet retries 32
station-role root
no cdp enable
interface Dot11Radio0.1
description Cisco Private
encapsulation dot1Q 1 nativ
no ip route-cach
no snmp trap link-statu
no cdp enable
bridge-group
bridge-group 1 subscriber-loop-contro
bridge-group 1 spanning-disable
bridge-group 1 block-unknown-sourc
no bridge-group 1 source-learnin
no bridge-group 1 unicast-floodin
interface Vlan
description Corporate Vla
no ip addres
ip virtual-reassembl
bridge-group
bridge-group 1 spanning-disable
interface Vlan
description Home Vla
no ip addres
ip virtual-reassembl
ip tcp adjust-mss 1452
bridge-group
bridge-group 2 spanning-disable
Interface BVI
Description Provisioned by CSM (corporate interface
ip address <bvi1addr> 255.255.255.240
! RFC 1918 subnet routable in Cisco, all CPE subnets assigned a /28
ip access-group FIREWALL_inside_inbound_1 i
ip nat inside
! NAT required to permit access to the Internet if IPSec tunnels are not established
ip inspect CSM_INSPCVO_1 i
ip virtual-reassembl
ip tcp adjust-mss 126
interface BVI
description Provisioned by CSM (public interface
ip address 10.0.2.1 255.255.255.
ip access-group TRUST_ACL_1 i
ip nat insid
ip inspect CSM_INSPCVO_1 i
ip virtual-reassembl
ip route-cache polic
ip tcp adjust-mss 1260
ip policy route-map ROUTEMAP_
router eigrp 109
passive-interface BVI
network <privnet> <privrmask
network <tunnetfull> <tunrmask
distribute-list CSM_IPSEC_REDISTRIBUTE_LIST_1 ou
no auto-summar
eigrp stub connected ! SDG's and hub routers will not send EIGRP queries to the CPEs
ip local policy route-map ROUTEMAP_1
ip route <sdp register's address> 255.255.255.255 tunnel0
ip classless
ip route <IP-subnet-Data-GW's> <DG IP subnet mask> <dhcp
! next-hop IP address! dialer1> ! static route to next hop to reach the SDG's and SLB hub routers, next hop depends upon method used to assign IP address to the interface E1(static or dhcp) or D1 (PPPoE)
ip route <IP-address-Management-GW-routable-loopback-interface> <loopback- interface-mask> <dhcp|next-hop-IP-address|dialer1>
! static route to next hop to reach SMG loopback interface
ip route <IP-subnet-Management-subnet> <IP-subnet-mask-Management-subnet> <dhcp ! next-hop-IP-address! dialer1>
! static route to next hop to reach Management subnet
ip nat inside source list 1 interface FastEthernet4 overload
ip nat inside source route-map ROUTEMAP_1 interface <FastEthernet4! Dialer1> overload
! WAN interface that is assigned an IP address (FastEthenet4 for dhcp and static and Dialer 1 for PPPoE)
ip inspect name CSM_INSPCVO_1 esmtp
ip inspect name CSM_INSPCVO_1 h323
ip inspect name CSM_INSPCVO_1 realaudio
ip inspect name CSM_INSPCVO_1 ftp
ip inspect name CSM_INSPCVO_1 udp
ip inspect name CSM_INSPCVO_1 tcp
ip inspect name CSM_INSPCVO_1 tftp
ip inspect name CSM_INSPCVO_1 skinny
ip inspect name CSM_INSPCVO_1 sip
ip access-list extended FIREWALL_inside_inbound_1
permit <protocol> any <smg-subnet> eq <port-number>
permit tcp any any eq domain
permit udp any any eq bootps
permit udp any any eq domain
permit tcp any any established
permit <protocol> any host <host-ip-address> eq <port-number>
deny ip any <ip- subnet>
permit ip any any
ip access-list extended FIREWALL_outside_inbound_1
permit ip <smg-subnet> <client subnet>
permit udp any any eq bootpc
permit udp any any eq isakmp
permit icmp any any
permit udp any any eq non500-isakmp
permit udp <public-ntp-servers> any eq ntp
permit gre any any
permit <protocol> host <ip address> any eq <protocol>
ip access-list standard CSM_IPSEC_REDISTRIBUTE_LIST_1
permit <IP-subnet-interface-BVI1-0> <wildcard subnet mask for BVI1>
permit <IP-subnet-interface-Tunnel-0> <wildcard subnet mask for Tunnel 0>
ip access-list extended NAT_ACL_1
deny ip <IP-subnet-interface-BVI1-0> <wildcard subnet mask for BVI1> any
deny ip 10.0.2.0 0.0.0.255 <IP-subnet-interface-BVI1-0> <wildcard subnet mask for BVI1>
permit ip 10.0.2.0 0.0.0.255 any
ip access-list extended TRUST_ACL_1
permit icmp 10.0.2.0 0.0.0.255 <IP-subnet-interface-BVI1-0> <wildcard subnet mask for BVI1>
permit tcp any any established
deny ip 10.0.2.0 0.0.0.255 <IP-subnet-interface-BVI1-0> <wildcard subnet mask for BVI1>
permit ip any any
route-map ROUTEMAP_1 permit 10
match ip address NAT_ ACL_1
set ip next-hop dynamic dhcp ! for CPE that obtains an IP address on FastEthernet 4 via DHCP
<IP-subnet-interface-BVI1-0> <wildcard subnet mask for BVI1>
ntp clock-period 17175078
ntp server <IP-address-SMG-management-subnet> source FastEthernet4 prefer
ntp server 64.104.222.16
ntp server 140.142.16.34 ! public ntp server
ntp server 198.123.30.132 ! public ntp server
ntp server 171.68.10.80 source BVI1
ntp server 171.68.10.150
An example of the floating static route that is applied to CPEs with the IP address assigned statically or via PPPoE to the outside interface:
ip route 0.0.0.0 0.0.0.0 <dialer1|next-hop-IP-address> 240
! Administrative distance of 240, default route learned from EIGRP will supersede this route.
4.4.3. SDG and Large-Scale Data Hub Router Architecture
SDG Architecture
SDGs are configured so that split tunneling is not permitted for CPE devices. The SDGs run EIGRP routing protocol using Autonomous System AS 109 and have redundant connections to the corporate network.
Figure 9 shows the SDG connectivity, which is representative of other SDG locations. Only the loopback address and the subnets assigned to the CPE BVI1 (Cisco 871) and E0 (Cisco 831) and Tunnel interfaces are advertised into EIGRP 109 on the upstream routers. The SDGs are configured to accept routes from EIGRP109 for default. An Offset list is applied on the failover SDG to ensure transparent failover if the primary SDG stops routing.
Figure 9. Cisco Virtual Office SDG
SDG Configuration
interface Loopback0
ip address <routable IP address of loopback interface of SDG> 255.255.255.255
interface Tunnel <Tunnel-interface-number>
! mGRE Tunnel Interface, initial number is 10, next is 20, and currently cannot exceed 800-1000 CPEs per SDG.
description DMVPN w/o ST
bandwidth 10000
ip address <IP-address-tunnel-interface> <subnet-mask-tunnel-interface>
! Subnet for tunnel interfaces on both SDG's and all CPEs in DMVPN cloud. For most cases the mask will be a /23 as the number of CPEs per mGRE interface is limited to about 600.
no ip redirects
ip mtu 1400
ip hello-interval eigrp 109 30
ip hold-time eigrp 109 90
no ip next-hop-self eigrp 109
! Normally the eigrp process advertises itself as the next hop unless this command is specified-however required only if spoke-to-spoke tunnels are implemented.
ip pim nbma-mode
! PIM configured for NBMA mode for the mGRE interface
ip pim sparse-dense-mode
ip multicast rate-limit out 768
ip nhrp map multicast dynamic
! NHRP will automatically create a broadcast/multicast mapping for CPEs when they register with the NHRP server
ip nhrp network-id xx01
! as specified for the specific SDG and tunnel interface
ip nhrp holdtime 500
ip nhrp server-only ! Prevents the hub from initiating and NHRP requests, as a result, the hub can only respond to NHRP requests
ip nhrp cache non-authoritative ! turns off default behavior on the SDG when it receives authoritative NHRP requests from NHRP clients for other NHRP clients it will forward to the appropriate client.
ip tcp adjust-mss 1360
! Defines the maximum amount of data that the hub router is willing to accept in a single TCP/IP datagram.
no ip split-horizon eigrp 109
! Split horizon on the mGRE tunnel interface must be disabled; otherwise, EIGRP will not advertise routes learned via the mGRE interface back out that interface-not required now but will be if split-tunneling is enabled.
delay 2000
tunnel source Loopback0
tunnel mode gre multipoint
! Enables a GRE tunnel to be used in multipoint fashion.
Multipoint tunnels require that you configure a tunnel key. Otherwise, unexpected GRE traffic could easily be received by the tunnel interface. For simplicity, we recommend that the tunnel key correspond to the NHRP network
tunnel key <removed>
! The tunnel key will be the same as the ip nhrp network-id.
tunnel protection ipsec profile cvo-profile-1 shared
! Associates this tunnel interface with the IPSec profile cvo-profile-1
hold-queue 2000 in
hold-queue 2000 out
!
interface GigabitEthernet0/1
ip address <ip-address-data-gw> 255.255.255.252
ip access-group REMOTE_HOST_BLOCK in
ip pim sparse-dense-mode
ip summary-address eigrp 109 <ip-addr><mask> admin-distance
! configures interface level route summarization
duplex full
speed 1000
media-type rj45
no negotiation auto
crypto ipsec df-bit clear
hold-queue 4000 in
hold-queue 2000 out
!
interface GigabitEthernet0/2
ip address <ip-address-data-gw> 255.255.255.252
ip access-group REMOTE_HOST_BLOCK in
ip pim sparse-dense-mode
ip summary-address eigrp 109 <ip-addr><mask> admin-distance
! configures interface level route summarization
duplex full
speed 1000
media-type rj45
no negotiation auto
crypto ipsec df-bit clear
hold-queue 4000 in
hold-queue 2000 out
interface GigabitEthernet0/3
ip address <ip-address-data-gw> 255.255.255.252
ip hello-interval eigrp 109 15
ip hold-time eigrp 109 45
duplex full
speed 100
media-type rj45
no negotiation auto
crypto ipsec df-bit clear
hold-queue 2000 in
hold-queue 2000 out
!
router eigrp 109
network <ip-address-block-non-routable-interface-IP-addresses>
! for most installations this is 10.0.0.0
network < ip-address-block-non-routable-interface-IP-addresses>
distribute-list USER_SUBNETS_AND_INTERFACES out GigabitEthernet0/1
! Permits only CPE Ethernet subnets, DC interfaces and mGRE tunnel interfaces to be advertised from the SDG.
distribute-list DEFAULT_ONLY in GigabitEthernet0/1
! SDG only requires default as long as CPEs are configured in non-split-tunneling configuration
distribute-list USER_SUBNETS_AND_INTERFACES out GigabitEthernet0/2
distribute-list DEFAULT_ONLY in GigabitEthernet0/2
distribute-list Spoke_Routes in GigabitEthernet0/3
distribute-list DEFAULT_ONLY out Tunnel10
! for non-split-tunneling CPE route configurations, only default will be advertised via EIGRP
distribute-list DEFAULT_ONLY out Tunnel20
no auto-summary
ip access-list standard DEFAULT_ONLY
permit 0.0.0.0
ip access-list standard OFFSET
! required only on secondary SDG in an mGRE instance
permit any
ip access-list standard USER_SUBNETS_AND_INTERFACES
permit <ip-address-interface-loopback1>
permit <ip-address-interface-g0/1>
permit <ip-address-interface-g0/2>
permit <ip-address-block-CPE-routers><wildcard-subnet-mask>
permit <ip-address-block-mGRE-interface-subnets><wildcard-subnet-mask>
4.4.4. Large-Scale Data Hub Router Architecture
As stated earlier, DMVPN supports two types of large-scale DMVPN architectures.
In the first architecture, the SLB model, depicted in Figure 10, the SLB hus perform all DMVPN functions, including IPsec encryption and decryption and maintaining the NHRP database and the routing protocol relationship with CPE devices.. Traffic to and from the hub routers is sent through a dedicated SLB router, with an additional SLB in standby mode.
Figure 10. Cisco Virtual Office SLB Hub Router Architecture withIPsec, DMVPN Performed on Hub Routers)
Figure 11 depicts a second design for implementing a large-scale DMVPN hub, the dual-tier headend model. In this model, the DMVPN function is split among different devices. First IPsec traffic from CPE is encrypted and decrypted by a Cisco Catalyst 6500 with a Supervisor Engine 720 and VPN SPA module, the encryption tier. The routing, including DMVPN NHRP and GRE encryption and decryption, is performed on a hub router, or Routing Tier.
Figure 11. Dual-Tier Headend Architecture where Access Gateways process IPsec encryption and decryption
Both models have distinct advantages, but the existing Cisco IT deployment is implemented based on the Cisco Virtual Office SLB Hub router architecture described in Figure . This decision to use a distibured encryption was made because of the high CPU and responsiveness of the Cisco Catalyst 6500 management gateways when PKI-AAA authorization was previously enabled. At times in the first phase of the Cisco Virtual Office program we observed a few isolated instances when a CPE device attempted to establish a connection with the hub by offering an invalid certificate. Just a few CPE devices offering invalid certificates can severely degrade performance on the hub before their connection attempts can be blocked. In most cases the certificates are invalid because the employee was terminated. The source of the problem is that the CPE device constantly attempts to establish the connection with the hub. STG was approached with this information and agreed to treat suggestions as feature requests that may be addressed with the introduction of IKE2 into Cisco IOS Software. Spreading the function of device authorization across many hub routers would minimize the potential effect on all clients. When this problem is addressed, the Cisco Virtual Office large-scale data hub architecture can be reevaluated for data connectivity. As with the SDGs, the SLB hub routers are configured to send a default route to CPE, and not to allow split tunneling.
4.4.5. SLB and Hub Router Architecture
The Cisco IOS SLB feature is a Cisco IOS Software-based solution that provides IP server load balancing. SLB in Cisco Virtual Office is based on following design considerations:
• The SLB device in Cisco Virtual Office will initially be a Cisco 7206VXR with an NPE-G2 configured as the Load Balancer. Later, for larger hubs, such as San Jose, RTP, and Bangalore, a Cisco Catalyst 6503 Switch will be configured as the Load Balancer. The load-balancer capacity should not be of concern because a Cisco 7206VXR with an NPE-400 can create 5000 connections per second and switch packets at half the Cisco Express Forwarding rate of 0.14.
• A group of hub routers associated with the Load Balancer are configured to handle all the tasks related to DMVPN, including Next-Hop Resolution Protocol (NHRP), Multipoint Generic Routing Encapsulation (MGRE), and IPsec encryption and decryption.