Ccnp security(simos)

CCNP Security(SIMOS)

Pretty Good Privacy(PGP)

• Email and file encryption system based on public key cryptography.

• Uses a concept call trusted introducing.

Trusted Introducer

Two Ways To Use PKI To Secure Messages

• They can digitally sign the messages for authenticity and integrity with their own private key as the sender and verify the signature with the corresponding private key as the receiver.

• They can encrypt the message with the public key of the other party, and the receiver will decrypt the message with its own private key.

Steps For User A And C To Communicate Securely

1. User B digitally signs the public key of user A (which it has locally) and sends it to user C.

2. User C can then verify the signature of user B (because it has the public key of user B) and can consider the public key of user A to be authentic.

3. User B digitally signs the public key of user C (which it has locally) and sends it to user A.

4. User A can then verify the signature of user B (because it has the public key of user B) and consider the public key of user C to be authentic.

Group Encrypted Transport VPN• Large-scale, connectionless, tunnel-free

transmission protection.

• Used with Multiprotocol Label Switching (MPLS), IP, Frame Relay, and ATM networks.

• Ideal cryptographic solution for MPLS VPNs that need site-to-site encryption.

• Uses the concept of “trusted” group members.

Group Controller/Key Servers• Authenticates all group members.

• Performs admission control to the GET VPN domain.

• Creates and supplies group authentication key as security associations (SA) to group members

• Distribute keys and policies to all registered and authenticated group member routers.

Group Members

• Provide transmission protection to sensitive site-to-site (member-to-member) traffic.

• All communication between a key server and group members is encrypted and secured using the Internet Key Exchange (IKE) Group Domain of Interpretation (GDOI) protocol.

GET VPN Key Server And Group Member

IKE GDOI Keys

• TEK: A key that is used to protect traffic between group members.

• KEK: A key this is used to protect rekeys (during a key refresh) between key servers and group members.

GET VPN Traffic Exchange• GET VPN group members that have valid group

IPsec SAs assume that traffic they encrypt can be decrypted by some other legitimate GET VPN group member.

• The group member encrypts the multicast data, with header preservation, and the packet is switched out of the router.

• The replication of the multicast packet is performed in the core based on the source and multicast group IP address

Packet Security Services

• Packet confidentiality using cryptographic encryption algorithms such as AES or 3DES.

• Packet integrity and authenticity using cryptographic HMAC.

• Cisco-proprietary time-based (instead of sequence number–based) antireplay protection mechanism.

Differences between GDOI and IKE

• GDOI IKE SAs do not need to linger between members after initial establishment, but they can be quickly expired after a group member has authenticated to the key server and obtained the group policy.

• GDOI IKE sessions do not get established between all peers in a VPN, only between each group member and the key server.

Rekeying Consideration

• If most of the group members are only unicast capable, use unicast rekeying.

• If most of the group members are capable of multicast and the entire enterprise network is capable of multicast, use multicast rekeying.

Unicast Vs Multicast Rekeying

Unicast MulticastUse if infrastructure isonly unicast capable

Must have multicast-capable infrastructure

Requires rekey acknowledgment

Retransmits the keyseveral times withoutacknowledgments

Might requireadjustment of routerbuffers and queues ifthere are a large numberof peers

Fastest and mostscalable method

GET VPN Benefits

• Very scalable in that the configuration does not grow significantly when adding group members in a full mesh.

• Provides scalable support for multicast traffic.

GET VPN Limitation

• VPN addresses must be routable in the transport network. This is because of the use of the original IP header, and in most cases, it prevents GET VPNs from being used over the Internet.

• The compromise of one peer has a larger effect because the group shares session keys.

• Key servers must be available during rekeys and registration for the entire network to operate

IPSec IKEv1

• Needs a pre-shared key for skey calculation, which is used in order to decrypt/encrypt Main Mode packet 5 (MM5) and subsequent IKEv1 packets.

• The skey is derived from the Diffie-Hellman (DH) computation and the pre-shared key.

• That pre-shared key needs to be determined after MM3 (responder) or MM4 (initiator) is received, so that the skey, which is used in MM5/MM6, can be computed.

Keyring Selection CriteriaInitiator Responder

Multiple keyringswith different IPaddresses

Configured. If notexplicitly configuredthe most specific fromthe configuration

The most specificmatch

Multiple keyringswith the same IPaddresses

Configured. If notexplicitly configuredthe first matchingfrom the configuration

The first matchingfrom configuration

ASA IKEv1 Configurationasa1(config)#crypto ikev1 policy 1

asa1(config-ikev1-policy)#authentication pre-share

asa1(config-ikev1-policy)#encryption aes

asa1(config-ikev1-policy)#hash sha

asa1(config-ikev1-policy)#group 2

asa1(config-ikev1-polocy)#lifetime 86400

asa1(config)#crypto ikev1 enable outside

asa1(config)#crypto ipsec ikev1 transform-set ikev1-set esp-aes esp-sha-hmac

ASA IKEv1 Configurationasa1(config)#access-list ikev1-list extended permit ip 192.168.1.0 255.255.255.0 172.16.1.0 255.255.255.0asa1(config)#tunnel-group 10.10.10.2 type ipsec-l2lasa1(config)#tunnel-group 10.10.10.2 ipsec-attributesasa1(config-tunnel-ipsec)#ikev1 pre-shared-key this_is_a_keyasa1(config)#crypto map ikev1-map 1 match address ikev1-listasa1(config)#crypto map ikev1-map 1 set peer 10.10.10.2

ASA IKEv1 Configuration

asa1(config)#crypto map ikev1-map 1 set ikev1 transform-set ikev1-setasa1(config)#crypto map ikev1-map interface outside

ASA IKEv2 Configuration

tunnel-group 172.16.1.1 type ipsec-l2ltunnel-group 172.16.1.1 ipsec-attributes

ikev2 remote-authentication pre-shared-key <PRESHARED KEY>

ikev2 local-authentication pre-shared-key <PRESHARED KEY>

Sequence Crypto Map

Crypto Map Seq_No_1 deny packets from A.3 to B deny packets from A.3 to C permit packets from A to B permit packets from A to C Crypto Map Seq_No_2 permit packets from A.3 to B permit packets from A.3 to C

Using Dynamic Crypto Maps

Peers with dynamically assigned public IP addresses.

Both LAN-to-LAN and remote access peers can use DHCP to obtain a public IP address. The ASA uses this address only to initiate the tunnel.

Peers with dynamically assigned private IP addresses.

Peers requesting remote access tunnels typically have private IP addresses assigned by the headend. Generally, LAN-to-LAN tunnels have a predetermined set of private networks that are used to configure static maps and therefore used to establish IPsec SAs.

DMVPN Models• Hub-and-spoke: A hub-and-spoke DMVPN

requires that each branch (spoke) have a point-to-point GRE interface that is used to build a tunnel to the hub router.

• Spoke-to-spoke: A spoke-to-spoke DMVPN requires that each branch (spoke) have an mGRE interface through which dynamic spoke-to-spoke tunnels are used for spoke-to-spoke traffic. This model provides a scalable configuration for all involved devices and also provides direct spoke-to-spoke communication.

