Deploying Site-to-Site IPSec VPNs

Transcription

1 1 Deploying Site-to-Site IPSec VPNs Session Copyright Printed in USA. 2

2 Other VPN Sessions SEC-1000: Introduction to Network Security SEC-2010: Deploying Remote-Access IPSec VPNs SEC-2012: Deploying Complex and Large Scale IPSec VPNs SEC-3010: Troubleshooting IOS and PIX-Firewall Based IPSec Implementations SEC-3011: Troubleshooting VPN 3000 IPSec Implementations SEC-4010: Advanced IPSec Algorithms and Protocols 3 Agenda Applications of Site-to-Site IPSec VPNs Design Considerations Deployment Scenarios Fine Tuning Site-to-Site Deployment High Availability Management Case Study A Appendix 4 Copyright Printed in USA.

3 WAN Replacement Using Site-to-Site IPSec VPNs Intranet Branch/Remote Office Frame Internet Relay WAN VPN Network Extranet Business-to-Business POP DSL Cable Central Site 5 WAN Backup Using Site-to-Site IPSec VPNs Intranet Branch/Remote Office Extranet Business-to-Business VPN VPN Frame Relay WAN Network Internet VPN PSTN/ISDN Broadband VPN VPN Central Site 6 Copyright Printed in USA.

4 Regulatory Encryption Using Site-to-Site IPSec VPNs Country laws may require encryption in certain sectors (healthcare, finance) even if another VPN technology is used (Frame Relay, MPLS VPN) Intranet Branch/Remote Office Frame Relay or MPLS VPNs Extranet Business-to-Business 7 Agenda Applications of Site-to-Site IPSec VPNs Design Considerations Deployment Scenarios Fine Tuning Site-to-Site Deployment High Availability Management Case Study 8 Copyright Printed in USA.

5 Design Topics for Consideration IP addressing Routing Security Device authentication Migration Security policy enforcement Access control Scalability Device placement Performance Best products for function High Availability QoS Management Interoperability 9 Design Considerations: IP Addressing and Routing IP Addressing IPSec VPN is an overlays on existing IP network. VPN device needs routable IP address, Private IP address space can be used across VPN Design VPN address space to allow summarization NAT is not required or bypassed for VPN traffic Routing Routing required to forward encrypted and un-encrypted traffic appropriately Large Scale networks require dynamic routing 10 Copyright Printed in USA.

6 B A N K Design Considerations: Security Components of a VPN Packet IPSec Tunnel Packet L3 L7 Inspection IDS/FW IPSec L3 Filtering (Stateless) Network Transport L3 Filtering (Stateless) IPSec L3 L7 Inspection IDS/FW Peer Authentication Data Encryption Packet Integrity Session Re -Keying Apply layered security model to VPN designs Intranet and extranet consideration 11 Design Considerations: Cryptographic Options RFC IPSec Implementation Secure VPN IPSec Many Safeguards Hides Networks Transparent Tunneling Encryption Authentication Integrity IPSec GRE DES Triple DES AES RSA Digital Certificates Pre-shared Key HMAC-MD5 HMAC-SHA-1 12 Copyright Printed in USA.

7 Design Considerations: VPN Device Authentication Pre-shared keys Tied to unique IP address, not highly scalable, moderate difficulty to deploy Wildcard pre-shared keys Any device may use regardless of IP address, insecure since if the key is compromised all devices can be tunneled to, extremely easy to deploy Digital certificates Highly scalable, initial investment significant, very secure, non-repudiation option, not tied to IP address 13 Design Considerations: Migration Migration from traditional WAN Generally Internet access via a router and/or firewall already exists If existing Internet WAN link is used for VPN as well, augment bandwidth to accommodate extra VPN traffic and QoS may be required. Policy routing may be necessary during a phased migration approach 14 Copyright Printed in USA.

8 Design Considerations: Scaling, Sizing and Performance I Head-end VPN Device sizing consideration factors: Total number of remote sites, tunnels VPN traffic throughput Features: routing protocols, GRE, Firewall, QoS Scalability The head-end design must scale to support future load requirements Consider integrated verses purpose - defined devices Routing, resilience, load balancing, and the WAN connection are all key factors 15 Design Considerations: Scaling, Sizing and Performance II A head-end device should not be deployed in a configuration that results in CPU utilization higher than 50% after failure The 50% target includes all overhead incurred by IPSec and any other enabled features (firewall, routing, IDS, logging, etc.) Branch devices should not be taxed above 65% CPU utilization 16 Copyright Printed in USA.

9 Performance: Features and Packet Sizes Throughput Unencrypted Firewall Unencrypted QoS 3DES-SHA/Software 3DES-SHA/Hardware IPsec/FW IPsec/QoS IPsec/QoS/FW GRE 3DES-SHA VPN Head-end and Branch Device Consideration Cisco 1700 Series Cisco PIX 506-E Cisco VPN 3005 Remote Office T-1/E-1 Cisco 7200/6500 Series Cisco PIX 535 Cisco VPN 3080 Cisco 2600/3600 Series Cisco PIX 515-E Cisco VPN 3030/3060 nxt-1/e-1 Regional Office Broadband Central Office Cisco 800/900 Series Cisco PIX 501 Cisco VPN3002 Home Office 18 Copyright Printed in USA.

10 Design Consideration: Topology Peer-to-Peer Hub and Spoke Most common topology Scales well, o(n) Performance penalty due to two encryption/decryption cycles Partial Mesh Compared to hub and spoke topology, more direct spoke to spoke communications Fully Mesh Scaling issues: IPSec tunnels grow exponentially as number of sites increases Difficult to provision 19 Design Consideration: VPN Device Placement VPN Device In Parallel to Firewall VPN Terminated On DMZ Firewall/IDS Integrated VPN Device 20 Copyright Printed in USA.

