IPSec VPNs

Transform Set: esp-aes

128-bit

sh crypto ipsec sa peer 192.168.4.2

192.168.4.2 is the IP address of the outside interface of the destination peer Displays the details of the IPSec SAs (active or not) to the peer specified

IP Protocol ID: ESP

50

IP Protocol ID: AH

51

SPI (Security Parameter Index)

A "serial number" for tracking the security association (SA) between a router and its peer. There is one for the outbound tunnel R1>R2 and one for the inbound tunnel R2>R1 Inbound SPI on R1 is the Outbound SPI on R2 and vice versa

PSK (Pre Shared Key)

A password that both parties know. Used to authenticate since only the person you told the password to should be able to provide it. Not scalable for large deployment Is NOT used for encryption. Is ONLY used for authentication

ISAKMP HAGLE: Encryption

AES, DES, 3DES, SEAL

sh crypto isakmp sa: AG_AUTH

Aggressive Mode. The peers have authenticated the SA

sh crypto isakmp sa: AG_NO_STATE

Aggressive Mode. The peers have created the SA, but nothing else has occurred

sh crypto isakmp sa: AG_INIT_EXCH

Aggressive Mode. The peers have negotiated SA parameters and exchanged keys

IKEv1 Phase 1 Tunnel Modes

Aggressive: Faster, but less secure Main Mode: Slower, but more secure. The default method

IKEv1 Phase 2 Process

All transform-sets are sent to the remote peer

Split Tunneling

Allows a VPN tunnel to determine which traffic flows should be encrypted

Transparent Tunneling

Allows a VPN tunnel to form through a firewall or NAT device

MOBIKE

Allows mobile users to roam and change IP addresses without disconnecting their IPSec VPN session

ESP Trailer

Always encrypted Components: Padding Pad Length Next Header

ISAKMP Policy Authentication Commands and Types

authentication rsa-sig RSA Signatures authentication rsa-encr RSA nonces authentication pre-share Pre-shared Keys (PSK)

ISAKMP HAGLE: Authentication Method

Certificates, PSK

Remote Access VPN Process

Cisco AnyConnect client creates a virtual NIC that is assigned an IP by the VPN Gateway at the main site from a pool of addresses that will work with the IP addresses at the main site. All traffic then filters through the virtual NIC via the process that follows: Cleartext packet arrives at virtual NIC Fingerprint (hash) is created via hashing algorithm and attached to end of packet The entire packet is encrypted (including original IP header and fingerprint) ?

IKEv2 Process: CREATE_CHILD_SA

Creates a child SA Each Crypto ACL references one IPSec SA (AKA one instance of traffic originating from source A and heading to destination B) If there is more than one line in a Crypto ACL, then CREATE_CHILD_SA exchanges are used to negotiate additional IPSec SAs

ESP IPSec Transport Mode (Site-to-Site)

Is not the default mode. Needs to be specified in the crypto ipsec transform-set command Only the payload is encrypted and then encapsulated in an ESP header and trailer. The ESP trailer, as always, is also encrypted. The original IP header is moved outside of the ESP header/trailer and has the destination IP of the server.

Crypto ACL & Crypto Maps

Defines "interesting traffic", AKA which traffic should be transmitted via the VPN Applied to a crypto map (not an interface) So what this means is that it checks traffic in both the inbound and outbound direction. When checking traffic in the outbound direction the crypto ACL functions as normal. When checking traffic in the inbound direction, the source and destination are swapped. So if the crypto ACL has the source as 10.0.1.0 0.0.0.255 and the destination as 10.0.2.0 0.0.0.255 then on the way outbound the crypto ACL will check for that type of traffic, but on the way INBOUND it is reversed. So, instead it will check for traffic with a source of 10.0.2.0 0.0.0.255 and destination of 10.0.1.0. It's important to note that this DOES not change the ACL, it just changes the way the ACL is processed. If inbound traffic is received that matches the crypto ACL and the traffic is unencrypted, then the traffic will be dropped

sh crypto isakmp policy