DMVPN Benefits• Hub router configuration reduction:– The DMVPN feature allows you to create a single

mGRE tunnel interface and a single IPsec profile, and does not require crypto ACLs on the hub router.

• Automatic IPsec initiation: – GRE relies on NHRP to configure and resolve peer

destination addresses.

• Support for spoke routers configured with dynamic addressing: – DMVPNs allow spoke routers to have dynamic

interface IP addresses and to use NHRP to register the spoke router’s interface IP address with the hub router.

Building Block Of DMVPN• mGRE: mGRE allows a single Generic Routing

Encapsulation (GRE) interface to support multiple GRE tunnels as GRE support IP multicast and non-IP protocols to traverse the interface as well.

• NHRP: The NHRP database maintains mappings between the router (public, physical interface) and the tunnel (inside the tunnel interface) IP addresses of each spoke. Each spoke registers its public and internal tunnel addresses when it boots and queries the NHRP database for the addresses of other spokes.

• IPsec: Provides transmission protection for GRE tunnels.

IP Address Domain• The enterprise addressing space, which is

sometimes referred to as the private or inside addresses. These are the addresses that are assigned to the (m)GRE interfaces and are registered with the NHRP server by each spoke.

• The infrastructure addressing space, which is sometimes referred to as the service provider, public, or outside addresses. These are the addresses on the router’s physical interfaces and used as addresses in tunnel envelopes (the source and destination addresses in the GRE/IPsec packet headers).

DMVPN Hub And Spoke Model

DMVPN Hub And Spoke Initial Properties

• The hub knows the outer and inner IP addresses of each spoke in its NHRP database.

• Three spoke-to-hub GRE/IPsec tunnels are created.

• Any traffic from a spoke (whether to a hub or another spoke) must travel through the hub.

DMVPN Spoke To Spoke Tunnel Creation3. R2 consults its local NHRP cache for R4’s tunnel

IP address and finds no entry. It sends an NHRP query to the NHRP server (the DMVPN hub router) to resolve the inner (tunnel) address to an external physical IP address on R4.

4. The NHRP server, which maintains inner (tunnel) and outer (physical) addresses for spoke routers, sends an NHRP reply to R2, which informs it that the inner tunnel IP on R4 is reachable through its outer (physical) IP address.

DMVPN Spoke To Spoke Tunnel Creation

1. Dynamic routing (already configured over the permanent hub-to-spoke GRE/IPsec tunnels) populates each spoke’s routing table so that each spoke knows about the subnets behind the other spokes.

2. R2 consults its routing table for a route to the subnet behind R4. The routing table provides a next-hop IP address of R4’s tunnel IP.

DMVPN Spoke To Spoke Tunnel Creation5. R2 receives the response from the server and enters

it into the local NHRP cache. IPsec is triggered on R2 to create an IPsec tunnel directly to the outer (physical) address on R4. R2 initiates an IKE session to the outer (physical) address of R4 using its outer (physical) address and then negotiates IPsec security associations (SA) for a spoke-to-spoke GRE tunnel.

6. After the IPsec tunnel is created, R2 will create a GRE tunnel to the outer (physical) address on R4, and all traffic between R2 and R4 will now flow through this tunnel with no more participation by the hub router.

DMVPN Spoke To Spoke Tunnel Creation

7. At this point, only traffic from R2 to R4 (one direction) has been enabled.

8. For two-way traffic, R4 needs next-hop information for the subnet behind R2. R4 queries the NHRP server. After it receives the NHRP response from the NHRP server, the return path is mapped to the newly built GRE tunnel and the response traffic is now sent directly to R2, encapsulated in the GRE/IPsec tunnel.

DMVPN Limitation

• It requires PKI-based authentication of peers to provide scalable spoke-to-spoke IKE authentication

• It can be more complex to troubleshoot than classic IPsec tunnels because of the required understanding of NHRP and mGRE as well as GRE and IPsec.

Consideration For Deploying DMVPN• Hardware and software on existing routers: This is

needed to determine the performance of the routers and whether the Cisco IOS Software release supports DMVPN features.

• Cryptographic standards and security requirements: Information concerning local security requirements and security policies will dictate information such as cryptographic algorithms, key lengths, and tunneling protocols.

DMVPN General Deployment Guidelines• Use DMVPNs to deploy large hub-and-spoke

or full mesh VPN networks.

• Use dynamic routing protocols to route traffic across the DMVPNs.

• DMVPN is a suitable technology for providing secure paths over insecure networks such as the Internet because it hides internal IP addressing.

Tunnel Interface Header Type Support

• A passenger protocol or encapsulated protocol, such as IP, AppleTalk, DECnet, or IPX.

• A carrier protocol (GRE in this case).

• A transport protocol (IP only in this case).

GRE Limitations• GRE provides no cryptographic protection for

traffic and must be combined with IPsec to provide it.

• There is no standard way to determine the end-to-end state of a GRE tunnel. Cisco IOS Software provides proprietary GRE keepalives for this purpose.

• It can be CPU intensive on some platforms.

• Tunnels can sometimes cause maximum transmission unit (MTU) and IP fragmentation-related issues.

GRE Point To Point Configuration• They are typically used as simple point-to-point tunnels

that act like point-to-point WAN links or as the connections from spoke to hub router in hub-and-spoke VPNs.

• There is a separate GRE tunnel interface configured on each peer for each GRE peer.

• They do not require NHRP because other peers (their destination tunnel address) are statically configured.

• They provide support for unicast, multicast, and broadcast traffic.

Configure GRE Interface on Spoke

Spoke(config)# interface tunnel0

Spoke(config-if)# tunnel mode gre ip

Spoke(config-if)# tunnel source 172.17.2.4

Spoke(config-if)# tunnel destination 172.17.0.1

Spoke(config-if)# ip address 10.1.1.2 255.255.255.0

Steps To Configuring DMVPN Hub1. (Optional) Configure an IKE policy. Recall that if one is not created, the hub

router will use default IKE policies.

2. (Optional) Generate/configure spoke authentication credentials. This typically involves enrolling into a PKI to obtain a certificate for authentication purposes.

3. Configure an IPsec profile with an optional transform set. If a transform set is not configured, the router will use default IPsec transform sets.

4. Create an mGRE tunnel interface.

5. Configure an NHRP server on the mGRE interface.

6. Associate the IPsec profile with the mGRE interface to configure tunnel protection.

7. Configure an IP address and IP fragmentation/segmentation parameters on the mGRE interface.

Configuring Optional IKE Policies On Hub

crypto isakmp policy 10

authentication pre-share

group 14

crypto isakmp key cisco123 address 0.0.0.0 0.0.0.0

Configuring IPSec Profile

crypto ipsec transform-set anyt esp-3des esp-md5-hmac

crypto ipsec profile cisco

set security-association lifetime seconds 120

set transform-set anyt

GRE Point To Multipoint Configuration

• Only one tunnel interface must be configured for a router to support multiple GRE peers. For a hub-and-spoke network, a single mGRE tunnel interface on the hub can be used for many spoke peers.