11 VPN Device in Parallel to Firewall Stateless L3 Filtering (IKE,ESP) VPN Termination VPN Focused Layer 4 7 Analysis To WAN Edge To Campus Monitoring Internet Traffic DMZ Layer 4 7 Stateful Inspection and Filtering DOS Mitigation 21 Design Summary PROS Simplifies migration task VPN device addition Easy device management High scalability stack VPN devices CONS Doesn t completely abide to the layered security model Lacks stateful inspection unless VPN device supports it No centralized point of logging/content inspection 22 Copyright Printed in USA.

12 VPN Terminated on DMZ Stateless L3 Filtering (IKE,ESP) VPN VPN Termination Focused Layer 4 7 Analysis To WAN Edge To Campus Monitoring Internet Traffic DMZ Layer 4 7 Stateful Inspection and Filtering DOS Mitigation 23 Design Summary PROS Abides to the layered security model and enforces security policies that require firewalling Easy management with additional device Migration relatively straightforward with addition of LAN interface to firewall Moderate-to-high scalability as we stack VPN devicesos CONS Configuration complexity increases additional configuration on firewall Firewall must support policy routing to differentiate VPN verses non-vpn traffic Firewall may impose bandwidth restrictions on stacks of VPN devices 24 Copyright Printed in USA.

13 Firewall/IDS Integrated VPN Device To WAN Edge To Campus DMZ To WAN Edge DMZ To Campus To WAN Edge To Campus 25 Design Summary PROS Abides to the layered security model and enforces security policies that require firewalling Migration relatively straight-forward with addition of VPN feature set to firewall Same number of devices to manage CONS Scalability can be an issue as single device must scale to meet performance requirements of multiple features Complex configuration, many eggs in one basket 26 Copyright Printed in USA.

14 Agenda Applications of Site-to-Site IPSec VPNs Design Considerations Deployment Scenarios Fine Tuning Site-to-Site Deployment High Availability Management Case Study 27 Site-to-Site VPN Deployment Scenarios Basic peer-to-peer topology Basic Site-to-Site IPSec Configuration Static vs Dynamic Mapping Crypto ACL Consideration Split Tunneling Consideration Access Control Hub and Spoke Topology GRE Over IPSec Partial/Fully Mesh Topology Tunnel Endpoint Discovery (TED) Dynamic Multipoint VPN (DMVPN) 28 Copyright Printed in USA.

15 Secure Communications IPSec VPN A I m A Here Is my Proof Authority Identity Authentication and Trust B I m B Here Is my Proof PKI Proposals Key Generation Key Management Security Association ISAKMP and IKE Proposals IPSec VPN Tunnel IPSec Encryption Algorithms and Standards Hash Algorithms Tunneling Technology Cryptography Building Blocks A B Needs Secure Communications over Insecure Channel 29 IKE and Security Association IKE IPSec Data Two-phase protocol: Phase I exchange : two peers establish a secure, authenticated channel with which to communicate; Main mode or aggressive mode accomplishes a phase I exchange Phase II exchange : IPSec security associations are negotiated on behalf of IPSec services; Quick mode accomplishes a phase II exchange Each phase has its security association s(sas): ISAKMP SA (phase I, bi-directional) and IPSec SA (phase II, unidirectional) 1 Tunnel = 1 IKE SA + 2 IPSec SAs 30 Copyright Printed in USA.

16 Peer-to-Peer Configuration: IKE (Phase I) Policy Backbone Router1 Router / /24 crypto isakmp policy 1 authentication pre-shared hash sha encr aes 256 group 5 crypto isakmp key df*li^gj*al address netmask crypto isakmp policy 1 authentication pre-shared hash sha encr aes 256 group 5 crypto isakmp key df*li^gj*al address netmask IPSec (Phase II) Policy Backbone Router1 Router / /24 crypto ipsec transform-set aes_sha espaes 256 esp-sha-hmac access-list 101 permit ip crypto map VPN_To_R2 10 ipsec-isakmp set peer match address 101 set transform-set aes_sha crypto ipsec transform-set aes_sha esp-aes 256 esp-sha-hmac access-list 101 permit ip crypto map VPN_To_R1 10 ipsec-isakmp set peer match address 101 set transform-set aes_sha 32 Copyright Printed in USA.

17 Apply VPN Configuration Backbone Router1 Router / /24 interface serial 1/0 ip address crypto map VPN_To_R2 ip route interface serial 3/0 ip address crypto map VPN_To_R1 ip route PIX Firewall Site-to-Site VPN Configuration isakmp policy 1 authentication pre-share isakmp policy 1 encryption 3des isakmp policy 1 hash md5 isakmp policy 1 group 2 isakmp policy 1 lifetime isakmp key ********** address netmask access-list vpnacl permit ip crypto ipsec transform-set myset esp-3des esp-md5-hmac crypto map vpnmap 1 ipsec-isakmp crypto map vpnmap 1 match address vpnacl crypto map vpnmap 1 set peer crypto map vpnmap 1 set transform-set myset access-list bypass_nat permit ip nat (inside) 0 access-list bypass_nat sysopt connection permit-ipsec isakmp enable outside crypto map vpnmap interface outside Define IKE (phase I) policy Define IPSec (phase II) Policy Bypass NAT Allow VPN through Apply tunnel 34 Copyright Printed in USA.

18 VPN 3000 Concentrator Configuration 35 VPN 3000 Concentrator (Cont.) 36 Copyright Printed in USA.

19 Static vs. Dynamic Crypto Map Site_A Site_B ISP Dynamic Crypto Map crypto map vpn 10 IPSec-isamkp dynamic dynamap crypto dynamic-map dynamap 10 set transform-set match address Static Crypto Map crypto map vpn 10 IPSec-isakmp set peer Site_A set transform-set match address 101 crypto map vpn 20 IPSec-isakmp set peer Site_B set transform-set match address Static vs. Dynamic Crypto Map (Cont.) Static Crypto Map Need to VPN peer, crypto ACL, IPSec transform-set Use multiple crypto map instances to define multiple VPN peers Bi-directional tunnel initiation Requires more intensive management, deployment and troubleshooting Dynamic Crypto Map Only need to configure IPSec transform-set, crypto ACL is optional One dynamic map as a template Only the remote peer can initiate tunnel Used when remote peer has dynamic IP address Simple to manage and deploy 38 Copyright Printed in USA.

