580 likes | 779 Views
Deploying and Managing Enterprise IPsec VPNs. Ken Kaminski Cisco Systems Consulting Systems Engineer – Security/VPN Northeast kkaminsk@cisco.com. Security Enforcement, Firewall, IDS Network Topology Routing (OSPF, EIGRP) design High Availability Performance QoS Path MTU Discovery
E N D
Deploying and Managing Enterprise IPsec VPNs Ken Kaminski Cisco Systems Consulting Systems Engineer – Security/VPN Northeast kkaminsk@cisco.com
Security Enforcement, Firewall, IDS Network Topology Routing (OSPF, EIGRP) design High Availability Performance QoS Path MTU Discovery Network Management ............. IPsec - more than just crypto !
Agenda • IPsec Design Options • IPsec Design Issues • IPsec Management
Product Function Matrix Site-to-Site Role Remote Access Role With recent addition of Cisco VPN Client now supported with good feature set Primary Role Full fledged Site-to-Site IOS Scales for large deployments PDM 2.0 includes VPN management Integrated firewall and VPN device PIX Not recommended for large-scale use due to lack of QOS, SLA monitoring, and multiprotocol routing Primary Role Full fledged remote access solution 3000
Agenda • IPsec Design Options • IPsec • IPsec Remote Access (EzVPN) • IPsec/GRE • IPsec Design Issues • IPsec Management
Basic IPsec Example 2.2.2.2 10.1.2.0/24 1.1.1.1 Internet 10.1.1.0/24 10.1.3.0/24 3.3.3.3 • IKE Policy (Phase I) crypto isakmp policy 1 authentication pre-shared hash sha encryption 3des crypto isakmp key cisco123isabadkey address 2.2.2.2 crypto isakmp key passwordisiabadkey address 3.3.3.3
Basic IPsec Example 2.2.2.2 10.1.2.0/24 1.1.1.1 Internet 10.1.1.0/24 10.1.3.0/24 3.3.3.3 • IPsec Policy (Phase II) crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac ! access-list 102 permit ip 10.1.1.0 0.0.0.255 10.1.2.0 0.0.0.255 access-list 103 permit ip 10.1.1.0 0.0.0.255 10.1.3.0 0.0.0.255
Basic IPsec Example 2.2.2.2 10.1.2.0/24 1.1.1.1 Internet 10.1.1.0/24 10.1.3.0/24 3.3.3.3 • IPsec Policy (Phase II) crypto map IPSEC 20 ipsec-isakmp set peer 2.2.2.2 match address 102 set transform-set ESP-3DES-SHA crypto map IPSEC 30 ipsec-isakmp set peer 3.3.3.3 match address 103 set transform-set ESP-3DES-SHA
Basic IPsec Example 2.2.2.2 10.1.2.0/24 1.1.1.1 Internet 10.1.1.0/24 10.1.3.0/24 3.3.3.3 • Apply Crypto Map interface serial 0 crypto map IPSEC ! ip route 10.0.0.0 255.0.0.0 serial 0
Basic IPsec Summary • Supported by IOS, Pix, VPN 3000 and several other vendors • Either side can initiate tunnel • No support for routing protocol, multicast
Agenda • IPsec Design Options • IPsec • IPsec Remote Access (EzVPN) • IPsec/GRE • IPsec Design Issues • IPsec Management
IPsec Remote Access (EzVPN) IOS PIX VPN 3K VPN Client ? 1.1.1.1 Internet Head office IOS PIX VPN 3002 ? • Client - Server Architecture • Client always initiates IPsec connection • Client may have dynamic ip address • Very easy to configure ! • Very scalable, no routing expertise required !
IPsec Remote Access (EzVPN) IOS Pix VPN 3K 1.1.1.1 Internet Head office ? • Client extension mode : • Packets from all devices behind EzVPN Client are PATted to • one ip address (then tunneled in IPsec). • Network extension mode : • Packets from all devices behind EzVPN client • are tunneled in IPsec (no PAT before IPsec)
EzVPN Configuration example ? 1.1.1.1 Internet Head office Remote Office ? crypto ipsec client ezvpn hw-client group engineering-1 key secret mode client peer 1.1.1.1 ! interface Ethernet1 description connected to INTERNET ip address ....... crypto ipsec client ezvpn hw-client
Agenda • IPsec Design Options • IPsec • IPsec Remote Access (EzVPN) • IPsec/GRE • IPsec Design Issues • IPsec Management
IPsec/GRE : Scalable Site-to-site VPNs Internet Frame Relay • Routing Protocol (OSPF, EIGRP...) necessary ! • Routing (or multicast) not specified by IPsec • Supported in IOS using GRE/IPsec
IPsec/GRE Example 2.2.2.2 ? 1.1.1.1 Internet ? ? 3.3.3.3 • IKE Policy (Phase I) crypto isakmp policy 1 authentication pre-shared hash sha encryption 3des crypto isakmp key cisco123isabadkey address 2.2.2.2 crypto isakmp key passwordisiabadkey address 3.3.3.3 Same as without GRE
IPsec/GRE Example 2.2.2.2 ? tunnel 2002 1.1.1.1 Internet ? ? tunnel 2003 3.3.3.3 IPsec Policy (Phase II) crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac mode transport access-list 102 permit gre host 1.1.1.1 host 2.2.2.2 access-list 103 permit gre host 1.1.1.1 host 3.3.3.3
IPsec/GRE Example 2.2.2.2 ? tunnel 2002 1.1.1.1 Internet ? ? tunnel 2003 3.3.3.3 crypto map IPSEC 20 ipsec-isakmp set peer 2.2.2.2 match address 102 set transform-set ESP-3DES-SHA crypto map IPSEC 30 ipsec-isakmp set peer 3.3.3.3 match address 103 set transform-set ESP-3DES-SHA
IPsec/GRE Example tunnel 2002 10.99.1.0/24 2.2.2.2 ? 1.1.1.1 Internet ? ? tunnel 2003 10.99.2.0/24 3.3.3.3 int tunnel 2002 ip address 10.99.1.1 255.255.255.0 tunnel source serial 0 tunnel destination 2.2.2.2 crypto map IPSEC int tunnel 2003 ip address 10.99.2.1 255.255.255.0 tunnel source serial 0 tunnel destination 3.3.3.3 crypto map IPSEC
IPsec/GRE Example tunnel 2002 10.99.1.0/24 2.2.2.2 ? 1.1.1.1 Internet ? ? tunnel 2003 10.99.2.0/24 3.3.3.3 int serial 0 ip address 1.1.1.1 255.255.255.252 crypto map IPSEC ! ip route 2.2.2.2 255.255.255.255 serial 0 ip route 3.3.3.3 255.255.255.255 serial 0 ! router ospf 1 network 10.0.0.0 0.255.255.255 area 1
IPsec/GRE Summary • IOS only (not Pix, VPN 3000) • Enables Routing over IPsec protected Tunnels • Enables IPsec protected multicast • Enables Multi-Protocol (IPX...) • Easy to configure thanks to trivial ACLs • Reduces the number of SAs • Uses standards : RFC 240x (IPsec), RFC 2784 (GRE) • IPinIP (RFC 2003) is an alternative to GRE
Agenda • IPsec Design Options • IPsec Design Issues • Topologies • High Availability • Split Tunneling • Device Placement • IPsec Management
Site-to-Site Full Mesh Internet • N * (N-1) / 2 tunnels • Scaling issues with provisioning and routing protocols • (....future Cisco features may help here...)
Dynamic Multipoint VPN (DMVPN) 12.2(13)T • Objective : Easy to configure full mesh IPsec VPN • Uses multi-point GRE interfaces • Uses NHRP (Next Hop Resolution Protocol) • Only configure hub connection • Spoke learns about spoke peer dynamically
= Dynamic&Temporary Spoke-to-spoke IPsec tunnels Dynamic Multipoint VPN - DMVPN 10.100.1.0 255.255.255.0 12.2(13)T 10.100.1.1 = Dynamic & Permanent spoke-to-hub IPsec tunnels 130.25.13.1 Static public IP address Dynamic (or static) public IP addresses 10.1.2.1 10.1.2.0 255.255.255.0 Spoke 10.1.1.1 10.1.1.0 255.255.255.0
Full Mesh :Tunnel Endpoint Discovery (TED) MPLS-VPN/ Frame Relay • Dynamically discover tunnel endpoint (peer) • IOS since 12.0T • Only works with routable (public) ip address • Must be enabled in all peer routers
Traffic to B must be protected No SA -> Block &Answer probe A to B must be protected No SA -> Send Probe IKE A to B (proxy X) IKE Y to X TED Example Alice Bob Y X IP: A to B Z Clive X(config)# crypto dynamic-map DYN 10 set transform-set ESP-3DES-SHA match address 100 ! crypto map IPSEC 99 ipsec-isakmp dynamic discover ! access-list 100 permit ip 10.1.1.0 0.0.0.255 10.0.0.0 0.255.255.255
IPsec Migration Today 0. - - 1. IPsec - time - no communication possible - 2. IPsec IPsec - all encrypted - Problem : Migration to IPsec in large networks
IPSEC Passive Mode 12.2(13)T 0. - - 1. passive - 2. passive passive time - now all router are on passive - 3. active passive 4. active active - now all router are running normal IPsec - # crypto ipsec optional
Agenda • IPsec Design Options • IPsec Design Issues • Topologies • High Availability • Split Tunneling • Device Placement • IPsec Management
High-Availability Design Stateless options today: • IPsec and Dead Peer Detection • IPsec and HSRP • IPsec/GRE : Routing Protocols HE-2 Remote VPN Internet 10.1.5.0 Corporate Intranet Head-End VPN HE-1
Dead Peer Detection (IKE keepalives) • Supported on IOS, Pix, VPN 3000, Cisco VPN Client • hellos are sent between IKE peers that have active tunnels established • Will detect dead peers (stale IPsec SAs) • On the third hello packet failure, IKE attempts to set up a new tunnel to the next peer in list VPN Client Head-End HE-2 R1 Corporate Intranet Internet S2 P1 Hello HE-1 S1 Hello Hello
Dead Peer Detection vs IKE keepalives • DPD is an optimization to IKE keepalives : "I don't bother to check peer by sending keepalive, if I am receiving data from peer" • DPD compatibility : IOS 12.2(8)T and later Pix 6.0 and later VPN 3000 3.0 and later
High Availability with Dead Peer Detection HE-2 1.1.1.2 Remote Internet Corporate Intranet X Head-End 1.1.1.1 HE-1 crypto map IPSEC 10 match address 10 set peer 1.1.1.1 set peer 1.1.1.2 set transform-set ESP-3DES-SHA
IPsec and HSRP+ HE-2 Remote Internet Corporate Intranet X Head-End HE-1 • Supported on IOS • HSRP address used as tunnel endpoint • Active device terminates IPsec tunnel • In the event of failure, standby device takes over (SAs will be renegotiated)
High Availability with IPsec and HSRP+ 1.1.1..3 HE-2 Remote Internet Corporate Intranet X HE-1 interface Ethernet1/0 ip address 1.1.1.1 255.255.255.248 standby 1 ip 1.1.1.3 standby 1 priority 200 standby 1 preempt standby 1 name VPNHA standby 1 track Ethernet1/1 150 crypto map VPN redundancy VPNHA crypto map IPSEC 10 match address 10 set peer 1.1.1.3 set transform-set ESP-3DES-SHA
Reverse Route Injection (RRI) • Because IOS is active-active, and it is not possible for the next-hop-device to know which router “has” the active tunnel, Reverse Route Injection (RRI) is required for state tracking • Works with DPD and HSRP+ • 12.2(8)T who should I send traffic to for 10.1.5.0 ? HE-2 Remote Internet Corporate Intranet 10.1.5.0 Head-End HE-1
Reverse Route Injection Example HE-2 crypto isakmp keepalive 10 ! crypto map vpn 20 ipsec-isakmp set peer 2.2.2.2 set transform-set ESP-3DES-SHA match address 102 reverse-route ! Remote Internet Corporate Intranet X Head-End 2.2.2.2 HE-1
RRI In Action RRI triggers when SA goes down • SA Established To Primary • Sending IKE Keepalives (2) Router P RRI:“I can reach 10.1.5.0” Remote P (3) 10.1.5.0/24 via P Internet Head-End (8) 10.1.5.0/24 via S 10.1.5.0/24 S (5) Secondary Active (6) New SA Established To Secondary Sending IKE Keepalives (7) Router S RRI:“I can reach 10.1.5.0” = Unscheduled Immediate Memory Initialization Routine (4)
High Availability with IPsec/GRE • Just plain routing ! (OSPF, EIGRP...) • Routing copes with some failures other methods can't detect • Local and Geographical redundancy possible • Except under failure conditions: • The IPsec and GRE tunnels are always up since routing protocols are always running HE-2 Remote Internet Corporate Intranet Head-End HE-1
High Availability with IPsec/GRE tunnel 2 HE-2 Remote Internet Corporate Intranet Head-End tunnel 1 HE-1 Remote : ! int tunnel 1 ...... ip ospf cost 10 ..... ! int tunnel 2 ...... ip ospf cost 20 ...... HE-2 ! int tunnel 2 ...... ip ospf cost 10 ..... HE-1 ! int tunnel 1 ...... ip ospf cost 10 .....
Local/Geographical Failover/Load-Balancing • The Cisco VPN Client supports the notion of backup servers for high availability • PIX, 3000, and IOS compatible • The 3000 Concentrator also supports local clustering • Supports local load sharing (not geographical) • DNS resolution based load balancing could also be used as the client resolves the FQDN of the head-end device (geographical)
High Availability Summary • Key: DPD = Dead Peer Detection; RP = Routing Protocol; RRI = Reverse Route Injection Head-end Device IOS PIX 3000 Remote Device RP DPD (RRI) HSRP+ (RRI) DPD(RRI) IOS DPD HSRP+ (RRI) DPD (RRI) DPD(RRI) PIX Failover DPD HSRP+ (RRI) DPD (RRI) DPD(RRI) 3000 DPD
Agenda • IPsec Design Options • IPsec Design Issues • Topologies • High Availability • Split Tunneling • Device Placement • IPsec Management
NAT for Internet traffic No NAT for corporate traffic Split Tunneling www.evilhackers.com VPN HW Split-Tunneling Enabled VPN Client Internet
Split Tunneling • Should it be allowed ? Policy Decision ! • If allowed, firewall is needed at remote end • Cisco VPN Client - $0 firewall Default stops incoming connections; allows outgoing connections Firewall active even when VPN client is not connected Firewall policies can be pushed from VPN 3000 concentrator
Agenda • IPsec Design Options • IPsec Design Issues • Topologies • High Availability • Split Tunneling • Device Placement • IPsec Management
VPN DMZ VPN Device with separate Firewall VPN Termination Focused Layer 4–7 Analysis Stateless L3 Filtering (IKE, ESP) To Campus To WAN Edge L4–L7 Stateful Inspection and Filtering DoS Mitigation Nothing To See (crypto-wise)
Agenda • IPsec Design Options • IPsec Design Issues • IPsec Management