• Devices taking advantage of mGRE interfaces require the use of NHRP to build dynamic GRE tunnels. This also provides the option to have peers (usually spokes) that are dynamically addressed.

• mGRE interfaces also support unicast, multicast, and broadcast traffic.

mGRE Tunnel

Configure mGRE Interface On Hubinterface tunnel0

tunnel mode gre multipoint

tunnel source GigabitEthernet0/0

tunnel key 13579

ip address 10.1.1.1 255.255.0.0

ip mtu 1400

ip tcp adjust-mss 1360

tunnel protection ipsec profile cisco

Verifying Tunnel Interface Configuration

Router# show interfaces tunnel 0

Tunnel4 is up, line protocol is down

Hardware is Routing Tunnel

MTU 1500 bytes, BW 9 Kbit, DLY 500000 usec, rely 255/255, load 1/255

Encapsulation TUNNEL, loopback not set, keepalive set (10 sec)

Tunnel source 0.0.0.0, destination 0.0.0.0

Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled

Last input never, output never, output hang never

Last clearing of “show interface” counters never

Output queue 0/0, 0 drops; input queue 0/75, 0 drops

Five minute input rate 0 bits/sec, 0 packets/sec

Five minute output rate 0 bits/sec,

Beneficial Notification To NHRP Server From Spoke Router

• The hub router configuration is drastically shortened and simplified because it does not need to know any GRE or IPsec information about the spoke router. It is learned through NHRP.

• Adding a new spoke router to the DMVPN requires no configuration on the hub. The spoke is configured with the hub information and dynamically registers with the hub router. Dynamic routing protocols distribute information about the spoke to the hub, which in turn propagates the information to the other spokes.

Configuring NHRP Server On Hub

Hub(config)# interface tunnel0

Hub(config-if)# ip nhrp network-id 1

Hub(config-if)# ip nhrp authentication ADFqeqrDA

Hub(config-if)# ip nhrp map multicast dynamic

Verifying NHRP Command Output

Router# show ip nhrp

10.0.0.2/32 via 10.0.0.2, Tunnel0 created 00:17:49, expire 00:01:30

Type: dynamic, Flags: unique registered used

NBMA address: 172.17.0.2 Group: test-group-0

Verifying DMVPN RegistrationRouter# show dmvpnLegend: Attrb --> S - Static, D - Dynamic, I - Incomplete

N - NATed, L - Local, X - No Socket # Ent --> Number of NHRP entries with same NBMA peer

Tunnel1, Type: Spoke, NBMA Peers: 3,

# Ent Peer NBMA Addr Peer Tunnel AddState UpDn Tm Attrb ----- -------------------- --------------------- ----------- ------------------- -------

2 192.0.2.21 192.0.2.116 IKE 3w0d D1 192.0.2.102 192.0.2.11 NHRP 2:40:51 S1 192.0.2.225 192.0.2.10 UP 3w0d S

DMVPN Hub Implementation Guideline

• For IKE peering, each hub-to-spoke peering is the same as a classic IPsec VPN peering. However, if using dynamic spoke-to-spoke tunnels, these too need to be authenticated. This necessitates using a scalable authentication method, such as PKI.

• The hub and all spokes must be on the same IP subnet on the tunnel interface. This is required for the routing protocols to advertise the DMVPN as a single IP subnet. This is necessary so that all next-hop addresses appear to directly connect to the tunnel interface.

• If using redundant interfaces on the hub router, the DMVPN can be attached to a loopback interface. The loopback must be included in routing processes in this case.

Configuring DMVPN Spoke1. (Optional) Configure an IKE policy. Recall that if one is not created, the hub router

will use default IKE policies.

2. (Optional) Generate/configure spoke authentication credentials. This typically involves enrolling into a PKI to obtain a certificate for authentication purposes.

3. As with configuring the hub, an IPsec profile with an optional transform set can be configured. If a transform set is not configured, the router will use default IPsec transform sets.

4. Create an mGRE tunnel interface (or a GRE interface for strict hub-and-spoke DMVPNs).

5. Configure NHRP client parameters on the mGRE interface.

6. Associate the IPsec profile with the mGRE interface to configure tunnel protection.

7. Configure an IP address and IP fragmentation/segmentation parameters on the mGRE interface.

Configuring NHRP Client On Spoke

Spoke(config)# interface tunnel0

Spoke(config-if)# ip nhrp network-id 1

Spoke(config-if)# ip nhrp authentication ADFqeqrDA

Spoke(config-if)# ip nhrp nhs 10.1.1.1

Spoke(config-if)# ip nhrp map multicast 172.17.0.1

Spoke(config-if)# ip nhrp map 10.1.1.1 172.17.0.1

Configuring EIGRP Hub Configuration with Hub And Spoke Topology

router(config)# router eigrp 1

router(config-router)# no auto-summary

router(config-router)# exit ! router(config)# interface tunnel 0

router(config-if)# no ip split-horizon eigrp 1

Configuring EIGRP Hub Configuration with Full Mesh Topology

router(config)# router eigrp 1

router(config-router)# no auto-summary

router(config-router)# exit ! router(config)# interface tunnel 0

router(config-if)# no ip next-hop-self eigrp

router(config-if)# no ip split-horizon eigrp 1

Configuring OSPF Hub Configuration with Hub And Spoke Topology

router(config)# interface tunnel 0

router(config-if)# ip ospf network point-to-multipoint(Will change the next-hop ip address become the ip address of directly connecting router and advertise interface subnet mask as /32 host route)

router(config-if)# ip ospf priority 10

Configuring OSPF Hub Configuration with Full Mesh Topology

router(config)# interface tunnel 0

router(config-if)# ip ospf network broadcast

router(config-if)# ip ospf priority 10

NAT-T Works With IPSec/ISAKMP1. Detects if both ends support NAT-occurs in

ISAKMP Main Mode messages one and two.

2. If both devices support NAT-T, then NAT-Discovery is performed in ISKAMP Main Mode messages (packets) three and four.

3. If a NAT device has been determined to exist, NAT-T will change the ISAKMP transport with ISAKMP Main Mode messages five and six, at which point all ISAKMP packets change from UDP port 500 to UDP port 4500.

Crypto ACL Primary Function• Select outbound traffic to be protected by IPsec (permit =

protect).

• Indicate the data flow to be protected by the new SAs (specified by a single permit entry) when initiating negotiations for IPsec security associations.

• Process inbound traffic in order to filter out and discard traffic that should have been protected by IPsec.

• Determine whether or not to accept requests for IPsec security associations on behalf of the requested data flows when processing IKE negotiation from the IPsec peer. Negotiation is performed only for ipsec-isakmp crypto map entries.

Various Parts Used To Setup IPSec SA• Which traffic should be protected by IPsec (per a crypto ACL)

• The granularity of the flow to be protected by a set of SAs

• Where IPsec-protected traffic should be sent (the name of the remote IPsec peer)

• The local address to be used for the IPsec traffic

• What IPsec SA should be applied to this traffic (selecting from a list of one or more transform sets)

• Whether SAs are manually established or are established via IKE

• Other parameters that might be necessary to define an IPsec SA

IPSec Recommendation

• To minimize the possibility of packet loss during rekeying, we recommend using time-based rather than volume-based IPsec SA expiration.