20 Crypto ACL Consideration: Cisco IOS and PIX Firewall Crypto ACL defines IPSec SA proxy identities which specifies what data traffic IPSec protects Cisco IOS/VPNSM/PIX use access-list which supports L3/L4 protocol, L4 Ports, port ranges, IP address, IP subnets, subnet ranges Only use the any keyword once in a given ACL entry Take care to match more specific ACL entries first Never use any any 39 Crypto ACL Consideration: VPN 3000 Concentrator VPN 3000 uses network lists which support only IP address, subnets, subnet ranges Auto Discovery in conjunction with routing can be enabled to automatically exchange crypto network list between VPN peers Crypto ACL: / /24 Internet RIP / /24 40 Copyright Printed in USA.

21 IPSec SA Scalability: Crypto ACL Summarization ISP Internet access-list 199 permit tcp range any eq www Six SAs access-list 101 permit ip access-list 101 permit ip access-list 101 permit ip Two SAs: access-list 101 permit ip any Each ACL entry corresponds to two IPSec SAs Plan VPN addressing scheme carefully so that crypto ACL can be summarized: Reduce configuration Improve IPSec SA performance 41 Split Tunneling Traffic Flow Split-Tunneling Enabled VPN Internet VPN Head- End Definition: Split tunneling is the ability of a device to forward clear and encrypted traffic at the same time over the same interface In Site-to-Site VPN, Use routing and crypto ACL to control split tunneling Enabling split tunneling on spoke site can reduce load on head end. Use firewalls on spoke site to secure spoke VPN devices 42 Copyright Printed in USA.

22 Filtering/Access Control When filtering at the edge there s not much to see IKE UDP port 500 ESP, AH IP Protocol numbers 50,51 respectively NAT Transparency Enabled UDP port 4500 Internal access control should be implemented via the internal interface ACLs or group policy and not the crypto ACLs for the performance reasons 43 Hub and Spoke Topology 90% hub spoke, 10% spoke spoke traffic Design options: Cisco IOS: Uses crypto ACL summarization for smaller scale deployment; uses GRE over IPSec with dynamic routing protocol for larger scale deployment VPN 3000 concentrators use summarized network lists for small scale deployment PIX Firewalls do not support hub and spoke topology Best option: GRE over IPSec with dynamic routing protocol 44 Copyright Printed in USA.

23 Why GRE over IPSec L3 GRE Tunnel IPSec Tunnel IP IP ESP HDR Data IP GRE IP HDR Data IP HDR HDR HDR HDR HDR GRE IP HDR HDR Encrypted IP HDR IPSec (ESP) tunnels only IP unicast traffic GRE encapsulates non-ip and IP multicast or broadcast packets into IP unicast packets Using a GRE tunnel inside an IPSec tunnel uses only three security associations (at maximum) Use tunnel mode IPSec verses transport because: 1:1 NAT doesn t have problems With hardware acceleration it is actually faster Some new features (LAF) require tunnel mode Data Decapsulate Twice Data 45 GRE over IPSec Configuration A crypto isakmp policy 1 authentication pre-share crypto isakmp key cisco47 address crypto ipsec transform-set trans2 esp-3des esp-md5-hmac mode transport crypto map vpnmap2 local-address Ethernet1 crypto map vpnmap2 10 IPSec-isakmp set peer set transform-set trans2 match address 110 interface Ethernet1 ip address crypto map vpnmap2 interface Tunnel0 ip address ip mtu 1440 tunnel source Ethernet1 tunnel destination crypto map vpnmap2 ip route access-list 110 permit gre - host host (13)T and later crypto isakmp policy 1 authentication pre-share crypto isakmp key cisco47 address crypto ipsec transform-set trans2 esp-3des esp-md5- hmac mode transport crypto ipsec profile vpnprof set transform-set trans2 interface Ethernet1 ip address interface Tunnel0 ip address ip mtu 1440 tunnel source Ethernet1 tunnel destination tunnel protection ipsec profile vpnprof ip route Copyright Printed in USA.

24 GRE over IPSec Configuration Evolution Before 12.2(13)T, crypto maps are required to apply to both GRE tunnel interface and physical interface From 12.2(13)T and later Only need to apply crypto map on tunnel interface Use tunnel protection ipsec profile under tunnel interface 47 GRE over IPSec Design Recommendations I s1 h1 h2 INTERNET In order to avoid asymmetric routing, one of the two GRE tunnels between the head-end and remote site must be favored Change bandwidth value for the GRE interface on both ends to create primary and secondary tunnels Unrealistic bandwidth setting might affect the flow control of EIGRP Alternative: use the delay command under GRE tunnel interface s2 48 Copyright Printed in USA.

25 GRE over IPSec Design Recommendations II On failure recovery, the load should be dynamically rebalanced at the head-end Generally speaking the routing protocol at the head-end can safely scale up to 240 peers Consider that EIGRP is less CPU intensive than OSPF GRE Keepalives can be used for failure detection in case of static routing 49 Partial/Full Mesh Topology More than 50% spoke spoke traffic Configuration task, number of IPSec SAs grow exponentially as number of spoke sites increases; does not scale well for above ~10 sites Dynamic peer discovery and on-demand tunnel creation mechanisms are required: Tunnel Endpoint Discovery (TED) Dynamic Multipoint VPN (DMVPN) 50 Copyright Printed in USA.

26 Tunnel Endpoint Discovery (TED) A X1 A to B Must Be Protected No SA => Send Probe IP: A to B X2 IKE: A to B (proxy=x1) IKE: Y to X1 Traffic to B Must Be Protected No SA and Probe Received => Block and Answer Probe Y B TED sends an IKE probe to the remote network to determine IKE peer Requires use of registered addresses for end hosts crypto dynamic-map ted-map 10 match address 101 crypto map tedtag 10 ipsec-isakmp dynamic ted-map discover access-list 101 permit ip Dynamic Multipoint VPN (DMVPN) /24 fi E /24 fi /24 fi fi fi H Rh1 Internet /24 Multi-point GRE greatly reduces configuration task Next hop resolution protocol (NHRP) is used to dynamically map GRE layer to backbone IP layer Dynamic, on-demand spoke-to-spoke communication.spoke sites can have dynamic IP address GRE/IPSec /24 fi /24 fi E /24 fi fi fi /24 fi /24 fi /24 fi E fi fi Rs1.2.2 H / /24 H3 52 Copyright Printed in USA.

