Tag Archives: 4.2a

4.2.a Implement and troubleshoot IPsec with preshared key

http://rayas-security.blogspot.com/2013/06/ipsec-vpn-main-mode-vs-aggressive-mode.html

4.2.a [i] IPv4 site to IPv4 site

IPSec between two sites such as branch and a headquarter is known as site to site or LAN to LAN tunnel. It can be configured with or without GRE. IKE has two modes of operation, aggressive or main mode. Main mode hides IKE/ IPSec peer identities.

Adam, Paul (2014-07-12). All-in-One CCIE V5 Written Exam Guide (Kindle Locations 4827-4829).  . Kindle Edition.

http://www.cisco.com/en/US/docs/ios-xml/ios/sec_conn_vpnips/configuration/xe-3s/sec-ipsec-virt-tunnl.html

4.2.a Implement and troubleshoot IPsec with preshared key

4.2.a [ii] IPv6 in IPv4 tunnels

Generic routing encapsulation (GRE) tunnels sometimes are combined with IPSec, because IPSec does not support IPv6 multicast packets. This function prevents dynamic routing protocols from running successfully over an IPSec VPN network. Because GRE tunnels do support IPv6 multicast , a dynamic routing protocol can be run over a GRE tunnel. Once a dynamic routing protocol is configured over a GRE tunnel, you can encrypt the GRE IPv6 multicast packets using IPSec.

IPSec can encrypt GRE packets using a crypto map or tunnel protection. Both methods specify that IPSec encryption is performed after GRE encapsulation is configured. When a crypto map is used, encryption is applied to the outbound physical interfaces for the GRE tunnel packets. When tunnel protection is used, encryption is configured on the GRE tunnel interface.

“% CRPTO-4-IKMP_BAD_MESSAGE: IKE” message from 150.150.150.1 failed its sanity check or is malformed appears if the pre-shared keys on the peers do not match. In order to fix this issue, check the pre-shared keys on both sides.

Adam, Paul (2014-07-12). All-in-One CCIE V5 Written Exam Guide (Kindle Locations 4860-4863).  . Kindle Edition.

http://www.cisco.com/en/US/docs/ios-xml/ios/sec_conn_vpnips/configuration/xe-3s/sec-ipv6-ipv4-gre.html

http://www.cisco.com/en/US/tech/tk583/tk372/technologies_tech_note09186a00800949c5.shtml#ike

4.2.a Implement and troubleshoot IPsec with preshared key

4.2.a [iii] Virtual tunneling Interface [VTI]

The use of IPsec VTIs both greatly simplifies the configuration process when you need to provide protection for remote access and provides a simpler alternative to using generic routing encapsulation (GRE) or Layer 2 Tunneling Protocol (L2TP) tunnels for encapsulation and crypto maps with IPsec. A major benefit associated with IPsec VTIs is that the configuration does not require a static mapping of IPsec sessions to a physical interface. The IPsec tunnel endpoint is associated with an actual (virtual ) interface. Because there is a routable interface at the tunnel endpoint, many common interface capabilities can be applied to the IPsec tunnel.

The IPsec VTI allows for the flexibility of sending and receiving both IP unicast and multicast encrypted traffic on any physical interface, such as in the case of multiple paths . Traffic is encrypted or decrypted when it is forwarded from or to the tunnel interface and is managed by the IP routing table. Using IP routing to forward the traffic to the tunnel interface simplifies the IPsec VPN configuration compared to the more complex process of using access control lists (ACLs) with the crypto map in native IPsec configurations. DVTIs function like any other real interface so that you can apply quality of service (QoS), firewall, and other security services as soon as the tunnel is active.

IPsec VTIs allow you to configure a virtual interface to which you can apply features. Features for clear-text packets are configured on the VTI. Features for encrypted packets are applied on the physical outside interface. When IPsec VTIs are used, you can separate the application of features such as NAT, ACLs, and QoS and apply them to clear-text or encrypted text, or both. When crypto maps are used, there is no simple way to apply encryption features to the IPsec tunnel.

There are two types of VTI interfaces:

● Static VTIs (SVTIs)

● Dynamic VTIs (DVTIs)

SVTI configurations can be used for site-to-site connectivity in which a tunnel provides always-on access between two sites. The advantage of using SVTIs as opposed to crypto map configurations is that users can enable dynamic routing protocols on the tunnel interface without the extra 4 bytes required for GRE headers , thus reducing the bandwidth for sending encrypted data. Additionally, multiple Cisco IOS software features can be configured directly on the tunnel interface and on the physical egress interface of the tunnel interface. This direct configuration allows users to have solid control on the application of the features in the pre- or post-encryption path.