• If Using manual keying, must configure SPI to be greater than 4096.

IPSec VPN Source Port Adapter(SPA)• Crypto-connect mode– Traditionally, VPNs are configured on the IPsec VPN

SPA by attaching crypto maps to interface VLANs and then crypto-connecting a physical port to the interface VLAN.

• VRF mode– The model of interface VLANs is preserved, but the

crypto connect vlan command is not used. Instead, a route must be installed so that packets destined for that particular subnet in that particular VRF are directed to that interface VLAN.

Port VLAN And Interface VLANOutside Port Outside Port

Port VLAN 502

Port VLAN 503

IPSec VPN SPA

Outside Port

Inside Port

Interface VLAN 2

Interface VLAN 3

MSFC/PFC

Layer 2

Layer 3

Access Port ConfigurationGigabitEthernet 1 / 2

Wan interface access port

Port VLAN 502Crypto-connect VLAN 2

IPSec VPN SPA in slot 4 subslot 1

Outside Port Gi4/0/2

Inside Port Gi4/0/1

Interface VLAN 2192.168.100.254

MSFC/PFC

VRF Mode Basic Configuration Exampleip vrf ivrf

rd 1000:1

route-target export 1000:1

route-target import 1000:1

!

crypto engine mode vrf

!

vlan 2,3

!

crypto keyring key0

pre-shared-key address 11.0.0.2 key 12345

!

crypto isakmp policy 1

encr 3des

hash md5

authentication pre-share

VRF Mode Basic Configuration Examplecrypto isakmp profile prof1

vrf ivrf

keyring key0

match identity address 11.0.0.2 255.255.255.255

!

!

crypto ipsec transform-set proposal1 esp-3des esp-sha-hmac

!

crypto map testtag local-address Vlan3

crypto map testtag 10 ipsec-isakmp

set peer 11.0.0.2

set transform-set proposal1

set isakmp-profile prof1

match address 101

!

interface GigabitEthernet1/1

!switch inside port

ip vrf forwarding ivrf

ip address 12.0.0.1 255.255.255.0

VRF Mode Basic Configuration Example

interface GigabitEthernet1/2

!switch outside port

switchport

switchport access vlan 3

switchport mode access

!

interface GigabitEthernet4/0/1

!IPsec VPN SPA inside port

switchport

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 1,2,1002-1005

switchport mode trunk

mtu 9216

flowcontrol receive on

flowcontrol send off

spanning-tree portfast trunk

VRF Mode Basic Configuration Exampleinterface GigabitEthernet4/0/2

!IPsec VPN SPA outside port

switchport

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 1,1002-1005

switchport mode trunk

mtu 9216

flowcontrol receive on

flowcontrol send off

spanning-tree portfast trunk

!

interface Vlan2

ip vrf forwarding ivrf

ip address 13.0.0.252 255.255.255.0

crypto map testtag

crypto engine slot 4/0 inside

!

interface Vlan3

ip address 11.0.0.1 255.255.255.0

crypto engine slot 4/0 outside

!

access-list 101 permit ip host 12.0.0.2 host 13.0.0.2

Benefits Of IKEv2

• Dead Peer Detection and Network Address Translation-Traversal Built-in Support.

• Certificate URLs can be refrence through URL and hash.

• Denial of Service Attack Resilience.• EAP Support.• Multiple Crypto Engines.• Reliability and State Management

(Windowing).

IKEv2 CLI Construct• IKEv2 Proposal– Encryption algorithm– Integrity algorithm– Pseudo-Random Function (PRF) algorithm– Diffie-Hellman (DH) group

• IKEv2 Policy– An IKEv2 policy contains proposals that are used to negotiate.

• IKEv2 Profile– Repository of nonnegotiable parameters of the IKE SA, such as

local or remote identities and authentication methods and services that are available to authenticated peers that match the profile.

• IKEv2 Key Ring– Repository of symmetric and asymmetric preshared keys and is

independent of the IKEv1 key ring.

Configuring Global IKEv2 Options

crypto ikev2 certificate-cache 750

crypto ikev2 cookie-challenge 450

crypto ikev2 diagnose error 500

crypto ikev2 dpd 500 50 on-demand

crypto ikev2 http-url certcrypto ikev2 limit max-in-negotiation-sa 5000 incoming

crypto ikev2 nat keepalive 500

crypto ikev2 window 15

crypto logging ikev2

Configuring IKEv2 Fragmentation And Proposal

crypto ikev2 fragmentation mtu 100crypto ikev2 proposal proposal1encryption aes-cbc-128 aes-cbc-192integrity sha1group 14prf sha256 sha512 (Mandatory if the encryption type is AES-GCM)

Match Statements On IKEv2 Policies• An IKEv2 policy without any match statements will match all peers in

the global FVRF.

• An IKEv2 policy can have only one match FVRF statement.

• An IKEv2 policy can have one or more match address local statements.

• When a policy is selected, multiple match statements of the same type are logically ORed and match statements of different types are logically ANDed.

• There is no precedence between match statements of different types.

• Configuration of overlapping policies is considered a misconfiguration. In the case of multiple, possible policy matches, the first policy is selected.

Configuring IKEv2 Policies

crypto ikev2 policy policy1

proposal proposal1

match fvrf any

match address local 10.0.0.1

IKEv2 SuiteB Components

• Advanced Encryption Standard (AES) 128- and 256-bit keys configured in the IKEv2 proposal. For data traffic, AES should be used in Galois Counter Mode (GCM) that is configured in the IPsec transform set.

• Elliptic Curve Digital Signature Algorithm (ECDSA) configured in the IKEv2 profile.

• Secure Hashing Algorithm 2 (SHA-256 and SHA-384) configured in the IKEv2 proposal and IPsec transform set.

Basic IPSec VTI Tunnel

IPSec Static VTI Configuration

Router# configure terminal Router(config)# interface Tunnel0 Router(config-if)# description VPN tunnel to branch office Router(config-if)# ip unnumbered GigabitEthernet0/0 Router(config-if)# tunnel source GigabitEthernet0/0 Router(config-if)# tunnel destination 192.168.2.2 Router(config-if)# tunnel mode ipsec ipv4 Router(config-if)# tunnel protection ipsec profile ENC-ProfileRouter# copy running-config startup-config

IPSec VTI Benefits• Simplify configuration

• Flexible interface feature support– Accepting features that can be applied to physical

interfaces

• Support for multicast

• Better scalability– IPsec VTIs require fewer SAs to support all types of traffic.

• Routable interface– Like GRE/IPsec, VTIs support all types of IP routing

protocols

IPSec VTI Limitations• The IPsec VTI is limited to only IP unicast and

multicast traffic, while the GRE/IPsec tunnels support a much wider range of protocols and applications.

• Cisco IOS Software IPsec stateful failover is not supported on VTIs, although other redundancy features, such as dynamic routing protocols, can be used as alternative failover methods.

Static VTI Deployment StepsStep 1.

Configure Internet Key Exchange (IKE) peering between VPN endpoints.

Step 2.

Configure an IPsec traffic protection policy on all peers.

Step 3.