27 Agenda Applications of Site-to-Site IPSec VPNs Design Considerations Deployment Scenarios Fine Tuning Site-to-Site Deployment High Availability Management Case Study 53 Fine Tune VPN Systems to Avoid MTU Issues Due to the overhead (~60bytes) added by IPSec in the middle of transmission path, the Path MTU (PMTU) setting of your VPN system might need to be fine tuned to avoid stalled application symptom Normal scenarios (No need to fine tune) Application sends only small-sized packets PMTU discovery (PMTUd) process helps end hosts reduce packet size automatically to accommodate IPSec overhead 54 Copyright Printed in USA.

28 Fine Tune VPN Systems to Avoid MTU Issues (Cont.) When do you need to find tune: PMTUd fails due to the ICMP messages used by PMTUd (Type 3 code 4) are lost or blocked IPSec fragments packets after encryption; the reassembly job done by the remote VPN device causes performance degradation When DF (Don t Fragment) bit is set 55 IPSec and PMTU Discovery MTU / /28 MTU 1500 e1/1 e1/0 MTU MTU MTU Path 1500 Media 1500 IPSec Tunnel Path 1500 Media DF=1 ICMP Type3 Code 4 (1454) 1454 DF= DF Copied 1454 DF=1 ICMP Type3 Code 4 (1354) 1354 DF=1 ICMP (1400) ICMP: dst ( ) frag. needed and DF set unreachable sent to ( debug ip icmp output) IPSec SPI Copied ICMP: dst ( ) frag. needed and DF set unreachable rcv from Adjust path MTU on corresponding IPSec SA path mtu 1400, media mtu 1500 current outbound spi: EB84DC Copyright Printed in USA.

29 PMTU Setting Options on VPN Devices General Consideration: Avoid fragmentation after encryption as much as possible Adjust MTU to leave room in advance for IPSec overhead Last resort: clear DF bit so that packet can get through Device Methods for setting PMTU Cisco IOS PIX VPN 3000 Adjust TCP MSS option Look Ahead Fragmentation (LAF) Adjust IP MTU of GRE tunnel interface Clear DF bit using policy routing or IPSec df-bit clear feature (last resort) Adjust TCP MSS option Pre-tunnel Fragmentation Adjust IP MTU of the interface Clear DF bit 57 Adjust TCP MSS Option TCP Maximum Send Segment (MSS) option is sent during TCP connection establishment phase; TCP end hosts obeys the MSS value conveyed to the other end Cisco IOS: ip tcp adjust-mss 1380 under ingress interface PIX: sysopt connection tcp mss Copyright Printed in USA.

30 Look Ahead Fragmentation (LAF) Fragmentation after IPSec requires reassembly on the receiving router Take the packet, look ahead by adding 84 bytes (max. ESP header size) If > path MTU size, then fragment before IPSec Early tests show, pre-frag increases performance on 7200VXR receiver from 12mb/s to 70mb/s Re-assembly now done on end host To enable: Crypto IPSec df-bit clear Crypto IPSec fragmentation before-encryption Cisco IOS/ VPNSM VPN GRE over IPSec MTU Considerations Fragmentation GRE fragments before encapsulation IPSec fragments after encryption Can get double fragmentation: Reassembly by IPSec peer and end host Solution: Set GRE interface IP MTU IPSec transport mode ip mtu 1440 IPSec tunnel mode ip mtu 1420 Use tunnel path-mtu-discovery under GRE interface so that PMTUd process will work after GRE Use LAF; the IP MTU of GRE tunnel interface will automatically adjusted 60 Copyright Printed in USA.

31 Quality of Service (QoS) in VPN Deployment Enable end-to-end QOS throughout the network Cisco VPN products preserve the TOS/DSCP bits after encryption QoS classification/marking must occur before encryption Challenges: QoS happens after IPSec on egress interface; some QoS mechanisms (Flow-based WFQ, PQ,CQ, CBWFQ) that classify traffic using L3/4 packet header info. no longer work when applied on egress interfaces Crypto engine is a FIFO queue; no priority associated with different classes of traffic 61 Cisco IOS VPN QoS Consideration: QoS Pre-classify Network Headers Crypto Engine QoS pre-classify preserves the Layer3/4 information before crypto engine QoS mechanism at egress interface used preserved header info to classify packets 62 Copyright Printed in USA.

32 IOS VPN QoS Consideration: Crypto Low Latency Queuing (LLQ) D v D D CB WFQ D D D D v v v v Best Effort LLQ v v Crypto Engine D v IP Data Traffic VOIP Traffic LLQ before crypto engine is designed to minimize voice latency and jitter Queuing occurs when crypto engine is congested 63 VPN Service Module (VPNSM) QoS Consideration VPNSM supports priority queuing with two priorities: High and Low Class of Service (CoS) is used to map traffic to VPNSM priority queues Use Cat6K MLS QoS to mark packets with CoS values 64 Copyright Printed in USA.

33 VPN QoS Consideration: VPN 3000 Concentrator Allows bandwidth reservation for site-to-site tunnels Traffic policing is available to police excess packets 65 NAT and Site-to-Site VPN One-to-one NAT in between IPSec peers: Works fine with IPSec ESP Does not work with IPSec AH (integrity check covers IP header) Port address translation (PAT) breaks IPSec Solution: IPSec NAT transparency (NAT-T) During IKE phase I negotiation, special NAT discovery payload is used to discover the existence of NAT and location of NAT device If there is NAT, encapsulate ESP packet as UDP payload (UDP/4500) ISAKMP NAT keepalive is sent to keep NAT entry from timeout. 66 Copyright Printed in USA.

