47202018 crypto map based IPsec VPN fundamentals... -C'sco Support Community Cisco Support @ English stdealts Cisco Support Community Register Login This category i Q Search the Community Crypto map based IPsec VPN fundamentals - negotiation and configuration @ voc tsosiwicrss 19-12-2013 01:26 Al What is IPsec + IKE negotiation at a glance + Tunnel mode and transport mode. + Configuration + IKE + IPsec Troubleshooting + Show commands + Debugging + References This document will outline basic negotiation and configuration for crypto-map- based IPsec VPN configuration, hitpsssupporfocums. cisco comS!securiy-documents/cryplo-map-based-psec-vpr-furdamentals-negoition-andia-p/3153502 wn472072018 crypto map based IPsec VPN fundamentals... -C'sco Support Community This document is intended as an introduction to certain aspects of IKE and IPsec, it WILL contain certain simplifications and colloquialisms. What is IPsec IPsec is a standard based security architecture for IP hence IP-sec. IKE (Internet Key Exchange) is one of the ways to negotiate IPsec Security Associations (SAs), in particular case ISAKMP {implementation of IKE) is what. Cisco uses. Currently two versions of IKE exist 1. IKE version 1 (IKEv1) - the more common and older, widely deployed. This is what typically is used to around the world when IPsec is implemented. 2. IKE version 2 (IKEv2) - as the name suggests it a newer, more robust protocol. It's less widely deployed, however offers more and is quickly gaining traction. This document focuses mostly on IKEv1 and crypto map configuration, however most aspects are true for other types of frameworks. IKE negotiation at a glance To establish IKE Security Association (IKE SA or Phase 1) in a secure way peers will need to exchange certain information, those include + How to protect negotiation - hashing algorithm to use, encryption algorithm to se, Diffie-Hellman group (key length), desired IKE SA lifetime. + Diffie-Hellman exchange will need to be performed - establish a shared secret over insecure medium + Authentication - Peers exchange identities and authentication material (pre shared key or certificates, in a typical environment) hitpsssupporfocums. cisco comS!securiy-documents/cryplo-map-based-psec-vpr-furdamentals-negoition-andia-p/3153502 ane472072018 crypto map based IPsec VPN fundamentals... -C'sco Support Community Itis important to note that pre shared key is not actually exchanged, it is intended factored into the key protecting identity, Thus if the peer doesn't have the correct pre-shared key it will not be able to authenticate and finish phase 1 negotiation. IKE SA can be established via aggressive mode or main mode negotiation, this document covers Main Mode exchange which is the one typically deployed, Aggressive mode is the less secure of modes and is typically used in EZVPN with pre-shared key, where additional layer of security is provided by performing user authentication. Once IKE SA is established, the peers are ready to establish information about what traffic to protect and how to protect it. This will form an IPsec Security Association (SA) or phase 2, in an exchange called Quick Mode. Once quick mode is performed and IPsec SA exists and traffic is able to flow ina secured way. A visual aide to remember this by: hitpsssupporfocums. cisco comS!securiy-documents/cryplo-map-based-psec-vpr-furdamentals-negoition-andia-p/3153502 ant472072018 crypto map based IPsec VPN fundamentals... -C'sco Support Community IKE Policy Negotiation Diffie-Hellman (Temporal keys) a uel Reo eceuees <=> | At this stage it is important to remember, during normal operation, one IKE SA exists between peers. During rekey or re-negotiation multiple IKE SA can exist. However between two peers multiple IPsec SAs can exist. This concept is visualized here. eee Control Plane Data Plane local: 10.1.1.0224 Tooal: 102.2.0724 Protected networks: Inbound IPsec SA (SPI 0x1234ABCD) Protected networks: remote: 10.22.0724 EM cek rea) remote: 10.1.1.0124 EOE Petetinlccnice hitpsssupporfocums. cisco comS!securiy-documents/cryplo-map-based-psec-vpr-furdamentals-negoition-andia-p/3153502 ant472072018 crypto map based IPsec VPN fundamentals... -C'sco Support Community As the above diagram shows there are two IPsec SAs, identified by Security Parameter Index (SPI), present on a device for each direction, one for inbound traffic one for outbound traffic, It is also crucial to remember that inbound IPsec SA on left hand side device, if the outbound IPsec SA on right hand side device, and vice versa At this stage it is also worth to mention that “local” and "remote" networks are reversed on each end. This concept will come up again when performing configuration of “interesting traffic” later on. Tunnel mode and transport mode. When IPsec protects traffic, it has a couple of services and modes to choose from. + Authentication Service - protect and verify integrity of data - make sure data is not changed during transport. Using AH (Authentication Header) and IP protocol 51. « Encryption Services - data encryption - make sure nobody can eavesdrop on the data in transport. Using ESP (Encapsulating Security Payload) and IP protocol of 50. Second service is much more widely deployed. While it is possible to mix the two services, it is an very rare scenario, with limitated-or-no support on certain platforms. More is another concept which come up quite often with IPsec. Two modes exist: + Transport mode - preserving original IP header. Typically used in combination with GRE or other encapsulating protocols. + Tunnel mode - encapsulating entire IP datagram within a new header, essentially tunneling the packet. hitpsssupporfocums. cisco comS!securiy-documents/cryplo-map-based-psec-vpr-furdamentals-negoition-andia-p/3153502 snr472072018 crypto map based IPsec VPN fundamentals... -C'sco Support Community A mode which is the most common for most crypto map deployments is Encryption Services and tunnel mode, However let's have a look at an overview how each of those will work, First let's have a look at AH and ESP and how they tread original IP datagram, in this case some TCP data will be sent over. Authentication Header (AH) aH IP Data Packet a Urea 2 Authenticated Umea 2-1) \ Encapsulating Security Payload (ESP) ESP mz Encrypted | Authenticated , And now about how those IP protocols fit in the two modes. (AH) MH 82151) Transport Mode HE KEEN) Tunnel Mode Encapsulating Security Payload (ESP) y a Uae oe) 2 ENE transport Mode ety i BRA tunnet mode hitpsssupporfocums. cisco comS!securiy-documents/cryplo-map-based-psec-vpr-furdamentals-negoition-andia-p/3153502 en7472072018 crypto map based IPsec VPN fundamentals... -C'sco Support Community As pointed out the last mode is what is typically used with crypto map based IPsec VPNs, In this mode, RFC1918 addresses (or in fact any other IP address) can be sent over the Internet encapsulated in new IP header which will use addresses routable on the Internet. Configuration Now that basic theoretical concepts are introduced, this document will show how to map those into the actual crypto map based configuration. IKE + IKE negotiation protection: crypto isakmp policy 10 encr aes 256 authentication pre-share group 2 lifetime 28800 ISAKMP policy defines, what will be the means to authenticate, and how to protect negotiation , as well as how long and IKE SA will be alive before re- negotiation (by default it's one day). Those parametrs need to agree on both ends of the tunnel. + IKE authentication In previous section the means to authenticate was specified, here the configuration creates notion of the actual pre-shared key to be used to authenticate the peer. In this case it has value of “test” crypto keyring MY_KEYRING local-address Loopback2 pre-shared-key address [Link] [Link] key test hitpsssupporfocums. cisco comS!securiy-documents/cryplo-map-based-psec-vpr-furdamentals-negoition-andia-p/3153502 m7472072018 crypto map based IPsec VPN fundamentals... -C'sco Support Community + ISAKMP profile This profile binds together features used by IKE and IPSec, it will be later on referenced in IPsec section, in crypto map configuration. crypto isakmp profile MY_PROFILE [vrf MY_IVRF] keyring MY_KEYRING match identity address [Link] self-identity address local-address Loopback2 In this case the profile sprecifies that any (wildcard [Link]) identity of type “address” should fall under this profile. It is important to mention that we're discussing about peer IDENTITY, in this case peer of type address with value of "any" is matched. Self-identity statement tells this router to use it's own identity of type address when performing authentication Optionally, in case of VRF-ware IPsec, this is where IVRF (in this case MY_IVRF) is referenced. It is also important to note that our identity (self-identity) is what the remote peer will have to match in their ISAKMP profile. In a classic exampe if we send our identity as address, the remote peer will have to match identity of type "address" We've covered: 1. How to protect IKE negotiation 2, How to authenticate ourselves and peer. The Diffie-Hellman keys (and other parameters, or VIDs) are exchanged automatically and rarely require much configuration. IPsec hitpsssupporfocums. cisco comS!securiy-documents/cryplo-map-based-psec-vpr-furdamentals-negoition-andia-p/3153502 anr472072018 crypto map based IPsec VPN fundamentals... -C'sco Support Community As in case of IKE certain parameters need to be exchanged for IPsec SAs to be established, Also as in case of ISAKMP profile we will introduce a central component of crypto map. + IPsec transform set. As discussed previously a device needs to know how to protect traffic, this is where transform set comes into play. It defines what hashing and encryption algorithm is to be used to protect traffic. crypto ipsec transform-set MY_SET esp-3des esp-sha-hmac In this case 3DES and SHA were chosen For guidance and recommendations on current best practices about chosing the right algorithms refer to: [Link] + Traffic selection Crypto maps use traffic selection mechanism in form of access-list. The access-list is always defined from local perspective, i.e. Cisco devices will use an access-list which will select (using permit statement) traffic from X to Y and on it's peer the access-list will be mirrored selecting traffic from Y to X. It is important to note that this is one of the things checked/enforced during negotiation. access-list 10@ permit ip [Link] @[email protected] any In this case router will be interested to encrypt all traffic from [Link]/24 subnet. The remote end will used access-list specifying the reverse "any to [Link]/24" (or use dynamic crypto map!) = Crypto map Crypto map is a feature binding all the information we discussed before in this, section and previous together. hitpsssupporfocums. cisco comS!securiy-documents/cryplo-map-based-psec-vpr-furdamentals-negoition-andia-p/3153502 snr472072018 crypto map based IPsec VPN fundamentals... -C'sco Support Community A few facts about crypto map. 1. One crypto map can be applied to an interface 2. Same crypto map can be applied to multiple interfaces 3. To accommodate multiple tunnels crypto map entries are used. One crypto map can have multiple entries, identified by a number. 4, Static crypto map can reference a dynamic crypto map. The two crypto map types discussed and their usage: + Static crypto map - identifies peer and traffic to be encrypted explicitly. Typically used to accommodate a few tunnels with different profiles and characteristics (different partners, sites, location) + Dynamic crypto map - is one of the ways to accomodate peers sharing same characteristics (for example multiple branches offices sharing same configuration) or peers having dynamic IP addressing (DHCP, etc.) crypto map MY_CRYPTO_MAP 100 ipsec-isakmp set peer [Link] set transform-set MY_SET set isakmp-profile MY_PROFILE match address 100 Looking at this example, Crypto map names MY_CRYPTO_MAP has entry 100 using ISAKMP to negotiate IPsec. This crypto map entry should match traffic specified by access-list 100 and perform parameters defined in ISAKMP profile called MY_PROFILE. The way to protect traffic is defined in transform set MY_SET. When performing IKE negotiation, packets should be sent to peer [Link] hitpsssupporfocums. cisco comS!securiy-documents/cryplo-map-based-psec-vpr-furdamentals-negoition-andia-p/3153502 s0n7472072018 crypto map based IPsec VPN fundamentals... -C'sco Support Community A crypto map (by name) is then applied to an interface. r2itsh run int €1/0 Building configuration. Current configuration : 80 bytes interface Ethernet1/0 ip address [Link] [Link] crypto map MY_CRYPTO_MAP end Troubleshooting When troubleshooting both show and debug commands should be used. Show commands + show crypto isakmp sa - shows status of IKE session on this device. r2t#sh crypto isa sa IPva Crypto ISAKMP SA dst src state conn-id status [Link] [Link] QM_IDLE 1004 ACTIVE In this case there's only one session and it's in state "ACTIVE" + show crypto ipsec sa - shows status of IPsec SAs. Crucial information to look for, what traffic is being protected, from what IVRF (protected VRF) and if hitpsssupporfocums. cisco comS!securiy-documents/cryplo-map-based-psec-vpr-furdamentals-negoition-andia-p/3153502472072018 crypto map based IPsec VPN fundamentals... -C'sco Support Community IPsec SAs (or SPls) are in active state. r2ttsh crypto ipsec sa interface: Ethernet1/0 Crypto map tag: MAP, local addr [Link] protected vif: (none) local dent (addr/mask/prot/port): 1192.168.0.0/[Link]/256/0) remote kdent (addr/mask/prot/port): ([Link]/[Link]/256/0) current_peer [Link] port 500 PERMIT, flags={origin_is_acl,} Hpkts encaps: 5, tipkts encrypt: 5, Hpkts digest: 5 #pkts compressed: 0, #pkts decompressed: 0 fipkts not compressed: 0, Hpkts compr. failed: 0 #pkts not decompressed: 0, #pkts decompress failed: 0 #send errors 0, #recv errors 0 local crypto endpt.: [Link], remote crypto endpt.: [Link] path mtu 1500, ip mtu 1500, ip mtu idb Ethernet1/0 current outbound spi: OxDFDE17CA(3755874250) PFS (Y/N): N, DH group: none hitpsssupporfocums. cisco comS!securiy-documents/cryplo-map-based-psec-vpr-furdamentals-negoition-andia-p/3153502 van7472072018 crypto map based IPsec VPN fundamentals... -C'sco Support Community inbound esp sas: ‘spi: Ox205F6BE9(543124457) transform: esp-aes esp-sha-hmac , in use settings ={Tunnel, } conn id: 13, flow_id: SW:13, sibling_flags 80000040, crypto map: MY_CRYPTO_MAP sa timing: remaining key lifetime (k/sec): (4335214/3551) IV size: 16 bytes replay detection support: Y ‘Status: ACTIVE(ACTIVE) inbound ah sas: inbound pep sas: outbound esp sas: ‘spi: OxDFDE17CA(3755874250) transform: esp-aes esp-sha-hmac , in use settings ={Tunnel, } conn id: 14, flow_id: SW:14, sibling_flags 80000040, crypto map: MY_CRYPTO_MAP sa timing: remaining key lifetime (k/sec): (4335214/3551) IV size: 16 bytes replay detection support: Y Status: ACTIVE(ACTIVE) hitpsssupporfocums. cisco comS!securiy-documents/cryplo-map-based-psec-vpr-furdamentals-negoition-andia-p/3153502 san7472072018 crypto map based IPsec VPN fundamentals... -C'sco Support Community outbound ah sas: ‘outbound pep sas: In the above case traffic between local [Link]/24 (in global VRF) to remote 192.168. 1.0/24 is protected and remote peer is [Link] There are two IPsec SAs active (one in each direction) and we processed total of 5 packets in each direction + show crypto session - shows a at a glance view of different tunnels on this device. r2Hsh crypto session Crypto session current status Interface: Ethemet1/0 Sessfon status: UP-ACTIVE Peer; [Link] port 500 IKEv1 SA: local [Link]/500 remote [Link]/500 Active IPSEC FLOW: permit ip 192.168,0.0/255,255,255.0 192,168, 1.0/[Link] Active SAs: 2, origin: crypto map Show crypto session offers at-a-glance view of information gathered already with previous commands. hitpsssupporfocums. cisco comS!securiy-documents/cryplo-map-based-psec-vpr-furdamentals-negoition-andia-p/3153502 van7472072018 crypto map based IPsec VPN fundamentals... -C'sco Support Community Peer IP address, what is the protected traffic and how many active SAs are present, This situation is from a working tunnel. Debugging To narrow down debugging to one peer conditional debugging should be used. On IOS this is done by performing: debug crypto condition peer ipva .... ‘Two major component can be debugged + debug crypto isakmp - information specific to ISAKMP exchange. This will contain information about main mode and quick mode negotiation. + debug crypto ipsec - some phase 2 specific information can be found here. References + VRF-aware IPsec cheatsheet [Link] 13524 + Understanding main mode debugs: [Link] [Link]! [Link] 18522 Tags: asa crypto encryption ike ike_protocols los_vpn_—_ psec. ipsec_vpn (*) 14 Helpful hitpsssupporfocums. cisco comS!securiy-documents/cryplo-map-based-psec-vpr-furdamentals-negoition-andia-p/3153502 1sn7472072018 crypto map based IPsec VPN fundamentals... -C'sco Support Community COMMENTS eC anikettate150 Community Member 08-07-2017 04:1 Correction of IP protocol + Authentication Service - AH (Authentication Header) and IP protocol 51 + Encryption Services - ESP (Encapsulating Security Payload) and IP protocol of 50. 08-07-2017 04:2 Of course you're correct. Reference: [Link] Unfortunately I can't rate your answer, the rating button is not available :{ Top Tags VIEW ALL troubleshoot pix_500 configuration asa_5500 asa vpn psec _error_message pix6x vpn_client pix_7.x asa_7.x _connectivity_issues acs _acs_windows hitps:[Link]!securty-documents/cryplo-map-based-psec-vpr-fundamentals-negoiation-anda-p/3153502 16n747202018 crypto map based IPsec VPN fundamentals. vpn_concentrator aaa upgrade firewall tac radius ios_vpn ssi_vpn asdm acs_solution_engine ® e6663 * viens » 2 COMMENTS Recommended & How to configure PFS with IPSec VPN % @ Border Gateway Protocol (BGP) Fundament... % Ga B& Crypto Licensing information % @ tunnel protection & crypto map Dik & In Crypto map-based with ivrf Top 8oO8ca Contacts Privacy Statement Feedback Cookie Policy Site Map Trademarks: Terms & Conditions Help ticati Cisco Support Community n— security anyconnect 14 HELPFUL ToC_2% Vinit Jain si Jason Gervia i: zhagin Abaji Rawool i: pws Uithium: tft ‘cisco hitps:[Link]!securty-documents/cryplo-map-based-psec-vpr-fundamentals-negoiation-anda-p/3153502 wir