Configure a static or dynamic VTI tunnel on each peer.

Step 4.

Configure static or dynamic routing over the VTI tunnels.

Dynamic VTI(DVTI)• Spoke peers attempt to create VPN connections

with the hub peer.

• They appear as virtual access interfaces that are created from information configured in a virtual template interface not as a tunnel interface.

• The settings in the virtual template interface include the hub IP address inside the tunnel (unnumbered), the tunnel mode (IPsec), and the tunnel protection, and can optionally include NetFlow accounting or firewall policy settings.

Virtual Template ConfigurationInterface Virtual-template 1

Ip unnumbered FastEthernet0/0

Tunnel mode ipsec ipv4

Tunnel protection ipsec profile Profile1

Ip flow ingress

Zone-member security B2BVPN-Zone

Virtual Access ConfigurationInterface Virtual-access 125 Ip unnumbered FastEthernet0/0 Tunnel source 10.1.1.1 Tunnel mode ipsec ipv4 Tunnel destination 10.1.1.2 Tunnel protection ipsec profile Profile1 No tunnel protection ipsec initiate Ip flow ingress Zone-member security B2BVPN-Zone

FlexVPN Spoke Configurationaaa new-model

aaa authorization network default local

aaa session-id common

crypto ikev2 keyring Flex_key

peer Spokes

address 0.0.0.0 0.0.0.0

pre-shared-key local cisco

pre-shared-key remote cisco

!!

crypto ikev2 profile Flex_IKEv2

match identity remote address 0.0.0.0

identity local email [email protected]

authentication remote pre-share

authentication local pre-share

keyring local Flex_key

aaa authorization group psk list default default

virtual-template 1

FlexVPN Spoke Configurationcrypto logging session

crypto ipsec profile default

set ikev2-profile Flex_IKEv2

interface Tunnel1

ip address negotiated

ip mtu 1400

ip nhrp network-id 2

ip nhrp shortcut virtual-template 1

ip nhrp redirect

ip tcp adjust-mss 1360

tunnel source GigabitEthernet0/0

tunnel destination 172.25.1.1

tunnel path-mtu-discovery

tunnel protection ipsec profile default

FlexVPN Spoke Configuration

interface Virtual-Template1 type tunnel ip unnumbered Tunnel1 ip mtu 1400 ip nhrp network-id 2 ip nhrp shortcut virtual-template 1 ip nhrp redirect ip tcp adjust-mss 1360 tunnel path-mtu-discovery tunnel protection ipsec profile default

FlexVPN Basic Connectivity Hub Configurationaaa new-model

aaa authorization network default local

aaa session-id common

crypto ikev2 authorization policy default

pool FlexSpokes

route set interface

crypto ikev2 keyring Flex_key

peer Spokes

address 0.0.0.0 0.0.0.0

pre-shared-key local cisco

pre-shared-key remote cisco

!!

peer Client1

identity email [email protected]

pre-shared-key cisco

!!

peer Client2

identity email [email protected]

pre-shared-key cisco

FlexVPN Basic Connectivity Hub Configuration

crypto ikev2 profile Flex_IKEv2 match fvrf any match identity remote address 0.0.0.0 match identity remote email domain cisco.com authentication remote pre-share authentication local pre-share keyring local Flex_key aaa authorization group psk list default default virtual-template 1

no crypto ikev2 http-url cert

crypto logging session

crypto ipsec profile default set ikev2-profile Flex_IKEv2

FlexVPN Basic Connectivity Hub Configuration

interface Virtual-Template1 type tunnel vrf forwarding IVRF ip unnumbered Loopback100 ip mtu 1400 ip nhrp network-id 2 ip nhrp redirect ip tcp adjust-mss 1360 tunnel path-mtu-discovery tunnel vrf INTERNET tunnel protection ipsec profile default

FlexVPN Extended Connectivity Hub Configuration

aaa attribute list Client1 attribute type interface-config "ip mtu 1300" protocol ip attribute type interface-config "service-policy output TEST" protocol ip

crypto ikev2 authorization policy Client1 pool FlexSpokes aaa attribute list Client1 route set interface

FlexVPN Extended Connectivity Hub Configuration

crypto ikev2 name-mangler GET_NAME

email username

crypto ikev2 profile Flex_IKEv2

aaa authorization group psk list default

name-mangler GET_NAME

FlexVPN Process Overview

FlexVPN Initiator

FlexVPN Responder

IKEv2 Profile Local Identity

IKEv2 name mangler

IKEv2 profile match remote identity

IKEv2 authorization policy

AAA atribute list

1 . Send Local IdentityEg: [email protected]

2. Does this remote identity Match any of my profile ?

3. IKEv2 Profile authorization statement Require mangling to be done

4. Return a name to be usedBy authorization call.

5. Perform authorization call as defined by“aaa authorization network” statement

6. Return information from aaa atribute list

Two Major Modes For User Traffic Encapsulation

• Full tunneling VPNs: Require VPN client software to be installed on the remote computer or dedicated VPN devices (hardware clients) to enable full routed IP access to internal resources. Cisco IOS Software provides support for SSL VPNs and IPsec (Easy VPN, or EZVPN) full tunneling software clients.

• Clientless VPN: Access to corporate resources can be provided to remote users even when the remote device is not managed nor is there any VPN client software.

Full Tunneling Remote Access SSL VPN Benefits

• It supports any IP application without changing the application. It creates a transparency that creates an environment in which it is like being inside the protected network and having access to any corporate resource to which the user has access.

• It does not require any user training except for initiating and terminating the VPN connection.

• It can traverse most firewalls and Network Address Translation (NAT) devices.

• Because it is limited to users having the AnyConnect VPN client on their machines, mostly used on managed devices that are typically more trusted than unmanaged devices.

Full Tunneling Remote Access SSL VPN Limitation

• It requires that users install an SSL VPN client on their systems.

• It requires administrative privileges to install the VPN client because the client needs to modify network interfaces and the IP stack to operate successfully.

Cisco ISR Web VPN Technique

• URL and Common Internet File System (CIFS) file access: When the client browser establishes the SSL session and the user is authenticated, the gateway can present a page with resource bookmarks.

• Port forwarding: Provides access to TCP-based applications by mapping application-specific ports on the remote computer to application-specific ports on the internal servers.

Clientless SSL VPN Benefits• It can traverse most firewalls and NAT devices

because the SSL VPN encapsulation uses the familiar HTTPS port (TCP 443) and looks like any other HTTPS connection.

• It does not require that users install a VPN client on their systems.

• It has no need for the user to have administrative privileges because there is no software to install.

Clientless SSL VPN Limitations• It does not support all IP applications, although most

web-based client-server applications are supported.

• It might require user training because the way users access resources can change relative to what they are accustomed to doing.

• It can potentially allow access from untrusted systems because any system with a web browser can attempt a connection. A layered security approach should be deployed to provide additional security controls.

VPN Access Method Use CasesUse Case

Full Tunneling SSL VPN

Clientless SSL VPN

Full Tunneling IPsec VPN

Mobile workers usingmanaged devicesrequiring transparentnetwork access

Yes No Yes

Mobile workers usingunmanaged devicesfrom public locations