34 Compression and VPNs Aids in path MTU issues LZS can be used for layer 3 compression over VPNs; to enable add the comp-lzs IPSec transform to the transform set The compression ratio will vary dramatically depending on the traffic undergoing compression The LZS implementation has a maximum 2:1 compression ratio IPCP-LZS in software runs in process mode and creates significant CPU overhead Some crypto hardware accelerator cards support LZS in hardware (VAM) Layer 2 compression has no effect on IPSec traffic 67 Agenda Applications of Site-to-Site IPSec VPNs Design Considerations Deployment Scenarios Fine Tuning Site-to-Site Deployment High Availability Management Case Study 68 Copyright Printed in USA.

35 High Availability Common High Availability (HA) practice in conjunction with IPSec HA features Design options Local HA via link resiliency Local HA via Hot Standby Routing Protocol/Virtual Router Redundancy Protocol/failover Geographical HA via IPSec backup peers Local/geographical HA via GRE over IPSec (dynamic routing) VPN peer reachability detection mechanism IKE timer Routing protocol IKE keepalive/dpd GRE Tunnel keepalive 69 IKE Keepalive and Dead Peer Detection (DPD) Consideration IKE Keepalive ESP? DPD Used to clear stale IPSec SAs in the dead peer situation Must be enabled on both VPN peers Bi-directional, periodic keepalive between two peers Can cause high CPU usage on hub VPN device in large scale deployment; can scale up to 240 peers Used to clear stale IPSec SAs in the dead peer situation Can be configured to track on direction only Keepalive sent only in absence of VPN traffic Compared to IKE keepalive, more efficient and use less CPU 70 Copyright Printed in USA.

36 IPSec Local HA via Link Resiliency ISPs Link Resiliency: ISDN backup, backup frame Relay DLCI etc Choose multiple ISPs to achieve link diversity Use a loopback interface as the ISAKMP identity for the VPN router Failover mechanism: backup interface, dialer watch, floating static routes 71 IPSec Local HA Using HSRP/VRRP Remote HSRP Internet HE-2 VPN Head-End VPN HE-1 VRRP Corporate Intranet Available in Cisco IOS Active-active failover Reverse route injection (RRI) is required for the hosts behind HSRP routers to track tunnel states VRRP supported by VPN 3000 concentrator PIX failover is similar to VRRP mechanism Active-standby failover 72 Copyright Printed in USA.

37 Local HA Using HSRP/VRRP:IOS HSRP and RRI (1) SA Established To Primary Sending IKE Keepalives (2) Router P RRI: I can reach Remote Internet P (3) /24 via P Head-End /24 (8) /24 via S S (6) New SA Established To Secondary (5) Secondary Active Sending IKE Keepalives (7) Router S RRI: I can reach = Unscheduled Immediate Memory Initialization Routine (4) HSRP is enable on outside (WAN facing) interface Cisco IOS IPSec HA enhancement features: Allow IPSec use HSRP Virtual IP as the peer address Reverse route injection (RRI) injects IPSec remote proxy IDs into dynamic routing process 73 IOS HSRP and RRI Configuration crypto isakmp keepalive 10 crypto map vpn 10 IPSec-isakmp set peer set transform-set myset match address 101 reverse-route interface Ethernet1/0 ip address standby 1 ip standby 1 priority 200 standby 1 preempt standby 1 name VPNHA standby 1 track Ethernet1/1 150 crypto map vpn redundancy VPNHA interface Ethernet1/1 ip address router ospf 1 redistribute static subnets network area 0 access-list 101 permit ip Copyright Printed in USA.

38 Cisco IOS IPSec Stateful Failover inbound esp sas: spi: 0xB57000DA( ) transform: esp-des esp-md5- hmac, in use settings ={Tunnel, } slot: 100, conn id: 2000, flow_id: 1, crypto map: vpn sa timing: remaining key lifetime (k/sec): ( /663) IV size: 8 bytes replay detection support: Y P SSP S inbound esp sas: spi: 0xB57000DA( ) transform: esp-des esp-md5-hmac, in use settings ={Tunnel, } slot: 100, conn id: 2000, flow_id: 1, crypto map: vpn sa timing: remaining key lifetime (k/sec): ( /3489) IV size: 8 bytes replay detection support: Y HA Status: STANDBY IPSec stateful failover greatly improves failover time compared to the stateless IPSec/HSPR failure State Synchronization Protocol (SSP) is designed to sync ISAKMP and IPSec SA database between HSRP active and standby routers Use a dedicated link between the two HSRP routers for SSP exchange 75 Cisco IOS IPSec HSRP Stateful Failover Configuration ssp group 10 remote redundancy IPSec_HA crypto isakmp ssp 10 crypto ipsec transform-set myset esp-3des espmd5-hmac crypto map vpn ha replay-interval inbound 10 outbound 1 crypto map vpn 10 IPSec-isakmp set peer set transform-set myset match address 101 reverse-route interface Ethernet1/0 ip address standby 10 ip standby 10 preempt standby 10 name IPSec_HA standby 10 track Ethernet1/3 50 crypto map vpn ssp 10 access-list 101 permit ip Copyright Printed in USA.

39 Geographic HA Using IPSec Backup Peers Branch Office ISPs Corporate Network crypto isakmp keepalive 20 3 crypto map vpn 10 ipsec-isakmp set peer set peer set transform-set myset match address During IKE negotiation, IKE timer (3 retries) detects the peer failure IKE keepalive or DPD detected failed peer after tunnel is established1 77 Local/Geographical HA Using GRE over IPSec (dynamic Routing) San Jose Branch Internet Corporate Network h1 h2 s1 Geographical HA New York s2 Primary Tunnel Secondary Tunnel Local HA with Redundant Hub Design Except under failure conditions: The IPSec and GRE tunnels are always up since routing protocols are always running The remote sites always have two apparent paths to all networks available via the head-end Use dynamic routing for path selection and failover 78 Copyright Printed in USA.