DVTIs can provide highly secure and scalable connectivity for remote-access VPNs. The DVTI technology replaces dynamic crypto maps and the dynamic hub-and-spoke method for establishing tunnels. Dynamic VTIs can be used for both the server and remote configuration. The tunnels provide an on-demand separate virtual access interface for each VPN session. The configuration of the virtual access interfaces is cloned from a virtual template configuration, which includes the IPsec configuration and any Cisco IOS software feature configured on the virtual template interface, such as QoS, NetFlow, or ACLs.

Dynamic VTIs function like any other real interface so that you can apply QoS, firewall, other security services as soon as the tunnel is active. QoS features can be used to improve the performance of various applications across the network. Any combination of QoS features offered in Cisco IOS software can be used to support voice, video, or data applications.

Adam, Paul (2014-07-12). All-in-One CCIE V5 Written Exam Guide (Kindle Locations 4896-4898).  . Kindle Edition.

http://www.cisco.com/en/US/docs/ios/12_3t/12_3t14/feature/guide/gtIPSctm.html

4.2.a Implement and troubleshoot IPsec with preshared key

from the horse’s mouth:

http://www.cisco.com/en/US/docs/security/security_management/cisco_security_manager/security_manager/4.1/user/guide/vpipsec.html#wp961876

To define an IKE proposal, you must specify:

A unique priority (1 through 65,543, with 1 the highest priority).

An encryption method for the IKE negotiation, to protect the data and ensure privacy.

A Hashed Message Authentication Codes (HMAC) method (called integrity algorithm in IKEv2) to ensure the identity of the sender, and to ensure that the message has not been modified in transit.

For IKEv2, a separate pseudo-random function (PRF) used as the algorithm to derive keying material and hashing operations required for the IKEv2 tunnel encryption. The options are the same as those used for the hash algorithm;

A Diffie-Hellman group to determine the strength of the encryption-key-determination algorithm. The device uses this algorithm to derive the encryption and hash keys. 

An authentication method, to ensure the identity of the peers.

A limit to the time the device uses an encryption key before replacing it.

ie: h a g l e
R8(config)#crypto isakmp enable
R8(config)#crypto isakmp policy 10
R8(config-isakmp)#hash ?
md5     Message Digest 5
sha     Secure Hash Standard
sha256  Secure Hash Standard 2 (256 bit)
sha384  Secure Hash Standard 2 (384 bit)
sha512  Secure Hash Standard 2 (512 bit)R8(config-isakmp)#hash sha
R8(config-isakmp)#authenti ?
pre-share  Pre-Shared Key
rsa-encr   Rivest-Shamir-Adleman Encryption
rsa-sig    Rivest-Shamir-Adleman SignatureR8(config-isakmp)#authenti pre-share
R8(config-isakmp)#group ?
1   Diffie-Hellman group 1 (768 bit)
14  Diffie-Hellman group 14 (2048 bit)
15  Diffie-Hellman group 15 (3072 bit)
16  Diffie-Hellman group 16 (4096 bit)
19  Diffie-Hellman group 19 (256 bit ecp)
2   Diffie-Hellman group 2 (1024 bit)
20  Diffie-Hellman group 20 (384 bit ecp)
24  Diffie-Hellman group 24 (2048 bit, 256 bit subgroup)
5   Diffie-Hellman group 5 (1536 bit)

R8(config-isakmp)#group 5
R8(config-isakmp)#lifetime ?
<60-86400>  lifetime in seconds

R8(config-isakmp)#lifetime 3600
R8(config-isakmp)#encry ?
3des  Three key triple DES
aes   AES – Advanced Encryption Standard.
des   DES – Data Encryption Standard (56 bit keys).

R8(config-isakmp)#encry aes 256
R8(config-isakmp)#

 

4.2.a Implement and troubleshoot IPsec with preshared key

from CCNP Security
VPN 642-648
Quick Reference by christian matei

■ The Phase 1 goal is to establish a secure and authenticated management channel (called the control channel) by using Diffie-Hellman (DH) exchange so that Phase 2 negotiations can occur securely. Phase 1 can operate in main mode or aggressive mode, and it results in one bidirectional IKE SA.
■ The Phase 2 goal is to negotiate and establish IPsec SAs that will protect IP traffic, this being the final scope. It is done over the secure channel created in Phase 1, and session encryption keys are derived from the Phase 1 master key or by using a  separate D-H exchange if Perfect Forward Secrecy (PFS) is enabled. Phase 2 can operate in quick mode or GDOI mode (used only by GETVPN on IOS routers), and it results in a minimum of two unidirectional SAs (one inbound and one outbound).

phase 1 sets up a secure authenticated control channel… phase 2 establishes ipsec sa’s to protect the traffic…