Table Of Contents
Planning Issues and Decisions
IPSec Overview
Deployment Information
Standards and Specifications
Network-Based IPSec VPN Solution Planning
Scalability, Capacity Planning, and Performance
Security Policies
Planning Issues and Decisions
IPSec Overview
For general information about IPSec, see http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/vpnsc/ipsec/2_0/prov_gd/ipsecpg1.htm.
Deployment Information
For information on deploying IPSec VPNs, see http://www.cisco.com/warp/public/cc/pd/iosw/prodlit/depip_wp.htm.
Standards and Specifications
For information on standards and specifications, see http://www.cisco.com/pcgi-bin/Support/browse/psp_view.pl?p=Internetworking:IPSec&s=Overview#Standards_and_Specifications.
Network-Based IPSec VPN Solution Planning
Keep the following issues in mind when planning the solution:
•
Use of domain name—Use a domain name in the IPSec endpoint definition on the VPN clients instead of IP addresses. You can then use DNS to resolve the domain names into IP address before IPSec session creation.
Using domain names allows flexibility in deployments because no changes are required on the clients if any changes are made on the server side (server IP address, additional server added that must be resolved to different IP addresses, and load balancing among servers based on DNS resolution).
•AAA setup—You (service provider) can set up RADIUS so that it conforms to your own and to your enterprise customers' existing AAA structure. We recommend two ways to implement AAA:
–Proxy AAA—Your AAA can perform the user authentication while the authorization request can be proxied to the customer AAA server.
Note The customer AAA server must be reachable through the global routing table.
–VRF aware AAA—Send the authorization and the authentication requests directly to the customer AAA server on a per VRF basis.
•Route summarization—RRI installs a route to the IP address assigned to the client in the VRF routing table. The route would usually be in the customer address range, but it must be advertised to the other PEs that are part of the VPN. It is advisable to define the address pools along summarizable boundaries. Instead of advertising each and every individual RRI installed route, only advertise a summary route into the VPN (this reduces the routing protocol overhead and the routes that a VRF handles).
•Split tunneling—The VPN clients normally connect to the server over the Internet; after connecting, you have the option to:
–restrict their Internet access by forcing all the traffic over the IPSec tunnel or
–allowing it to continue using its existing Internet connection for non-VPN related traffic (split tunneling)
You can send the access-list to separate the VPN traffic to the client during Mode-Config. The decision to enable/disable split tunneling is usually based on the policies and service agreements of the service provider and customer.
Note Most enterprise customers would like to disable split tunneling, thereby forcing all traffic, even non-VPN related, to the central site. This allows the enterprise to have greater control over client communication and to force all Internet traffic through a firewall to protect the enterprise's internal network.
•If split tunneling is enabled, the enterprise customer can potentially open up its networks to external attacks. If the customer has a service agreement with you (the service provider) to provide direct Internet services, then the split tunneling would be disabled and you (the service provider) would provide Internet services.
•Default route—For IKE/IPSec completion, the tunnel endpoint reachability needs to be available in the global or the VRF routing table.
Note For almost all deployment models in the network-based IPSec VPN solution the outbound interface is global. However, if you choose to, you can place the outbound interface in a VRF.
–For global reachability, a default route in the global routing table needs to be injected; this should not be a issue in most deployments as the server would need some form of Internet connectivity for the clients and the sites to connect to it.
–The endpoint reachability in the VRF table can pose challenges. The easiest implementation is to have a default route in each of the VRFs pointing out the interface on which the clients connect. This may not be possible or desirable in many situations.
•If split tunneling is disabled, then all the traffic needs to be forwarded to the enterprise hub site. The easiest way to accomplish this would be for the hub site to distribute a default route to its PE which would then be propagated to the rest of the PEs in the VPN network.
Figure3-1 shows one possible implementation that manipulates the VRF route export/import policies in BGP.
Figure 3-1 Possible Default Route Implementation
If customer A belongs to a certain VPN and if split tunneling is disabled on the clients, then all the traffic going to the Internet is forwarded to the company hub site. Customer A's hub router advertises a default route to the PE1. The MBGP route export policies on PE1 are defined in such a way that only the default route is advertised to the other PEs (PE2 and PE3 in this case). The route targets on PE2 and PE3 are set in such a way that they import PE1 routes only (default route). PE2 and PE3 in turn export aggregate subnets to the PE1 only. These subnets are in turn advertised into the IGP running between the CompanyA hub router and PE1. In effect, all the traffic is forwarded to the company hub site which can control user policies and apply services such as firewall.
Scalability, Capacity Planning, and Performance
The Cisco 7204 and 7206 routers are the only supported platforms in Cisco network-based IPSec VPN solution Release 1.5. Keep in mind the following factors when deploying the solution:
•Total number of tunnels; distinguish between site-to-site and client tunnels.
•Peak number of tunnels that will be serviced.
•Number of VRFs.
•Number of routes per VRF from remote PEs and from remote sites (if performing dynamic routing).
•Whether you will load balance or provide redundancy.
Load balancing can be accomplished by:
–Manually distributing the VRFs across multiple boxes.
–Using multiple HSRP groups, which will also provide redundancy.
–Using fully-qualified domain names to resolve domain names into IP addresses. The DNS server can load balance the incoming request across different boxes.
Security Policies
When defining and installing security policies for the Cisco network-based IPSec VPN solution Release 1.5, consider the following:
•Firewalls—Although not part of the solution, it is assumed that firewalls are installed and used on both your own (service provider) network and the customer network. You should have a firewall at the Internet entry/exit point to protect your network and the customers it services. In most cases you should disable split tunneling on the clients so that all traffic, including non-VPN traffic, is forwarded to the customer hub site. This allows the customer firewall to process all incoming traffic thereby protect the customer network from external attacks.
•Access lists—To further protect the IPSec server, define access lists on the outgoing interfaces of the router connected to the server (towards the Internet) to restrict the traffic to IKE and IPSec.
•AAA—To deny unauthorized access, use XAUTH to authenticate the VPN clients. We also recommend that you use advanced password generation methods such as secure ID during authentication.
Note When using the proxy AAA method for user authorization, the customer AAA server needs to be accessible through the global routing table for proxy function successfully.
•Route import/export policy—In the MPLS VPN scenario, PEs exchange VPN routes based on the route export/import policies configured under each VRF. Potential configuration errors (for example, incorrect route descriptors) could lead to cross-VRF route export/import that can compromise the VPNs.
Note Be sure to verify the configuration before applying any changes to the network.