40 Redundant Hubs in Action Initial Build A H1 33% S1: P H1 S H2 S2: P H1 S H3 H2 33% S3: P H2 S H1 S4: P H2 S H3 H3 33% S5: P H3 S H1 S6: P H3 S H2 79 Redundant Hubs in Action After Failure H1 33% 50% S1: P H1 S H2 S2: P H1 S H3 H2 33% 0% S3: P H2 S H1 S4: P H2 S H3 H3 33% 50% S5: P H3 S H1 S6: P H3 S H2 80 Copyright Printed in USA.

41 Site-to-Site High Availability Summary Key: CK = Cisco-type IKE Keepalives; DPD = Dead Peer Detection; HA = High Availability; RP = Routing Protocol; DPD is preferred over CK; BP= IPSec backup peer Head-end Remote Device Device Cisco IOS/VPNSM Cisco IOS RP/GRE (IKE peers); HSRP+ (IKE peer), DPD/CK, RRI/HSRP (RP/HSRP back-end)/bp PIX 3000 DPD/CK/BP DPD/CK, RRI (RP back-end)/bp PIX Firewall HSRP+ (IKE peer), DPD/CK, RRI/HSRP (RP/HSRP back-end)/bp DPD/CK/BP DPD/CK, RRI (RP back-end)/bp VPN3000 HSRP+ (IKE peer), DPD/CK, RRI/HSRP (RP/HSRP back-end)/bp DPD/CK/BP DPD, RRI (RP back-end)/bp 81 Agenda Applications of Site-to-Site IPSec VPNs Design Considerations Deployment Scenarios Fine Tuning Site-to-Site deployment High Availability Management Case Study 82 Copyright Printed in USA.

42 Managing VPN In order to manage remote devices via a VPN tunnel you should: Use static public IP addresses at remote sites and static crypto maps at the head-end Be aware that some services do not always use the public IP address as the source address (e.g. TFTP) IPSec information is available via syslog (minimal) or the IPSec MIB via SNMP (IOS, 3000) 83 VPN Management Best Practices Manage out-of-band Use dedicated management interfaces if possible If not possible, use VPN for secure management and restrict access over the tunnel to management protocols only When managing a VPN device via a VPN: Use strong authentication, integrity, and encryption Use a different username for configuration management and troubleshooting If you cannot use IPSec, use SSH/SSL 84 Copyright Printed in USA.

43 VPN Management Applications Device Managers (on the box) PDM PIX Device Manager VDM VPN Device Manager for Cisco IOS SDM Security Device Manager for Cisco IOS Multi-Device Managers (off the box) Cisco IOS, IDS, PIX, 3000 Management Consoles VPN Monitor VPN Solutions Center (service provider provisioning tool) 85 Agenda Applications of Site-to-Site IPSec VPNs Design Considerations Deployment Scenarios Fine Tuning Site-to-Site deployment High Availability Management Case Study 86 Copyright Printed in USA.

44 Company Profile: Existing Infrastructure 200 Employee company Frame Relay and ISDN are used to interconnect remote offices Currently has 15 Remote sites, growing to 50+ in the near future VPN Design Goals Use Internet VPN to replace WAN to save cost Migrating from FR environment, requires some level of assurance of service availability Flexible design to accommodate future growth 87 Current Traffic Profile Internet Access T-1 line, Firewall and Edge/ISP Router Head-End: ~1.5Mbps throughput HTTP, FTP and other traffic Frame-Relay Network Head-End: ~5 Mbps throughput Remote Sites: 56/64K T1, ~1Mbps throughput Intranet Services: Database, HTTP, FTP, Mail etc PSTN Network Head-End: Access Server PRI Lines Remote Sites: 128K ISDN 88 Copyright Printed in USA.

45 Current Network Topology Internet Head Quarter PSTN Frame Relay Cloud Remote Sites 89 Design Considerations Checklist I IP Addressing and Routing Private IP addressing used for VPN All spoke sites has static routable IP addresses Dynamic routing required GRE Over IPSec Security Use firewall in front of VPN devices Device Authentication Limited remotes sites IKE Pre-shared Key Cryptographic options 3DES encryption with data integrity and authentication 90 Copyright Printed in USA.

46 Design Considerations Checklist II High Availability Multiple Head End devices Routing protocol (EIGRP) is used for convergence, transparent to end user Migration Utilize existing Internet connection for site-to-site IPSec VPN Upgrade existing Internet connection to accommodate added VPN traffic Dynamic routing needed to distinguish between Internet and intranet traffic 91 Design Considerations Checklist III Device Sizing and Scalability (Head End and Remote): Number of branches ~ VPN Tunnels No. of Head End Devices = [ no. Tunnels/240 ]+1)=2 Throughput per branch ~ 0.75Mbps Aggregated head-end VPN throughput: 0.75*50 35Mbps A Traffic throughput and CPU utilization Branch device CPU utilization is considered at 65% 2 Tunnels (Primary and Secondary) Product selection Head End: C7200 NPE-G1 with VAM Remote Sites: C1700 C3600 with encryption modules 92 Copyright Printed in USA.

47 VPN Design P S Central Site Internet Remote Sites 93 Conclusions Cost Saving Monthly cost to subscribe to Internet Initial equipment cost is re-captured by monthly savings Deploy VPN enabled routers (including DSL and other features) DSL and/or cable-free install by some ISP Scalability Minimal downtime during failover Use of DSL and/or cable technology Flexible Design Future growth and resiliency with multiple links and additional hub sites 94 Copyright Printed in USA.

48 Flexible VPN Design to Accommodate Future Growth San Jose Atlanta VPN A-P VPN B-S VPN A-S VPN B-P Internet VPN Z -S VPN Z-P Site A Site B Corporate Network Multiple Hub Sites Site Z Remote VPN Sites 95 For More Information c/technologies.shtml 96 Copyright Printed in USA.

49 Recommended Reading CCSP Cisco Secure VPN Exam Certification Guide ISBN: Network Design Principles and Practices ISBN: CCIE Exam Certification Guide: Security ISBN: Available on-site at the Cisco Company Store 97 Please Complete Your Evaluation Form Session 98 Copyright Printed in USA.

50 99 Appendix 100 Copyright Printed in USA.