No Yes No

Partners requiringcontrolled transparent access

Yes No Yes

Partners requiringcontrolled accesswithout a client

No Yes No

SSL/TLS Function

• Authenticate the server to the client.

• Authenticate the client to the server (optional).

• Select joint cryptographic algorithms.

• Generate shared secrets.

• Build a protected connection (SSL/TLS tunnel) to secure TCP and UDP connections.

Session And Key Management Phase

• Session establishment phase: When the negotiation of parameters and peer authentication takes place.

• Data transfer phase: User data is exchanged securely between encapsulating endpoints.

Three Subphase Of Session Establishment

• In subphase 1, hello messages are exchanged to negotiate parameters including authentication and encryption algorithms.

• In subphase 2, one-way or two-way authentication between the client and server is performed. A master key is also sent by the client using the public key of the server to start protecting the session.

• In subphase 3, the session key is calculated and the cipher suite is activated

Methods to Create Session Keys• RSA, where a shared secret is encrypted using the public key of

the other peer.

• A fixed Diffie-Hellman (DH) key exchange, which uses a fixed DH value contained in a certificate.

• An ephemeral DH key exchange, which is based on the actual DH value signed with the private key of the sender. This provides the best protection because each session will have a different set of keys.

• An anonymous DH key exchange with no certificates or signatures. This should be avoided because it cannot prevent a man-in-the-middle attack because of the anonymity.

IKE Built-in Extension Properties

• IKE extended authentication (XAUTH): XAUTH provides an additional user authentication step after IPsec peers have mutually authenticated each other. XAUTH supports user authentication using static and one-time passwords.

• IKE mode configuration: This allows the gateway to configure network parameters on the client. This feature can configure parameters such as assigning a client a tunnel IP address and configuring the client DNS servers, WINS servers, and split tunneling routes.

SSL VPN Deployment Steps1. Configure the ISR with basic SSL VPN gateway features to include

provisioning a certificate to enable SSL/TLS server authentication.

2. Configure basic user authentication by adding user accounts with passwords and creating an access policy for all remote users.

3. (Optional) Configure full tunneling VPN access to internal resources if the connection requires access that is like being connected to the internal network directly.

4. (Optional) Deploy the Cisco AnyConnect VPN client if full tunneling is required.

5. (Optional) Configure clientless VPN access to internal resources if the connection only requires browser-based access.

Enable SSL VPN Gateway• router(config)# webvpn gateway MY-GATEWAY

• router (config-webvpn-gateway)#? ip address 172.16.1.1 port 443

• router (config-webvpn-gateway)# ssl trustpoint MY-TRUSTPOINT

• router (config-webvpn-gateway)# logging enable

• router (config-webvpn-gateway)# inservice

Configure Gateway High Availability

router (config)# interface GigabitEthernet0/0

router (config-if)# standby 1 ip 172.16.1.1

router (config-if)# standby 1 name SSLVPN-HSRP

router (config)# webvpn gateway MY-GATEWAY

router (config-webvpn-gateway)# ip address 172.16.1.1 port 443 standby SSLVPN-HSRP

Gateway Verification

router# show webvpn gateway

Gateway Name Admin Operation ------------ ----- --------MY-GATEWAY up up

Configuring SSL VPN Context

router(config)# webvpn context MY-CONTEXT

router(config-webvpn-context)# policy group MY-POLICY

router(config-webvpn-context)# banner “Welcome to SSL VPN”

router(config-webvpn-context)# default-group-policy MY-POLICY

Enable User Authentication Using Local AAA

router(config)# aaa authentication login LOCAL-AUTHEN local

router(config)# username vpnuser privilege 0 secret 5 $25$05ikadSDAjaksfdjDw32PDij34214$4213


router(config-webvpn-context)# aaa authentication list LOCAL-AUTHEN

Full Tunneling Scenario

Enable Full Tunneling Access

router(config)# webvpn install svc flash://anyconnect-win-2.4.0202-k9.bin SSLVPN Package SSL-VPN-Client (seq:1): installed successfully


router(config-webvpn-context)# policy group MY-POLICY

router(config-vpn-policy)# functions svc-enabled

router(config-vpn-policy)# svc keep-client-installed

Configure Local IP Address Assignment

router(config)# ip local pool MY-POOL 192.168.1.2 192.168.1.150


router(config-webvpn-context)#policy group MY-POLICY

router(config-vpn-policy)#svc address-pool MY-POOL

Configure Client Configuration

Router(config)# webvpn context MY-CONTEXT

Router(config-webvpn-context)# policy group MY-POLICY

Router(config-vpn-policy)# svc default-domain mydomain.com

Router(config-vpn-policy)# svc dns-server primary 10.1.1.1

Configuring Split Tunneling



Router(config-vpn-policy)# svc split dns mydomain.com

Router(config-vpn-policy)# svc split include 10.0.0.0 255.0.0.0

Configuring Access ControlRouter(config)# ip access-list extended MY-ACL

Router(config-ext-acl)# permit udp any host 10.1.1.1 eq domain

Router(config-ext-acl)# permit tcp any host 10.1.1.1 eq www



Router(config-vpn-policy)# filter tunnel MY-ACL

Gateway, Context And Policy GroupWebVPN Gateway• Ip Address And Port• SSL PKI Trustpoint• HTTP Redirect

Port(Optional)• Hostname(Optional)• TCP Policy(Optional)• SSL Policy(Optional)

WebVPN Content• Portal Customization• SSL Certificate

Authentication• SSL Policy(Optional)• TCP Policy(Optional)• URL Lists• NBNS Lists• Port Forwarding Lists• Policy Groups• Default Policy Group• WebVPN Gateway• Gateway Domain(Optional)• AAA Authentication

method• AAA Authentication domain• CSD Enable/Disable• VRF Name(Optional)

Policy Group• Functions• SVC Configuration• Timeout values• URL Lists• NBNS Lists• Port Forward Lists• Citrix

Enable/Disable• Banner(Optional)

Verifying Operation On The SSL VPN Gateway

Router# show webvpn session context SSL VPN

WebVPN context name: SSL VPN

Client_Login_Name Client_IP_Address No_of_Connections Created Last_Useduser1 10.2.1.220 2 4:47:16 00:01:26user2 10.2.1.221 2 4:48:36 12:01:56


Router# show webvpn session user user1 context all

WebVPN user name = user1 ; IP address = 10.2.1.220; context = SSL VPN No of connections: 0 Created 00:00:19, Last-used 00:00:18 CSD enabled CSD Session Policy

CSD Web Browsing Allowed CSD Port Forwarding Allowed CSD Full Tunneling Disabled CSD FILE Access Allowed

User Policy Parameters Group name = ONE


Group Policy Parameters url list name = “Cisco” idle timeout = 2100 sec session timeout = 43200 sec port forward name = “EMAIL” tunnel mode = disabled citrix disabled dpd client timeout = 300 sec dpd gateway timeout = 300 sec keep stc installed = disabled rekey interval = 3600 sec rekey method = ssl lease duration = 3600 sec

Port Forwarding Process1. After logging in to the SSL VPN portal, the Java applet that is downloaded