Displays HAGLE settings for Phase 1 tunnel including the default ones If you see AES without an argument, it is 128-bit AES Troubleshooting: Run this command on both routers and look for mismatched parameters If the default value is specified in a policy, it will not show in running config (since it was never entered) and can only be displayed with sh crypto isakmp policy

sh crypto map

Displays the crypto ACL, transform set, peer IP, security-association lifetime, and PFS setting that has been applied to the crypto map. Displays the interface that the crypto map has been applied to

IKEv2

Documented in one RFC as opposed to the many spread out RFCs that document IKEv1 Faster and more efficient SA establishment than IKEv1 Does not have phases like IKEv1 does Faster rekeys Supports NAT Traversal Supports DPD (Dead Peer Detection) Supports First Contact (Initial Contact Support) Stronger security features than IKEv1 (Such as DDOS protection) More reliable than IKEv1 through the use of sequence Numbers, Acknowledgements, and Error Correction Supports EAP for authentication Supports MOBIKE

IPSec Authentication: RSA Encrypted Nonces

Does not use a PKI; Hardcodes the public key of each peer manually in the VPN gateway config Not common because it is tedious to configure and error prone

sh crypto isakmp sa: Deciphering the Output

Dst is the destination peer outside interface IP address Src is the local peer outside interface IP address State is related to the progress of the phase 1 negotiation Status is related to the VPN High Availability Status where "Active" = Active participant in tunnel communication and "Standby" = This router is in standby mode

Full Site-to-Site IPSec VPN Configuration via IOS CLI

Ensure that the ACLs that are currently in place are compatible with IPSec Allow Phase 1 ISAKMP (UDP Port 500) access-list 102 permit udp host 172.30.2.2 host 172.30.1.2 eq isakmp 172.30.1.2 is the outside interface of your VPN device 172.30.2.2 is the outside interface of the remote VPN peer eq isakmp means UDP port 500 This ACL is applied to the outside interface of your local VPN device in the inbound (ingress) direction You can then swap the source and destination IPs in the ACL and that can be the ACL that will be applied to the outside interface of the remote VPN peer in the inbound direction Allow NAT between VPN peers (Known as non500-ISAKMP or NAT traversal) (UDP Port 4500) access-list 102 permit udp host 172.30.2.2 host 172.30.1.2 eq non500-isakmp Allow ESP or AH (Depending on what your VPN was configured for) ESP access-list 102 permit esp host 172.30.2.2 host 172.30.1.2 AH access-list 102 permit ah host 172.30.2.2 host 172.30.1.2 Configure an ISAKMP Policy (Reference the quizlet on this) Configure IPSec Transform Set (Reference the quizlet on this) Configure Mirror Image Crypto ACLs (Reference the quizlet on this) Configure Crypto Map (Reference the quizlet on this) Create a routing policy to send traffic destined for the VPN network to the interface that the crypto map is applied to. (Reference quizlet on this: Correct Routing for IPSec Site-to-Site VPNs)

Key Management

Ensures that both peers have compatible keys Via DH, ECDH, IKE, IKEv2

HAGLE and the defaults

Hashing: SHA (160-bit SHA-1) Authentication Method: RSA Signature (Digital Certificates) DH Group: Group #1 (768 bit) Lifetime: 86,400 seconds (one day) Encryption: DES (56-bit)

ISAKMP HAGLE: Lifetime

How long until the tunnel is torn down and forced to rekey for continued communication (Defaults to one day, 86,400 seconds) The remote peer's lifetime must be equal to or less than the local peer. If the peers have different lifetime values, and the remote peer's lifetime is equal to or less than the local peer, then the shorter lifetime will be chosen

IKEv2 Process

IKE_SA-INIT IKE_AUTH CREATE_CHILD_SA

IPv6 IPSec

IPSec is native to IPv6, creating a new protocol header specifically for authentication and confidentiality to IPv6 packets You can encapsulate IPv6 in IPv4 header so that you can then send the IPv6 traffic over an IPv4 VPN

Crypto Map