51 Appendix GRE Over IPSec Configuration GRE Over IPSec: Redundant Hub Configuration VPN Scalability Test Results 101 GRE over IPSec: Network Layout /24.2 H Rh Internet Rs Rs /24 H /24.2 H3 102 Copyright Printed in USA.

52 IPSec + GRE Hub and Spoke Hub Configuration Transport Mode Dynamic Crypto Map ACL Entries GRE Hub to Spokes crypto ipsec transform-set trans2 esp-3des esp-md5-hmac mode transport crypto dynamic-map vpndyn 10 set transform-set trans2 match address 110 crypto map vpnmap local-address Ethernet4 crypto map vpnmap 10 ipsec-isakmp dynamic vpndyn interface Ethernet0 ip address interface Ethernet4 ip address crypto map vpnmap access-list 110 permit grehost host access-list 110 permit grehost host IPSec + GRE Hub and Spoke Hub Configuration (Cont.) GRE Tunnel Interfaces 1 per Spoke IP MTU EIGRP for Dynamic Routing interface Tunnel11 ip address ip mtu 1440 tunnel source Ethernet4 tunnel destination crypto map vpnmap interface Tunnel12 ip address ip mtu 1440 tunnel source Ethernet4 tunnel destination crypto map vpnmap router eigrp 1 network network no auto-summary 104 Copyright Printed in USA.

53 IPSec + GRE Hub and Spoke Spoke1 Configuration Transport Mode Static Crypto Map ACL Entry GRE Spoke to Hub crypto ipsectransform-set trans2 esp-3des esp-md5-hmac mode transport crypto map vpnmap2 local-address Ethernet1 crypto map vpnmap2 10 ipsec-isakmp set peer set transform-set trans2 match address 120 access-list 120 permit gre host host IPSec + GRE Hub and Spoke Spoke1 Configuration (Cont.) GRE Tunnel Interface IP MTU EIGRP for Dynamic Routing interface Tunnel0 ip address ip mtu 1440 tunnel source Ethernet1 tunnel destination crypto map vpnmap2 interface Ethernet0 ip address interface Ethernet1 ip address crypto map vpnmap2 router eigrp 1 network network no auto-summary 107 Copyright Printed in USA.

54 IPSec + GRE Hub and Spoke Spoke Configuration crypto isakmp policy 1 authentication pre-share crypto isakmp key cisco47 address crypto ipsec transform-set trans2 esp-3des esp-md5-hmac mode transport crypto map vpnmap2 local-address Ethernet1 crypto map vpnmap2 10 ipsec-isakmp set peer set transform-set trans2 match address 110 interface Ethernet0 ip address interface Ethernet1 ip address crypto map vpnmap2 interface Tunnel0 ip address ip mtu 1440 tunnel source Ethernet1 tunnel destination crypto map vpnmap2 router eigrp 1 network network no auto-summary ip route access-list 110 permit gre - host host IPSec + GRE Hub and Spoke Spoke2 Configuration Transport Mode Static Crypto Map ACL Entry GRE Spoke to Hub crypto ipsectransform-set trans2 esp-3des esp-md5-hmac mode transport crypto map vpnmap2 local-address Ethernet1 crypto map vpnmap2 10 ipsec-isakmp set peer set transform-set trans2 match address 120 access-list 120 permit gre host host Copyright Printed in USA.

55 IPSec + GRE Hub and Spoke Spoke2 Configuration (Cont.) GRE Tunnel Interface IP MTU EIGRP for Dynamic Routing interface Tunnel0 ip address ip mtu 1440 tunnel source Ethernet1 tunnel destination crypto map vpnmap2 interface Ethernet0 ip address interface Ethernet1 ip address crypto map vpnmap2 router eigrp 1 network network no auto-summary 110 IPSec + GRE Hub and Spoke Spoke2 Configuration crypto isakmp policy 1 authentication pre-share crypto isakmp key cisco47 address crypto ipsec transform-set trans2 esp-3des esp-md5-hmac mode transport crypto map vpnmap2 local-address Ethernet1 crypto map vpnmap2 10 ipsec-isakmp set peer set transform-set trans2 match address 110 interface Ethernet0 ip address interface Ethernet1 ip address crypto map vpnmap2 interface Tunnel0 ip address ip mtu 1440 tunnel source Ethernet1 tunnel destination crypto map vpnmap2 router eigrp 1 network network no auto-summary ip route access-list 110 permit gre - host host Copyright Printed in USA.

56 IPSec + GRE Routing Tables Hub Spoke1 Spoke2 C /28 is directly connected, Ethernet4 C /30 is directly connected, Tunnel12 C /30 is directly connected, Tunnel13 C /24 is directly connected, Ethernet0 D /24 [90/ ] via , 00:12:30, Tunnel11 D /24 [90/ ] via , 00:12:28, Tunnel12 S* /0 [1/0] via C /24 is directly connected, Ethernet1 C /30 is directly connected, Tunnel0 D /30 [90/ ] via , 00:18:39, Tunnel0 D /24 [90/ ] via , 00:18:39, Tunnel0 C /24 is directly connected, Ethernet0 D /24 [90/ ] via , 00:18:40, Tunnel0 S* /0 [1/0] via C /24 is directly connected, Ethernet1 D /30 [90/ ] via , 00:21:53, Tunnel0 C /30 is directly connected, Tunnel0 D /24 [90/ ] via , 00:21:53, Tunnel0 D /24 [90/ ] via , 00:21:54, Tunnel0 C /24 is directly connected, Ethernet0 S* /0 [1/0] via GRE over IPSec: Redundant Hubs S1: P H1 S H2 H1 33% S2: P H1 S H3 H2 33% S3: P H2 S H1 S4: P H2 S H3 H3 33% S5: P H3 S H1 S6: P H3 S H2 113 Copyright Printed in USA.