from the SSL VPN portal dynamically modifies the local host’s file. The Java applet then listens on the remote host’s loopback address at port 3001 and forwards any incoming connections over the SSL VPN session.

2. The user opens a Telnet client and attempts to connect to an internal server on port 3001.

3. The local host’s file will be analyzed by the applet. It has an entry for the internal server that points to the loopback address (127.0.0.1) of the remote client. The Telnet client connects to the local host on port 3001, and the Java applet forwards this connection to the SSL VPN gateway through the tunnel.

4. The gateway extracts the TCP session from the SSL VPN session, establishes a TCP connection with the internal target host on the standard Telnet port, and acts as a data relay between the two TCP sessions.

Port Forwarding Limitations

• Port forwarding supports only simple, static-port TCP applications.

• Port forwarding requires preinstalled native applications on the remote systems.

• Users must change application settings such as the destination port of the server.

• Port forwarding requires administrative privileges because it changes the local host’s file.

Configuring SSL VPN Portalrouter(config)# webvpn context MY-CONTEXT router(config-webvpn-context)# url-list “MY-WEB-BOOKMARKS” router(config-webvpn-url)# url-text “Internal Web Server” url-value http://intranet.mydomain.com router(config-webvpn-url)# exit router(config-webvpn-context)# cifs-url-list “MY-CIFS-BOOKMARKS” url-text “Internal File Server” url-value “cifs://w2k3s/share” router(config-webvpn-context)# nbns-list “MY-AD-NAMESERVERS” router(config-webvpn-context)# nbns-server 10.10.1.1 ! router(config-webvpn-context)# policy-group MY-POLICY router(config-webvpn-group)# url-list “MY-WEB-BOOKMARKS” router(config-webvpn-group)# cifs-url-list “MY-CIFS-BOOKMARKS” router(config-webvpn-group)# nbns-list “MY-AD-NAMESERVERS” router(config-webvpn-group)# functions file-access router(config-webvpn-group)# functions file-browse router(config-webvpn-group)# functions file-entry

Configuring Optional Port Forwardingrouter(config)# webvpn context MY-CONTEXT

router(config-webvpn-context)# port-forward “MY-PORT-FORWRD”

router(config-webvpn-port-fwd)# local-port 3001 remote-server “10.10.1.1” remoteport 3389 description “Terminal Services”

router(config-webvpn-port-fwd)# exit

router(config-webvpn-context)# policy-group MY-POLICY

router(config-webvpn-group)# port-forward “MY-PORT-FORWRD” auto-download

Configuring Optional Cisco Secure Desktop

Router(config)# webvpn install csd flash://csd_3.5.841-k9.pkg SSLVPN Package Cisco-Secure-Desktop : installed successfully


Router(config-context)#csd enable

Configure Optional Access Controlrouter(config)# webvpn context MY-CONTEXT

router(config-webvpn-context)# acl “MY-PORTAL-ACL”

router(config-webvpn-acl)# permit url http://intranet.mydomain.com

router(config-webvpn-acl)# permit url “cifs://w2k3s/share”

router(config-webvpn-acl)# permit tcp any 10.10.1.1 255.255.255.255

router(config-webvpn-acl)# exit

router(config-webvpn-context)# policy-group MY-POLICY

router(config-webvpn-group)# acl “MY-PORTAL-ACL”

Remote Access FlexVPN

Radius For Authentication Only And Local Authorization

aaa new-model

aaa group server radius FlexVPN-AuthC-Server-Group-1 server-private 10.7.7.129 key Cisco123

aaa authentication login FlexVPN-AuthC-List-1 group FlexVPN-AuthC-Server-Group-1

aaa authorization network FlexVPN-AuthZ-List-1 local

Configuring Local Authorization Policy

ip local pool FlexVPN-Pool-1 10.8.8.100 10.8.8.200

crypto ikev2 authorization policy FlexVPN-Local-Policy-1

pool FlexVPN-Pool-1

dns 10.7.7.129

netmask 255.255.255.0

def-domain example.com

Server Using Certificate To Authenticate Itself

crypto pki trustpoint FlexVPN-TP-1 enrollment url serial-number none fqdn flex-hub.example.com ip-address none subject-name cn=flex-hub.example.com revocation-check crl rsakeypair FlexVPN-TP-1-Key 2048

Configuring Setting For Connectioncrypto ikev2 profile FlexVPN-IKEv2-Profile-1 match identity remote key-id example.com identity local dn authentication remote eap query-identity authentication local rsa-sig pki trustpoint FlexVPN-TP-1 dpd 60 2 on-demand aaa authentication eap FlexVPN-AuthC-List-1 aaa authorization group eap list FlexVPN-AuthZ-List-1 FlexVPN-Local-Policy-1 virtual-template 10

Configuring IPSec Profile Links to IKEv2 Profile

crypto ipsec profile FlexVPN-IPsec-Profile-1 set ikev2-profile FlexVPN-IKEv2-Profile-1

Configuring Virtual Template

interface Virtual-Template10 type tunnel ip unnumbered GigabitEthernet0/0 tunnel mode ipsec ipv4 tunnel protection ipsec profile FlexVPN-IPsec-Profile-1

Optional Negotiation For SHA-1

crypto ikev2 proposal SHA1-only encryption aes-cbc-256 integrity sha1 group 5crypto ikev2 policy SHA1-only match fvrf any proposal SHA1-only

IPSec Common Problems

• IKE SA not established

• IPSec SA’s not established

• MTU/Fragmentation Issues

No IKE SA Troubleshooting Step

• Check for Routing.

• Check for IKE SA using show and debug.

• Check for IKE Policies.

Debug Crypto ISAKMP ExampleISAKMP:(0):Checking ISAKMP transform 1 against priority 10 policy

ISAKMP: encryption 3DES-CBC

ISAKMP: hash SHA

ISAKMP: default group 2

ISAKMP: auth pre-share

ISAKMP: life type in seconds

ISAKMP: life duration (basic) of 7200

ISAKMP:(0):Encryption algorithm offered does not match policy!

ISAKMP:(0):atts are not acceptable. Next payload is 0

Debug Crypto ISAKMP ExampleISAKMP:(0):Checking ISAKMP transform 1 against priority 65535 policy

ISAKMP: encryption 3DES-CBC

ISAKMP: hash SHA

ISAKMP: default group 2

ISAKMP: auth pre-share

ISAKMP: life type in seconds

ISAKMP: life duration (basic) of 7200

ISAKMP:(0):Encryption algorithm offered does not match policy!

ISAKMP:(0):atts are not acceptable. Next payload is 0

ISAKMP:(0):no offers accepted!

ISAKMP:(0): phase 1 SA policy not acceptable! (local 30.3.1.1 remote 40.10.1.1)

No IPSec SA Troubleshooting Steps

• Check for IPSEC SA (look for inbound and outbound SPI’s).

• Use IPSec Debugs to troubleshoot.

• Check the IPSec Transform Sets.

• Check the Crypto ACLs.

Show Crypto IPSec SAinterface: GigabitEthernet0/1

Crypto map tag: CMAP, local addr 30.3.1.1