If then statement that watches traffic in both the inbound and outbound direction. Is applied to the outside interface You can only have one crypto map per interface References Crypto ACL (Which data to be transmitted via the VPN) References Transform Set (How that data will be protected) References IPSec peer (Where to send the protected data) References lifetime (Optional. 3600 seconds [1 hour] is the default) (Does not have to match, but probably should) Must match the IPSec peer's Crypto Map: Each peer must have a mirror crypto ACL of the other peer's crypto ACL At least one transform-set set in common Must identify the other peer by its outside interface

sh crypto ipsec sa

If you see an entry in here, then you know that the tunnel has formed, but not necessarily that it is functional (It could've been configured incorrectly) Displays established IPSec SAs (at the bottom) Displays the interface the crypto map is applied to and what the address of that interface is "local ident" and "remote ident" shows what traffic is being encrypted local crypto endpt and remote crypto endpt shows the IP addresses of the outside interfaces of the routers Shows whether PFS (Port Forward Secrecy) is enabled or not and which DH group it is using shows anti-replay support and its status Displays outbound and inbound SPIs

sh crypto isakmp key

If you've chosen PSK (Pre-Shared Keys) for Phase 1 HAGLE authentication, you can see what the string value of the key is for each peer IP address Output crypto isakmp key KeyForSite3Site4 address 192.168.4.2 KeyForSite3Site4 is the key 192.168.4.2 is the peer IP address

ESP IPSec Tunnel Mode (Site-to-Site)

Is the default mode The entire IP packet (IP header and payload, Source IP address of the source host's physical NIC, destination address of the server on the destination network) is encrypted and then encapsulated in an ESP header and trailer. The ESP trailer is encrypted, the ESP header is not. A new IP header (Source IP address of the outside interface of the source network peer, destination IP address of the outside interface of the destination network peer) with an IP protocol ID of either 50 (ESP) encapsulates everything (ESP Header and Trailer, Original IP Header, and payload). If the packet were to be intercepted at this point, only the source and destination VPN endpoint IPs will be viewable. Also, they wil be able to tell that it is an IPSec packet. A keyed (using a shared secret since ESP uses HMAC) hash of the ESP packet (ESP trailer + data + original IP header + ESP header [This does not include the new IP header]) is created. The keyed hash is added to a newly created ESP Auth header which is then prepended to the ESP information that was just hashed. Once the traffic reaches the remote VPN peer, the ESP header/trailer, Original IP Header, and payload are authenticated by verifying that the keyed hash in the ESP Auth header matches the keyed hash created by the remote VPN peer (This is done before decryption, since the hashing was performed after the encryption when the entire packet was originaly created. Also, this lessons the impacts of DDOS, since you can drop a packet before having to waste time decrypting it). The new IP header is ripped off to reveal the ESP header . The ESP header is then ripped off and the entire packet is decrypted, to reveal the original IP packet which has the destination IP of the server.

Main Mode

Is the default mode Three exchanges between peers (One extra exchange compared to aggressive mode) Exchange 1: Negotiate IKE policy (Determine encryption and hashing algorithms, DH Group, Lifetime, and Peer Authentication Method) that will be used for the ISAKMP SA Initiator says I've got these ISAKMP policies (Sometimes referred to as an ISAKMP proposal. Basically, it is a specific HAGLE configuration). Pick one. Responder looks through its list of ISAKMP policies from top to bottom (top to bottom refers to the numerical order of the numbers specifying the policies. I.e. crypto isakmp policy 110) trying to match with the ISAKMP policies of the initiator from top to bottom. Once there is a match, the responder chooses that policy as the acceptable policy and replies back. If there is no match, then negotiations fail Exchange 2: DH Key Exchange (At the end of this, both peers now have the same symmetrical key) Peer 1 sends some numbers Z to Peer 2. Peer 2 uses its private nonce and the peers random numbers Z to create a public nonce which is then provided back to Peer 1. Peer 1 now does the same thing (uses random numbers Z with its private nonce to create a public nonce and provides it to Peer 2.) Peer 2 uses the number it just received from peer 1, does some math to it, which creates a symmetrical key Peer 1 uses the number it received from peer 2, does some math to it, which creates the same symmetrical key Exchange 3: Peer Authentication (Now that the communication is encrypted (via the symmetrical keys), you can authenticate without worrying about someone else stealing the preshared key used to authenticate) Uses PSK (Pre-shared Key), RSA Digital Signatures, or ECDSA If peer authentication fails, Phase 1 ISAKMP SA is terminated If peer authentication passes, Phase 1 ISAKMP SA is established and can be used as a secure tunnel to negotiate the Phase 2 IPSec SA

AES

Is the most common IPSec encryption technology

ESP

Layer 4 protocol. Provides confidentiality (encryption), integrity, authentication, and protection against replay attacks More common than AH, since it provides encryption and AH doesn't Both encryption and authentication are OPTIONAL in ESP, but you must choose at least one of them

AH (Authentication Headers)

Layer 4 protocol. Provides integrity, authentication, and protection against replay attacks Generally not used because there is no confidentiality (encryption) Breaks when going through NAT - AH forces authentication of the IP header (whereas ESP does not), which is why AH breaks when going through NAT (because NAT will change the IP address and cause the authentication via the keyed hash to fail)

ISAKMP HAGLE: Hashing

MD5, SHA

sh crypto isakmp sa: MM_KEY_AUTH

Main Mode. The peers have authenticated the SA

sh crypto isakmp sa: MM_NO_STATE

Main Mode. The peers have created the SA, but nothing else has occurred

sh crypto isakmp sa: MM_SA_SETUP

Main Mode. The peers have negotiated Phase 1 SA parameters

sh crypto isakmp sa: MM_KEY_EXCH

Main Mode. The peers have performed a DH exchange and have generated a shared secret (symmetrical key)

IPSec VPN General Rules & Features

Most common type of VPN Supports site-to-site VPNs Suppports Cisco AnyConnect Client (For remote access VPNs) Supports clietnless SSL VPN (For remote access VPNs) Supports IOS devices and ASAs as endpoints of the VPN Generally IPSec VPN is more common for site-to-site VPNs and SSL VPNs are more common for remote access VPNs Provides Privacy (Confidentiality) - via encryption Provides Data Integrity - via HMAC (SHA-1, SHA-2, MD5) Provides Origin Authentication - PSK or Digital Certificates (via RSA Digital Signatures and ECDSA Digital Signatures) Provides key management -

IKEv2 Process: IKE_SA-INIT

Negotiates security parameters for the IKE_SA, sends nonces, and sends Diffie-Hellman values. Peers establish a secure channel after which all further communications are encrypted

ESP Header

Never encrypted Components: SPI Sequence Number

IPSec Authentication: ECDSA Signatures (Elliptical Curve)

New and not universally supported Uses a PKI the same as RSA signatures, but uses Elliptic Curve instead of RSA asymmetric algorithm More efficient and secure than RSA Signatures

EAP for authentication

Offers more flexibility by allowing different methods for authentication For example, the client could authenticate the server using certificates while the server authentications the client with a pre-shared key (PSK)

IKEv1 Phase 1

One bidirectional Phase 1 ISAKMP SA is established at the end of this Determines mode (Either main mode or aggressive mode) Goes through the process of the mode that was chosen

The three SAs in IKEv1

One bidirectional phase 1 ISAKMP SA (Used to securely negotiate the parameters of the IPSec SAs) Two unidirectional phase 2 IPSec SAs (One protecting data from Site1 to Site2, One protecting data from Site2 to Site1)

Mirror Image Crypto ACLs

Peer 1: access-list 110 permit ip 10.0.1.0 0.0.0.255 10.0.2.0 0.0.0.255 Peer 2: access-list 110 permit ip 10.0.2.0 0.0.0.255 10.0.1.0 0.0.0.255 References the internal IP address

sh crypto isakmp sa: QM_IDLE

Quick Mode. Indicates that IKE phase 1 has completed successfully and that there is an active IKE ISAKMP SA between the peers IKE SA has been authenticated THIS IS AN IKE PHASE 2 MODE

Nonce

Random number generated by a VPN peer

ISAKMP HAGLE: DH Group

Refers to the modulus size to use for the DH key exchange (The higher, the more secure, but also the more computationally expensive)

Security Association

Represents one of the Phase 1 or Phase 2 tunnels SAs are regularly terminated and replaced, IKE's key regeneration capability allows it to create a new set of keys for the replacement SA (This is known as key regeneration)

sh crypto isakmp sa detail

Show the encryption, hashing, and authentication methods, DH Group, and lifetime of currently active ISAKMP SA tunnels

sh crypto ipsec transform-set

Shows details about the transform set Transform set AES_SHA: { esp-128-aes esp-sha-hmac } will negotiate = { Tunnel, }, AES_SHA is the name of the transform set esp-128-aes specifies encryption via esp using aes 128-bit encryption algorithm esp-sha-hmac specifies integrity authentication via esp using sha hmac will negotiate = Tunnel specifies that it will opt for tunneling mode as opposed to transport mode

sh crypto isakmp sa

Shows status of Phase 1 tunnel

IKEv1

Supports key regeneration Generally there are three SAs in IKEv1

Transform Set (Sometimes known as IPSec Proposals)

The hashing and encryption that will be used for the Phase 2 IPSec SAs (tunnels) Payload Encryption (Only through ESP, since AH does not encrypt): esp-des (56-bit) (DEFAULT) esp-3des (168-bit) [Effective key strength of 112-bit] esp-aes (128-bit) esp-aes-192 (192-bit) esp-aes-256 (256-bit) esp-null (Does not use encryption. Remember that encryption is optional for ESP) Payload Integrity Authentication (Through either ESP HMAC or AH HMAC): esp-md5-hmac esp-sha-hmac (DEFAULT) ah-md5-hmac ah-sha-hmac Tunnel Mode Transport Tunnel (DEFAULT) Transform sets work similar to ISAKMP policies in that you can configure multiple transform sets for one crypto map. You should configure the transform sets from most to least secure because the responding VPN peer will look at its transform sets and try to match it's most desirable (most secure) transform set first CLI: crypto ipsec transform-set nameOfTransformSet esp-des esp-sha-hmac mode tunnel

Quick Mode

The only mode available for IKEv1 Phase 2 Negotiates IPSec parameters

IKEv2 DDOS Protection

The responder requires that the initiator send it a cookie to validate who it is before it will keep a state or perform a DH operation (keeping a state or performing a DH operation are both computationally expensive). This cookie request response is not computationally expensive at all. Therefore, until an initiator can verify that it is legitimate, they can only perform a DOS to the extent that they can create a lot of cookies requests which, again, doesn't take up a lot of resources

IKEv1 Phase 2 Mandatory Criteria

Thee two communicating devices must contain compatible (mirror image) crypto ACLs. Thee two communicating devices must have at least one transform set in common. The two communicating devices must identify the other peer's outside interface IP address via the crypto map.

IKEv2 Process: IKE_AUTH

Transmits identities, proves knowledge of the secrets corresponding to the two identities, and sets up an SA for the first (and often only) AH and/or ESP CHILD_SA. Peers authenticate each other After completion, both peers now have an IPSec SA to protect tunnel traffic

Aggressive Mode

Two exchanges between peers (Faster negotiation and tunnel setup than main mode, but less secure because peer identities are sent unencrypted)

IKEv1 Phase 2

Two unidirectional IPSec SAs are established at the end of this Periodically renegotiates IPSec SAs to ensure security Optionally performs an additional DH exchange (If PFS is enabled) For IKE Phase 2 to work the following 3 criteria must be met: They must contain compatible (mirror image) crypto ACLs. They must have at least one transform set in common. They must identify the other peer.

Phase 1 ISAKMP Port

UDP Port 500

NAT between VPN peers (Known as non500-ISAKMP or NAT traversal)

UDP port 4500 NAT Traversal (NAT-T) allows you to use PAT on a VPN peer by encapsulating IPSec within UDP. UDP will provide the necessary source/destination ports that are required for PAT. IPSec by itself does not have source/destination ports

IPSec Authentication: RSA Signatures (Digital Certificates)

Used for authentication for an IPSec VPN Both peers enroll with the same PKI and then use identity certificates to exchange their public keys. They then prove that they have the private key for that pub/priv key pair. Scaleable for large deployment

DH Key Exchange

Used in IKEv1 Phase 1 Main Mode during the second exchange Someone eavesdropping between the peers cannot compute the same symmetrical key using the data that the peers share with each other in the DH key exchange Is computationally expensive, which is why DH is used to create symmetric keys which are less computationally expensive

IKEv1 Phase 2 Tunnel

Used to send encrypted traffic between the two routers

IKEv1 Phase 1 Tunnel

Used to send management traffic related to the VPN between the two routers (HAGLE)

IKEv1 Key Regeneration

When an IPSec SA expires due to the lifetime coming to an end, a replacement SA with new keying material is generated New keys can be based on original Phase 1 DH New keys can be based on new Phase 2 DH (Known as perfect forward secrecy (PFS), Considered more secure)

PFS (Perfect Forward Secrecy)

When enabled, performs an additional DH exchange which generates a new symmetrical key pair to be used in the Phase 2 tunnel (As opposed to using the DH symmetrical key pair from the Phase 1 tunnel). Is disabled by default. (Needs to be enabled)

Site-to-Site IPSec VPN Configuration via ASDM

Wizards > VPN Wizards > Site-to-Site VPN Wizard

Correct Routing for IPSec Site-to-Site VPNs

You must configure routing to ensure that all traffic destined for the the destination server/host/PC IP is sent out the interface that has the crypto map applied to it (This is most likely going to be the outside interface) ip route 10.0.2.0 255.255.255.0 s0/1 s0/1 specifies the outside interface that the crypto map is applied to 10.0.2.0 is the IP address of the destination server/host/PC

If you've chosen PSK (Pre-Shared Keys) for Phase 1 HAGLE authentication, you need to set the pre-shared key with this command

crypto isakmp key Secret1 address 172.30.1.2 OR crypto isakmp key Secret 1 hostname PeerRouter These must be consistent. Either use hostnames or IPs Pre-shared keys are easy to setup making them good for small businesses with simple VPNs, but they do not scale well for larger businesses with more complex VPN configurations

IKEv1 Phase 1 ISAKMP SA Configuration, ISAKMP Policy Configuration (HAGLE, crypto isakmp policy)

crypto isakmp policy 110 Assign most secure policy the lowest priority number to ensure that the most secure protocol is chosen (The lower the number, the higher the priority which means a lower priority number isakmp policy has the highest chance of being chosen) 110 is known as the priority number. (This is only locally significant and does not need to match between the peers) encryption aes 128 authentication pre-share group 5 lifetime 86400 Specified in seconds hash sha Used to specify the integrity hashing algorithm

Crypto Map Configuration & Explanation

crypto-map nameOfCryptoMap 10 ipsec-isakmp nameOfCryptoMap is only locally significant Ipsec-isakmp verifies that IKE will be used to create the IPSec SA 10 is the sequence number One crypto-map can have multiple entries (defined by different sequence numbers). In this configuration, you would have one sequence number per VPN peer. So if you had 3 VPN peers, you would have a separate sequence number for the IPSec settings of each VPN peer, but they would all be apart of the same crypto map (because you can only apply one crypto map per interface. So if you had multiple crypto maps, you wouldn't be able to apply them all to the outside interface of the router) match address 110 110 is the crypto ACL number set transform-set nameOfTransformSet set peer 172.16.1.1 References the IP of the outside interface of the peer You can reference a "backup" or "redundant" peer by setting 2 peers in the crypto map in the following manner: set peer 172.16.1.1 default set peer 172.16.2.1 Where "default" specifies the primary peer and the command without "default" in it specifies the backup or redundant peer You can configure as many redundant peers as you want to set security-association lifetime seconds 86400 (3600 seconds [1 hour] is the default) The security-association lifetime is optional (Does not have to match, but probably should) int s0/1 crypto map nameOfCryptoMap This needs to be applied to the outside interface of the router

ISAKMP Policy Encryption Commands and Types

encryption des 56-bit DES-CBC encryption aes 128-bit AES encryption aes 128 128-bit AES encryption aes 192 192-bit AES encryption aes 256 256-bit AES

Verify whether a crypto map has been applied to an interface or not

sh run int fa0/1