57 Redundant Hubs Base Hub Configuration ACL Definitions on Later Slide Hub s External IP Address Primary and Secondary Networks crypto ipsec transform-set trans2 esp-3des esp-md5-hmac mode transport crypto dynamic-map vpndyn 10 set transform-set trans2 match address 110 crypto map vpnmap local-address Ethernet4 crypto map vpnmap 10 ipsec-isakmp dynamic vpndyn interface Ethernet0 ip address <x> interface Ethernet4 ip address <hub(x)> crypto map vpnmap router eigrp 1 network network network Redundant Hubs Hub1 Configuration: Tunnels Primary GRE Tunnels Bandwidth Controls Routing Secondary GRE Tunnels interface Tunnel11 ip address bandwidth 1000 tunnel source <hub1> tunnel destination <spoke1> crypto map vpnmap interface Tunnel12 ip address bandwidth 1000 tunnel source <hub1> tunnel destination <spoke2> crypto map vpnmap interface Tunnel13 ip address bandwidth 500 tunnel source <hub1> tunnel destination <spoke3> crypto map vpnmap interface Tunnel15 ip address bandwidth 500 tunnel source <hub1> tunnel destination <spoke5> crypto map vpnmap 115 Copyright Printed in USA.

58 Redundant Hubs Hub2 Configuration: Tunnels Secondary GRE Tunnel Primary GRE Tunnels Secondary GRE Tunnel interface Tunnel11 ip address bandwidth 500 tunnel source <hub2> tunnel destination <spoke1> crypto map vpnmap interface Tunnel13 ip address bandwidth 1000 tunnel source <hub2> tunnel destination <spoke3> crypto map vpnmap interface Tunnel14 ip address bandwidth 1000 tunnel source <hub2> tunnel destination <spoke4> crypto map vpnmap interface Tunnel16 ip address bandwidth 500 tunnel source <hub2> tunnel destination <spoke6> crypto map vpnmap 116 Redundant Hubs Hub3 Configuration: Tunnels Secondary GRE Tunnel Primary GRE Tunnels interface Tunnel12 ip address bandwidth 500 tunnel source <hub3> tunnel destination <spoke2> crypto map vpnmap interface Tunnel14 ip address bandwidth 500 tunnel source <hub3> tunnel destination <spoke4> crypto map vpnmap interface Tunnel15 ip address bandwidth 1000 tunnel source <hub3> tunnel destination <spoke5> crypto map vpnmap interface Tunnel16 ip address bandwidth 1000 tunnel source <hub3> tunnel destination <spoke6> crypto map vpnmap 117 Copyright Printed in USA.

59 Redundant Hubs Hub Configuration: ACLs Hub1: Hub2: Hub3: access-list 110 permit gre host <hub1> host <spoke1> access-list 110 permit gre host <hub1> host <spoke2> access-list 110 permit gre host <hub1> host <spoke3> access-list 110 permit gre host <hub1> host <spoke5> access-list 110 permit gre host <hub2> host <spoke3> access-list 110 permit gre host <hub2> host <spoke4> access-list 110 permit gre host <hub2> host <spoke1> access-list 110 permit gre host <hub2> host <spoke6> access-list 110 permit gre host <hub3> host <spoke5> access-list 110 permit gre host <hub3> host <spoke6> access-list 110 permit gre host <hub3> host <spoke2> access-list 110 permit gre host <hub3> host <spoke4> 118 Redundant Hubs Spoke1 Configuration Primary Crypto Map Secondary Crypto Map IPSec and GRE Peers Match crypto ipsec transform-set trans2 esp-3des esp-md5-hmac mode transport crypto map vpnmap2 local-address Ethernet1 crypto map vpnmap2 10 ipsec-isakmp set peer <hub1> set transform-set trans2 match address 121 crypto map vpnmap2 20 ipsec-isakmp set peer <hub2> set transform-set trans2 match address 122 access-list 121 permit grehost <spoke1> host <hub1> access-list 122 permit grehost <spoke1> host <hub2> router eigrp 1 network network network no auto-summary 119 Copyright Printed in USA.

60 Redundant Hubs Spoke1 Configuration (Cont.) Primary GRE Tunnel Secondary GRE Tunnel interface Tunnel0 ip address bandwidth 1000 tunnel source <spoke1> tunnel destination <hub1> crypto map vpnmap2 interface Tunnel1 ip address bandwidth 500 tunnel source <spoke1> tunnel destination <hub2> crypto map vpnmap2 interface Ethernet0 ip address interface Ethernet1 ip address <spoke1> crypto map vpnmap2 120 Redundant Hubs Spoke2 Configuration Primary Crypto Map Secondary Crypto Map IPSec and GRE Peers Match crypto ipsec transform-set trans2 esp-3des esp-md5-hmac mode transport crypto map vpnmap2 local-address Ethernet1 crypto map vpnmap2 10 ipsec-isakmp set peer <hub1> set transform-set trans2 match address 121 crypto map vpnmap2 20 ipsec-isakmp set peer <hub3> set transform-set trans2 match address 122 access-list 121 permit grehost <spoke2> host <hub1> access-list 122 permit grehost <spoke2> host <hub3> router eigrp 1 network network network no auto-summary 121 Copyright Printed in USA.

61 Redundant Hubs Spoke2 Configuration (Cont.) Primary GRE tunnel Secondary GRE tunnel interface Tunnel0 ip address bandwidth 1000 tunnel source <spoke2> tunnel destination <hub1> crypto map vpnmap2 interface Tunnel1 ip address bandwidth 500 tunnel source <spoke2> tunnel destination <hub3> crypto map vpnmap2 interface Ethernet0 ip address interface Ethernet1 ip address <spoke2> crypto map vpnmap2 122 VPN Scalability: Test Setup GRE Over IPSec with 500 spokes Test traffic includes FTP, DNS, HTTP, POP3, TN3270, and VoIP Yields conservative design target NOTE: Throughput numbers are valid for our specific design configuration; other designs may produce different results 123 Copyright Printed in USA.

62 Scale Test Results Branches Scale Test (Mbps) 830 (VPN Mod) (VPN Mod) XM (AIM) (AIM-II) (AIM-II) 15 Head-ends /VAM /VAM G1/VAM /7600/VPNSM (AIM-II) (AIM-II) Gbps 124 Copyright Printed in USA.