protected vrf: (none) local ident (addr/mask/prot/port): (3.1.1.0/255.255.255.0/0/0) remote ident (addr/mask/prot/port): (4.1.1.0/255.255.255.0/0/0) current_peer 40.10.1.1 port 500 PERMIT, flags={origin_is_acl,}

local crypto endpt.: 30.3.1.1, remote crypto endpt.: 40.10.1.1 path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/1 current outbound spi: 0x0(0)

inbound esp sas: inbound ah sas:

outbound esp sas: outbound ah sas:

Debug Crypto IPSecISAKMP (0:1022): received packet from 40.10.1.1 dport 500 sport 500 Global (R) QM_IDLE

ISAKMP:(1022): processing SA payload. message ID = -549695704

ISAKMP:(1022):Checking IPSec proposal 1

ISAKMP: transform 1, ESP_3DES

ISAKMP: attributes in transform:

ISAKMP: encaps is 1 (Tunnel)

ISAKMP: SA life type in seconds

ISAKMP: SA life duration (basic) of 1800

ISAKMP: SA life type in kilobytes

ISAKMP: SA life duration (VPI) of 0x0 0x46 0x50 0x0

ISAKMP: authenticator is HMAC-SHA

ISAKMP:(1022):atts are acceptable.

Debug Crypto IPSecIPSEC(validate_proposal_request): proposal part #1,

(key eng. msg.) INBOUND local= 30.3.1.1, remote= 40.10.1.1,

local_proxy= 3.1.1.0/255.255.255.0/0/0 (type=4),

remote_proxy= 4.1.1.0/255.255.255.0/0/0 (type=4),

protocol= ESP, transform= NONE (Tunnel),

lifedur= 0s and 0kb,

spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x0

Crypto mapdb : proxy_match

src addr : 3.1.1.0

dst addr : 4.1.1.0

protocol : 0

src port : 0

dst port : 0

IPSEC(ipsec_process_proposal): transform proposal not supported for identity:

{esp-3des esp-sha-hmac }

ISAKMP:(1022): IPSec policy invalidated proposal with error 256

ISAKMP:(1022): phase 2 SA policy not acceptable! (local 30.3.1.1 remote 40.10.1.1)

IPSec SA Showing Anti Reply Dropsinterface: GigabitEthernet0/1

Crypto map tag: CMAP, local addr 30.3.1.1

protected vrf: (none)

local ident (addr/mask/prot/port): (3.1.1.0/255.255.255.0/0/0)

remote ident (addr/mask/prot/port): (4.1.1.0/255.255.255.0/0/0)

current_peer 40.10.1.1 port 500

PERMIT, flags={origin_is_acl,}

#pkts encaps: 2900, #pkts encrypt: 2900, #pkts digest: 2900

#pkts decaps: 1909, #pkts decrypt: 1909, #pkts verify: 1909

#pkts compressed: 0, #pkts decompressed: 0

#pkts encaps failed (send) 0, #pkts decaps failed (rcv) 0

#pkts invalid prot (recv) 0, #pkts verify failed: 0

#pkts invalid identity (recv) 0, #pkts invalid len (rcv) 0

#pkts replay rollover (send): 0, #pkts replay rollover (rcv) 0

#pkts replay failed (rcv): 1000

#pkts internal err (send): 0, #pkts internal err (recv) 0

IPSec SA Showing Anti Reply Drops local crypto endpt.: 30.3.1.1, remote crypto endpt.: 40.10.1.1 path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/1 current outbound spi: 0xC37422AA(3279168170)

inbound esp sas: spi: 0x135E76B1(324957873) transform: esp-3des esp-sha-hmac , in use settings ={Tunnel, } conn id: 41, flow_id: SW:41, crypto map: CMAP sa timing: remaining key lifetime (k/sec): (4419198/860) IV size: 8 bytes replay detection support: Y Status: ACTIVE

Verifying DMVPN Common Issue• Verify the basic connectivity.• Verify for incompatible ISAKMP policy.– The show crypto isakmp sa command shows the

ISAKMP SA to be in MM_NO_STATE, meaning the main-mode failed.

• Verify for incorrect pre-shared key secret.– The router returns the "sanity check failed" message.

• Verify for incompatible IPsec transform set.– The router returns the "atts not acceptable" message

for the IPsec proposal.

Common Problem On DMVPN

• VPN Tunnel Flapping.

• NHRP Registration Failing.

• ISAKMP/IPSec bouncing up and down.

• Traffic flow only in one direction.

• Spokes are unable to establish routing protocol neighbor relationship.

VPN Tunnel Flapping

Router#show crypto isakmp sa

IPv4 Crypto ISAKMP SA

Dst src state conn-id slot status172.17.0.1 172.16.1.1 MM_NO_STATE 0 0 ACTIVE172.17.0.1 172.16.1.1 MM_NO_STATE 0 0 ACTIVE (deleted)172.17.0.5 172.16.1.1 MM_NO_STATE 0 0 ACTIVE172.17.0.5 172.16.1.1 MM_NO_STATE 0 0 ACTIVE (deleted)

NHRP Registration FailingRouter#show crypto IPSEC sa

local ident (addr/mask/prot/port): (172.16.1.1/255.255.255.255/47/0)

remote ident (addr/mask/prot/port): (172.17.0.1/255.255.255.255/47/0)

#pkts encaps: 154, #pkts encrypt: 154, #pkts digest: 154

#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0

inbound esp sas:

spi: 0xF830FC95(4163959957)

outbound esp sas:

spi: 0xD65A7865(3596253285)

NHRP Registration Failing

Router#show ip nhrp nhs detail

Legend: E=Expecting replies, R=Responding

Tunnel0: 172.17.0.1 E req-sent 0 req-failed 30 repl-recv 0

Pending Registration Requests:

Registration Request: Reqid 4371, Ret 64 NHS 172.17.0.1

Hub And Spoke IPSec VPN Design

FlexVPN Dual Hub Design

Dual DMVPN Cloud Topology

Single Tier HeadEnd Architechture

Dual Tier HeadEnd Architechture

DTLS On ASA• Allows the AnyConnect client establishing an SSL VPN

connection to use two simultaneous tunnels—an SSL tunnel and a DTLS tunnel.

• DTLS (Datagram Transport Layer Security) avoids latency and bandwidth problems associated with SSL connections and improves the performance of real-time applications that are sensitive to packet delays.

• By default, DTLS is enabled when SSL VPN access is enabled on an interface.

• In order for DTLS to fall back to a TLS connection, Dead Peer Detection (DPD) must be enabled.

Cisco Evolution Of Cryptography Encryption Digital Signature Hashing Key Exchange

Cisco Encryption Technology Short RSA Keys MD5 Diffie-Hellman

IPSec: 56 bit Digital Encryption Standard (DES)

2048 bit RSA Keys SHA-1

Elliptic Curve Diffie-Hellman (Using P-

256 and P-384 curves)

168-bit Triple DES (3DES)Elliptic Curve

Digital Signature Algorithm

SHA-256

128-bit AES (Galois/Counter Mode GCM and Galois Message

Authentication Code(GMAC)

SHA-384 And SHA-

512

256-bit AES(GCM and GMAC)