CCNP Security SIMOS 300-209=vpn 642-648

1 | P a g e Eng.Mohamed Abou Elenein

By

Eng. Mohamed Abou-Elenein Attia

Email: [email protected]


Contents

Naked DMVPN ............................................................................................................... 3

Protected DMVPN ......................................................................................................... 7

Troubleshoot DMVPN ................................................................................................... 9

IKE call admission control ............................................................................................. 9

VTI Site to site VPN ...................................................................................................... 11

Dynamic VTI Hub ......................................................................................................... 14

Flex VPN site2site ........................................................................................................ 17

Flex VPN DVTI ................................................................................................................ *

Flex VPN smart Default ................................................................................................. *

Certificate install ......................................................................................................... 22

RSA-sig IKEv2 Authentication ..................................................................................... 30

DVTI IKEv2 Hub and Spoke RSA-Sig ............................................................................ 33

IKE V2 Pushing Policy .................................................................................................. 36

Flex VPN Client ............................................................................................................ 38

Spoke 2 Spoke flex VPN .............................................................................................. 41

Flex VPN troubleshooting ........................................................................................... 48

GETVPN ........................................................................................................................ 49

ASA IOS IKEV2 (site to site IPsec VPN) ........................................................................ 60

Reference ..................................................................................................................... 64


VPN negotiations happen in two distinct phases: Phase 1 and Phase 2.

Phase 1

The main purpose of Phase 1 is to set up a secure encrypted channel through which the two

peers can negotiate Phase 2. When Phase 1 finishes successfully, the peers quickly move on

to Phase 2 negotiations. If Phase 1 fails, the devices cannot begin Phase 2.

Phase 2

The purpose of Phase 2 negotiations is for the two peers to agree on a set of parameters that

define what traffic can go through the VPN, and how to encrypt and authenticate the traffic.

This agreement is called a Security Association.

The Phase 1 and Phase 2 configurations must match for the devices on either end of the

tunnel.

Naked DMVPN

A dynamic multipoint virtual private network (DMVPN) is a secure network that

exchanges data between sites without needing to pass traffic through an organization's

headquarter virtual private network (VPN) server or router.

VPNs traditionally connect each remote site to the headquarters; the DMVPN essentially

creates a mesh VPN topology. This means that each site (spoke) can connect directly with all

other sites, no matter where they are located.

A DMVPN service runs on VPN routers and firewall concentrators. Each remote site has a

router configured to connect to the company’s headquarters VPN device (hub), providing

access to the resources available. When two spokes are required to exchange data between

each other -- for a VoIP telephone call, for example -- the spoke will contact the hub, obtain

the necessary information about the other end, and create a dynamic IPsec VPN tunnel

directly between them.

Direct spoke-to-spoke deployments provide a number of advantages when compared to

traditional VPN deployments:

Traffic between remote sites does not need to traverse the hub (headquarter VPN router).

A DMVPN deployment eliminates additional bandwidth requirements at the hub.

DMVPNs eliminate additional network delays.

DMVPNs conserve WAN bandwidth.

They lower costs for VPN circuits.

They increase resiliency and redundancy.

DMVPN deployments include mechanisms such as GRE tunneling and IPsec encryption

with Next Hop Resolution Protocol (NHRP) routing that are designed to reduce


administrative burden and provide reliable dynamic connectivity between sites. It is in every

company’s advantage to make use of DMVPN where possible, to help reduce WAN costs and

increase bandwidth and reliability.

Generic Routing Encapsulation (GRE) is a tunneling protocol developed by Cisco Systems

that can encapsulate a wide variety of network layer protocols inside virtual point-to-point

links over an Internet Protocol network.

NHRP is an ARP-like protocol that allows Next Hop Clients (NHCs) to dynamically register

with Next Hop Servers (NHSs). This allows the NHCs to join the NBMA network without

configuration changes on the NHSs, especially in cases where the NHC has a dynamic

physical IP address or is behind a Network Address Translation (NAT) router that

dynamically changes the physical IP address. In these cases it would be impossible to

preconfigure the logical virtual private network (VPN IP) to physical (NBMA IP) mapping

for the NHC on the NHS. This function is called NHRP registration.

Note

If router R2 want sent packet to R4 or 10.4.4.1 R2 sent request to R1 (Hub) and Hub router

sent request to R4 once connection up traffic path between R2 and R4 directly

A non-broadcast multiple access network (NBMA) is a network to which multiple

computers and devices are attached, but data is transmitted directly from one computer to

another over a virtual circuit or across a switching fabric. The most common examples of

non-broadcast network media include ATM (Asynchronous Transfer Mode), frame relay, and

X.25.NHRP (Next Hop Resolution Protocol) is used to determine the NBMA sub network

addresses of the "NBMA next hop" toward a public internetworking layer address.

R1 (HUB)

int gi 0/0

ip add 15.0.0.1 255.255.255.0

no sh

exit

int g 1/0


ip add 10.1.1.1 255.255.255.0

no sh

exit

interface Tunnel0

ip address 172.16.0.1 255.255.255.0

no ip redirects

ip mtu 1416

no ip next-hop-self eigrp 777

ip nhrp authentication cisco123

ip nhrp map multicast dynamic

ip nhrp network-id 1

no ip split-horizon eigrp 777

tunnel source GigabitEthernet0/0

tunnel mode gre multipoint

exit

router eigrp 777

no auto-sum

network 10.0.0.0

network 172.16.0.0

end

ip route 35.0.0.0 255.255.255.0 15.0.0.2

ip route 25.0.0.0 255.255.255.0 15.0.0.2

ip route 45.0.0.0 255.255.255.0 15.0.0.2

--------------------------------------------------

R2 (SPOKE)

int gi 0/0

ip add 25.0.0.1 255.255.255.0

no sh

exit

int g 1/0

ip add 10.2.2.1 255.255.255.0

no sh

exit

interface Tunnel0

ip address 172.16.0.2 255.255.255.0

ip mtu 1416



ip nhrp map multicast 15.0.0.1

ip nhrp map 172.16.0.1 15.0.0.1


ip nhrp nhs 172.16.0.1



router eigrp 777

no auto-sum

network 10.0.0.0

network 172.16.0.0

end


ip route 35.0.0.0 255.255.255.0 25.0.0.2

ip route 15.0.0.0 255.255.255.0 25.0.0.2

ip route 45.0.0.0 255.255.255.0 25.0.0.2

--------------------------------------------------

R3 (SPOKE)

int gi 0/0

ip add 45.0.0.1 255.255.255.0

no sh

exit

int g 1/0

ip add 10.4.4.1 255.255.255.0

no sh

exit

interface Tunnel0

ip address 172.16.0.3 255.255.255.0

ip mtu 1416




ip nhrp map 172.16.0.1 15.0.0.1




tunnel mode gre multipointend

router eigrp 777

no auto-sum

network 10.0.0.0

network 172.16.0.0

end

ip route 35.0.0.0 255.255.255.0 45.0.0.2

ip route 15.0.0.0 255.255.255.0 45.0.0.2

ip route 25.0.0.0 255.255.255.0 45.0.0.2

--------------------------------------------------

R4 (SPOKE)

int gi 0/0

ip add 35.0.0.1 255.255.255.0

no sh

exit

int g 1/0

ip add 10.3.3.1 255.255.255.0

no sh

exit.

ip route 45.0.0.0 255.255.255.0 35.0.0.2

ip route 15.0.0.0 255.255.255.0 35.0.0.2

ip route 25.0.0.0 255.255.255.0 35.0.0.2

interface Tunnel0

ip address 172.16.0.4 255.255.255.0

ip mtu 1416





ip nhrp map 172.16.0.1 15.0.0.1





router eigrp 777

no auto-sum

network 10.0.0.0

network 172.16.0.0

end

--------------------------------------------------

R1(ISP)(tunnel up without any update from isp)

int g 0/0

ip add 15.0.0.2 255.255.255.0

no sh

exit

int g 2/0

ip add 35.0.0.2 255.255.255.0

no sh

exit

int g 3/0

ip add 45.0.0.2 255.255.255.0

no sh

exit

int g 1/0

ip add 25.0.0.2 255.255.255.0

no sh

exit

------------------------------------------

Verification

sh ip nhrp

sh ip route eigrp

sh ip nhrp summary

debug nhrp

sh ip int tunnel 0

Protected DMVPN

ISAKMP (Internet Security Association and Key Management Protocol) is a protocol defined

by RFC 2408 for establishing Security Associations (SA) and cryptographic keys in an Internet

environment. ISAKMP only provides a framework for authentication and key exchange and is

designed to be key exchange independent; protocols such as Internet Key Exchange and

Kerberized Internet Negotiation of Keys provide authenticated keying material for use with

ISAKMP.

R1(Hub)

crypto isakmp policy 5


hash sha

authentication pre-share

group 14

lifetime 86400

encryption aes 256

exit

crypto isakmp key cisco123 address 0.0.0.0

crypto ipsec transform-set OURSET esp-aes 256 esp-sha-hmac

mode transport

crypto ipsec profile OUR_IPSEC_PROFILE

set transform-set OURSET

exit

interface tunnel 0

tunnel protection ipsec profile OUR_IPSEC_PROFILE

exit

R2/R3/R4(spoke)


hash sha


group 14

lifetime 86400

encryption aes 256

exit


crypto ipsec transform-set OURSET esp-aes 256 esp-sha-hmac

mode transport

exit

crypto ipsec profile OUR_IPSEC_PROFILE

set transform-set OURSET

exit

interface tunnel 0

tunnel protection ipsec profile OUR_IPSEC_PROFILE

exit

--------------------- ------------------------

sh dmvpn

sh crypto isakmp sa

sh crypto isakmp sa detail

sh crypto ipsec sa peer 25.0.0.1

sh crypto ipsec sa peer 25.0.0.1 detail


Troubleshoot DMVPN

sh ip nhrp

sh int tunnel 0

sh run | tunnel 0

sh ip route

sh ip rout eigrp

sh ip eigrp neighbor

logging buffered 7

logging console 7

sh crypto isakmp policy show crypto isakmp sa sh crypto ipsec sa sh dmvpn details dubug crypto isakmp

IKE call admission control

Internet Key Exchange (IKE or IKEv2) is the protocol used to set up a security association

(SA) in the IPsec protocol suite. IKE builds upon the Oakley protocol and ISAKMP.IKE uses

X.509 certificates for authentication - either pre-shared or distributed using DNS (preferably

with DNSSEC) and a Diffie–Hellman key exchange - to set up a shared session secret from

which cryptographic keys are derived. In addition, a security policy for every peer which will

connect must be manually maintained.

IKEv1 Phases

IKE phase 1's purpose is to establish a secure authenticated communication channel by using

the Diffie–Hellman key exchange algorithm to generate a shared secret key to encrypt

further IKE communications. This negotiation results in one single bi-directional ISAKMP

Security Association (SA).The authentication can be performed using either pre-shared key

(shared secret), signatures, or public key encryption. Phase 1 operates in either Main Mode


or Aggressive Mode. Main Mode protects the identity of the peers; Aggressive Mode does

not.

During IKE phase 2, the IKE peers use the secure channel established in Phase 1 to negotiate

Security Associations on behalf of other services like IPsec. The negotiation results in a

minimum of two unidirectional security associations (one inbound and one outbound).Phase

2 operates only in Quick Mode.

IKEv1 vs. IKEv2

“ IKE,” which stands for “Internet Key Exchange,” is a protocol that belongs to the IPsec

protocols suite. Its responsibility is in setting up security associations that allow two parties

to send data securely. IKE was introduced in 1998 and was later superseded by version 2

roughly 7 years later. There are a number of differences between IKEv1 and IKEv2, not the

least of which is the reduced bandwidth requirements of IKEv2. Freeing up bandwidth is

always a good thing as the extra bandwidth can be used for the transmission of data.

Another difference between IKEv1 and IKEv2 is the inclusion of EAP authentication in the

latter. IKEv1 does not support EAP and can only choose between a pre-shared key and

certificate authentication which IKEv2 also supports. EAP is essential in connecting with

existing enterprise authentication systems. IKEv2 also introduces MOBIKE; a feature not

found on IKEv1. MOBIKE allows IKEv2 to be used in mobile platforms like phones and by

users with multi-homed setups.

Another difference between IKEv1 and IKEv2 is the incorporation of NAT traversal in the

latter. NAT traversal is necessary when a router along the route performs Network Address

Translation. This is when a router captures the packets sent and modifies the destination

address on the packets. This is typical when multiple users are using the same Internet

connection thus giving them the same IP address. This is not a problem with ordinary

activities like browsing but can be a significant problem when IPsec is needed. That is why

IKEv2 has a significant advantage over IKEv1

Lastly, IKEv2 has been improved so that it is able to detect whether the tunnel is still alive or

not. This is commonly referred to as a “liveness” check. If the liveness check fails, caused by

the tunnel breaking down, IKEv2 is then able to re-establish the connection automatically.

IKEv1 does not have this ability and would just assume that the connection is always up thus

having quite an impact on reliability. There are several workarounds for IKEv1, but these are

not standardized.

Summary:

1. IKEv2 does not consume as much bandwidth as IKEv1.

2. IKEv2 supports EAP authentication while IKEv1 doesn’t.

3. IKEv2 supports MOBIKE while IKEv1 doesn’t.

4. IKEv2 has built-in NAT traversal while IKEv1 doesn’t.

5. IKEv2 can detect whether a tunnel is still alive while IKEv1 cannot.


To deny TCP sync flood attack or deny any attacker to create VPN phase 1 so we limit

number of tunnels

Show crypto call admission statistics

We want to limit negotiation and limit IKE SA

Crypto call admission ike sa 2

Crypto call admission limit ike in-negotiation-sa 10

VTI Site to site VPN

VTI (Virtual Tunnel Interface)

Virtual tunnel interface is a full-featured routable interface, many of the common interface

options that can be applied to physical interfaces can now be applied to the IPsec virtual

tunnel interface. Using VTI in IPsec VPN makes the static mapping between the IPsec crypto

map and physical interface no longer an requirement. Instead, we can associate the IPsec

tunnel directly with the VTI.

VTI Benefits

Simplify configuration: When using the VTI IPsec configuration, fewer configuration

lines are required because after the virtual tunnel interface is created and an IPsec profile

is applied to it, the crypto maps are automatically generated for each tunnel. Thus

configuring IPsec peering is much simpler when using virtual tunnel interfaces as

compared to configuring IPsec peering with crypto maps or GRE/IPsec tunnels.

Better interoperation: An IPsec VTI (VTI-Based VPN)is a feature in Cisco IOS

Software that is used to support IPsec VPNs. VTIs support native IPsec tunneling,

including interoperability with standards-based IPsec implementations of other vendors.


Multicast support and better scalability: IPsec VTIs support multicast traffic such as

voice and video, IPsec VTIs require fewer SAs to support all types of traffic.

Dynamic Routing support: Like GRE/IPsec, VTIs support all types of IP routing

protocols, which provides scalability and redundancy.

VTI limitations:

No multi-protocol support: 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.

Stateful Failover not supported: 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.

General Deployment Guidelines

Static or dynamic VTI tunnels: Dynamic VTI tunnels should be for the hub in large hub-and-

spoke implementations. Otherwise, static VTI tunnels are recommended.

Static or dynamic routing protocol over the VTI tunnels: Dynamic routing protocols should be

used in large networks or to provide redundancy with multiple VTI tunnels. Otherwise, static

routing over VTI tunnels is recommended.

Use VTI-based site-to-site VPNs as the default IPsec technology for individual point-to-point

VPN links and for hub-and-spoke VPNs.

Consider deploying Dynamic Multipoint VPN (DMVPN) or Group Encrypted Transport

(GET) VPN for larger environments with partial or fully meshed VPN requirements.

Deploying Static Point-to-Point IPsec VTI Tunnels

(Optional) Configuring Basic IKE Peering and IKE (ISAKMP) Policies: They are used to

determine IKE authentication, IKE hash algorithm, IKE encryption, IKE key exchange (DH

group number), IKE session lifetime. Note that Cisco IOS Software does not require that the

IKE peers have matching IKE lifetime settings for a successful exchange. The IKE SA will

establish by adjusting its IKE session lifetime to the shorter of the two settings.

Cisco IOS Software Release 12.4(20) T introduced default pre-shared key based IKE policies.

There are eight default policies with priorities ranging from 65507 to 65514, with 65507

having the highest priority and 65514 having the lowest priority. So explicitly selecting an

IKE (ISAKMP) policy on each peer is not necessary.

IPsec virtual tunnel interface

R2

Crypto ipsec transform-set P2P-SET esp-aes 256 esp-sha-hmac

mode tunnel

exit

crypto ipsec profile P2P-PROFILE

set transform-set P2P-SET


exit

interface tunnel 1

ip unnumbere loopback 0

tunnel source gig 0/0

tunnel destination 35.0.0.1

tunnel mode ipsec ipv4

tunnel protection ipsec profile P2P-PROFILE

exit

int loopb 0

no sh

ip add 1.1.1.1 255.255.255.255

exit

router eigrp 777

network 1.1.1.1 0.0.0.0

exit

R3

crypto ipsec transform-set P2P-SET esp-aes 256 esp-sha-hmac

mode tunnel

exit

crypto ipsec profile P2P-PROFILE

set transform-set P2P-SET

exit

interface tunnel 1

ip unnumbere loopback 0




tunnel protection ipsec profile P2P-PROFILE

exit

int loopb 0

no sh

ip add 3.3.3.3 255.255.255.255

exit

router eigrp 777

network 3.3.3.3 0.0.0.0

exit

SHow crypto isakmp sa

SHow crypto isakmp sa detail

show crypto engine connections active

After that we can create policy to deny or permit traffic

Class-Map: Identify Traffic

Policy-Map: Manipulate traffic

Service Policy: Apply

To apply it n tunnel 1


Interface tunnel 1

Service-policy output POLICY_MAP_NAME

Exit

Dynamic VTI Hub

We use it if we have more and more branches this occur between HUB Router and Spoke

IPSEC

Hub with Dynamic VTI, Plus:

1. ISAKMP Profile

2. Key Ring with PSKs

3. Virtual Template

R1(Hub)


encr aes 192

authentication Pre-share

group 5

exit

cypto keyring OUR-PSKS

pre-share-key address 0.0.0.0 key cisco123

exit

crypto ipsec transform-set OUR-SET esp-aes 128 esp-md5-hmac

exit

crypto ipsec profile OUR-IPSEC-PROFILE

set transform-set OUR-SET

exit


interface virtuaal-template 1 type tunnel

ip unnumbered loop 0


tunnel protection ipsec profile OUR-IPSEC-PROFILE

exit

int loop 0

ip address 1.1.1.1 255.255.255.0

exit

crypto isakmp profile OUR-IKE-PROFILE

match identity address 25.0.0.2 255.255.255.255

match identity adress 0.0.0.0

virtual-template 1

keyring OUR-PSKS

exit

router eigrp 777

no auto-summary

network 1.0.0.0

network 10.0.0.0

end

R2


encr aes 192


group 5

exit

crypto isakmp key cisco123 adress 0.0.0.0


exit



exit

interface tunnel 2


ip unnumbered loopback 0

tunnel source serial 1/0



exit

int loop 0

ip address 2.2.2.2 255.255.255.0

exit

router eigrp 777

no auto-summary


network 2.0.0.0

network 10.0.0.0

end

R3


encr aes 192


group 5

exit



exit



exit

interface tunnel 2



tunnel source serial 1/0



exit

int loop 0

ip address 3.3.3.3 255.255.255.0

exit

router eigrp 777

no auto-summary

network 3.0.0.0

network 10.0.0.0

end

To check tunnel at R1 Show crypto isamp sa

show ip int brif | exclude unassigned



To check tunnel at R2 and R3

Show ip route eigrp

Flex VPN Site2Site (Site to site VPN)

Cisco IOS FlexVPN

Large customers deploying IPSec VPN over IP networks are faced with high complexity and

high cost of deploying multiple types of VPN to meet different types of connectivity

requirements. Customers often have to learn different types of VPNs to manage and operate

different types of network. And once a technology is selected for a deployment, migrating or

adding functionality to enhance the VPN is often avoided. FlexVPN was created to simplify

the deployment of VPNs, to address the complexity of multiple solutions, and as a unified

ecosystem to cover all types of VPN: remote access, teleworker, site to site, mobility,

managed security services, and others. See Figure


Cisco IOS FlexVPN Features and Benefits

Cisco IOS FlexVPN is a unified VPN solution and provides the following benefits:

Transport network: FlexVPN can be deployed either over a public internet or a private

Multiprotocol Label Switching (MPLS) VPN network.

Deployment style: Designed for the concentration of both site-to-site and remote access

VPNs, one single FlexVPN deployment can accept both types of connection requests at

the same time.

Failover redundancy: Three different kinds of redundancy model can be implemented

with FlexVPN:

1. Dynamic routing protocols (such as Open Shortest Path First [OSPF], Enhanced

Interior Gateway Routing Protocol [EIGRP], Border Gateway Protocol [BGP]) over

FlexVPN tunnels. Path/head-end selection is based on dynamic routing metrics.

2. IKEv2-based dynamic route distribution and server clustering.

3. IPsec/IKEv2 active/standby tasteful failover between two chassis (available in the

future).

Third-party compatibility: As the IT world transitions to cloud- and mobile-based

computing, more and more VPN routers and VPN endpoints from different vendors are

required. The Cisco IOS FlexVPN solution provides compatibility with any IKEv2-based

third-party VPN vendors, including native VPN clients from Apple iOS and Android

devices.

IP Multicast support: FlexVPN natively supports IP Multicast in two ways:

1. FlexVPN hub router replicates IP Multicast packets for each spoke.

2. If the transport network supports native IP Multicast, the FlexVPN hub router can

choose to have the transport network do multicast packet replication after IPsec

encryption (available in the future).

3. Superior quality of service (QoS): The architecture of Cisco IOS FlexVPN easily allows

hierarchical QoS to be integrated at the per tunnel or per SA basis:

4. Per tunnel QoS for each spoke at the FlexVPN hub router.

5. Per tunnel QoS dynamically applied to direct traffic between spokes (available in the

future).

Centralized policy control: VPN dynamic policies such as split-tunnel policy, encryption

network policy, Virtual Route Forwarding (VRF) selection, Domain Name System (DNS)

server (for remote access), and so on can be fully integrated with the authentication,

authorization, and accounting (AAA)/RADIUS server and applied at a per peer basis.

VRF awareness: The Cisco IOS FlexVPN solution can be fully integrated with MPLS VPN

networks for service provider type of deployment. Both Inside VRF and front-door VRF

are supported. Inside VRF assignment policy can be managed by the centralized AAA

server.


Phase 1

IKE V2:

Proposals (hagle)

Key Ring (KEYS)

Policy (VRF, Address limits)

Profile (identities, authentication methods)

Phase 2(IPSEC)

Transforms

Profiles

Lab A (As Shown)

R5

Show crypto ikev2 proposal default

Show crypto ikev2 policy default4

R5

If we want to change proposal

Crypto ikev2 proposal OUR-PROPOSAL

encryption XXXXXXX

group XXXXX

integrity XXXXX

crypto ikev2 keyring OUR_KEY_RING

peer R6-BRANCH-ROUTER


description This describes R6

address 64.0.0.6

identity fqdn r6.cbtnuggets.com

pre-shared-key local cisco-ABC

pre-share-key remote cisco-XYZ

exit

crypto ikev2 profile OUR-PROFILE

match identity remote R6.cbtnuggets.com

authentication local pre-share

authentication remote pre-share

keyring OUR_KEY_RING

exit

crypto ipsec profile default

set ikev2-profile OUR-PROFILE

exit

int tunnel 3





ip mtu 1400

ip tcp adjust-mss 1360

tunnel protection ipsec profile default

ip route 10.6.0.0 255.255.255.0 tunnel 3 200

Show run | section crypto


R6

crypto ikev2 keyring OUR_KEY_RING

peer R5-HQ-ROUTER

description This describes R5

address 45.0.0.5

identity fqdn r5.cbtnuggets.com

pre-shared-key local cisco-XYZ

pre-share-key remote cisco-ABC

exit

crypto ikev2 profile OUR-PROFILE

identity local fqdn R6.cbtnuggets.com

match identity remote R5.cbtnuggets.com

authentication local pre-share

authentication remote pre-share

keyring OUR_KEY_RING

exit


set ikev2-profile OUR-PROFILE

exit

int tunnel 3





ip mtu 1400



exit

ip route 10.5.0.0 255.255.255.0 tunnel 3 200

Show crypto ikev2 sa

show crypto ipsec sa



Certificate install

Phase1 (IKEV1 Tunnel)

H-----ASH

A-----UHNTICATION

G-----ROUP (DH)

L------IFE time

E ------NCRYPT Phase2 (IKEV2 Tunnel)

ENCRPTION

DH

LIFE TIME

HASH

What Is SSL (Secure Sockets Layer) and What Are SSL Certificates?

What Is SSL?

SSL (Secure Sockets Layer) is a standard security technology for establishing an encrypted

link between a server and a client—typically a web server (website) and a browser; or a mail

server and a mail client (e.g., Outlook).


SSL allows sensitive information such as credit card numbers, social security numbers, and

login credentials to be transmitted securely. Normally, data sent between browsers and web

servers is sent in plain text—leaving you vulnerable to eavesdropping. If an attacker is able

to intercept all data being sent between a browser and a web server they can see and use

that information.

More specifically, SSL is a security protocol. Protocols describe how algorithms should be

used; in this case, the SSL protocol determines variables of the encryption for both the link

and the data being transmitted.

SSL secures millions of peoples’ data on the Internet every day, especially during online

transactions or when transmitting confidential information. Internet users have come to

associate their online security with the lock icon that comes with an SSL-secured website or

green address bar that comes with an extended validation SSL-secured website. SSL-secured

websites also begin with https rather than http

Where Do Certificates Come In?

All browsers have the capability to interact with secured web servers using the SSL protocol.

However, the browser and the server need what is called an SSL Certificate to be able to

establish a secure connection.

What is an SSL Certificate and How Does it Work?

SSL Certificates have a key pair: a public and a private key. These keys work together to

establish an encrypted connection. The certificate also contains what is called the “subject,”

which is the identity of the certificate/website owner.

To get a certificate, you must create a Certificate Signing Request (CSR) on your server. This

process creates a private key and public key on your server. The CSR data file that you send

to the SSL Certificate issuer (called a Certificate Authority or CA) contains the public key. The

CA uses the CSR data file to create a data structure to match your private key without

compromising the key itself. The CA never sees the private key.

Once you receive the SSL Certificate, you install it on your server. You also install an

intermediate certificate that establishes the credibility of your SSL Certificate by tying it to

your CA’s root certificate. The instructions for installing and testing your certificate will be

different depending on your server.

In the image below, you can see what is called the certificate chain. It connects your server

certificate to your CA’s (in this case DigiCert’s) root certificate through an intermediate

certificate.

The most important part of an SSL Certificate is that it is digitally signed by a trusted CA like

DigiCert. Anyone can create a certificate, but browsers only trust certificates that come from

an organization on their list of trusted CAs. Browsers come with a pre-installed list of trusted

CAs, known as the Trusted Root CA store. In order to be added to the Trusted Root CA store

and thus become a Certificate Authority, a company must comply with and be audited

against security and authentication standards established by the browsers.

An SSL Certificate issued by a CA to an organization and its domain/website verifies that a

trusted third party has authenticated that organization’s identity. Since the browser trusts


the CA, the browser now trusts that

organization’s identity too. The browser

lets the user know that the website is

secure, and the user can feel safe

browsing the site and even entering their

confidential information.

How Does the SSL Certificate Create a

Secure Connection?

When a browser attempts to access a

website that is secured by SSL, the

browser and the web server establish an

SSL connection using a process called an

“SSL Handshake” (see diagram below).

Note that the SSL Handshake is invisible

to the user and happens instantaneously.

Essentially, three keys are used to set up the SSL connection: the public, private, and session

keys. Anything encrypted with the public key can only be decrypted with the private key,

and vice versa.

Because encrypting and decrypting with private and public key takes a lot of processing

power, they are only used during the SSL Handshake to create a symmetric session key.

After the secure connection is made, the session key is used to encrypt all transmitted data.

1. Browser connects to a web server (website) secured with SSL (https). Browser requests

that the server identify itself.

2. Server sends a copy of its SSL Certificate, including the server’s public key.

3. Browser checks the certificate root against a list of trusted CAs and that the certificate is

unexpired, unrevoked, and that its common name is valid for the website that it is

connecting to. If the browser trusts the certificate, it creates, encrypts, and sends back a

symmetric session key using the server’s public key.

4. Server decrypts the symmetric session key using its private key and sends back an

acknowledgement encrypted with the session key to start the encrypted session.


5. Server and Browser now encrypt all transmitted data with the session key.

Why Do I Need SSL?

One of the most important components of online business is creating a trusted environment

where potential customers feel confident in making purchases. Browsers give visual cues,

such as a lock icon or a green bar, to help visitors know when their connection is secured.

SSL versus TLS

TLS (Transport Layer Security) and SSL (Secure Sockets Layer) are protocols that provide data

encryption and authentication between applications and servers in scenarios where that

data is being sent across an insecure network, such as checking your email (How does the

Secure Socket Layer work?). The terms SSL and TLS are often used interchangeably or in

conjunction with each other (TLS/SSL), but one is in fact the predecessor of the other — SSL

3.0 served as the basis for TLS 1.0 which, as a result, is sometimes referred to as SSL 3.1.

Which is more secure – SSL or TLS?

It used to be believed that TLS v1.0 was marginally more secure than SSL v3.0, its

predecessor. However, SSL v3.0 is getting very old and recent developments, such as the

POODLE vulnerability have shown that SSL v3.0 is now completely insecure (especially for

web sites using it). Even before the POODLE was set loose, the US Government had already

mandated that SSL v3 not be used for sensitive government communications or for HIPAA-

compliant communications. If that was not enough … POODLE certainly was. In fact, as a

result of POODLE, SSL v3 is being disabled on web sites all over the world and for many other

services as well.

SSL v3.0 is effectively “dead” as a useful security protocol. Places that still allow its use for

web hosting as placing their “secure web sites” at risk; Organizations that allow SSL v3 use to

persist for other protocols (e.g. IMAP) should take steps to remove that support at the

soonest software update maintenance window.

Subsequent versions of TLS — v1.1 and v1.2 are significantly more secure and fix many

vulnerabilities present in SSL v3.0 and TLS v1.0. For example, the BEAST attack that can

completely break web sites running on older SSL v3.0 and TLS v1.0 protocols. The newer TLS

versions, if properly configured, prevent the BEAST and other attack vectors and provide

many stronger ciphers and encryption methods.

Public key infrastructure (PKI)

A public key infrastructure (PKI) supports the distribution and identification of public

encryption keys, enabling users and computers to both securely exchange data over

networks such as the Internet and verify the identity of the other party.


Without PKI, sensitive information can still be encrypted (ensuring confidentiality) and

exchanged, but there would be no assurance of the identity (authentication) of the other

party. Any form of sensitive data exchanged over the Internet is reliant on PKI for security.

Elements of PKI

A typical PKI consists of hardware, software, policies and standards to manage the creation,

administration, distribution and revocation of keys and digital certificates. Digital certificates

are at the heart of PKI as they affirm the identity of the certificate subject and bind that

identity to the public key contained in the certificate.

A typical PKI includes the following key elements:

A trusted party, called a certificate authority (CA), acts as the root of trust and provides

services that authenticate the identity of individuals, computers and other entities

A registration authority, often called a subordinate CA, certified by a root CA to issue

certificates for specific uses permitted by the root

A certificate database, which stores certificate requests and issues and revokes

certificates

A certificate store, which resides on a local computer as a place to store issued

certificates and private keys

A CA issues digital certificates to entities and individuals after verifying their identity. It signs

these certificates using its private key; its public key is made available to all interested

parties in a self-signed CA certificate. CAs use this trusted root certificate to create a "chain

of trust" -- many root certificates are embedded in Web browsers so they have built-in trust

of those CAs. Web servers, email clients, smartphones and many other types of hardware

and software also support PKI and contain trusted root certificates from the major CAs.

Along with an entity’s or individual’s public key, digital certificates contain information about

the algorithm used to create the signature, the person or entity identified, the digital

signature of the CA that verified the subject data and issued the certificate, the purpose of

the public key encryption, signature and certificate signing, as well as a date range during

which the certificate can be considered valid.

Problems with PKI

PKI provides a chain of trust, so that identities on a network can be verified. However, like

any chain, a PKI is only as strong as its weakest link. There are various standards that cover

aspects of PKI -- such as the Internet X.509 Public Key Infrastructure Certificate Policy and

Certification Practices Framework (RFC2527) -- but there is no predominant governing body

enforcing these standards. Although a CA is often referred to as a “trusted third party,”

shortcomings in the security procedures of various CAs in recent years has jeopardized trust

in the entire PKI on which the Internet depends. If one CA is compromised, the security of

the entire PKI is at risk. For example, in 2011, Web browser vendors were forced to blacklist

all certificates issued by the Dutch CA DigiNotar after more than 500 fake certificates were

discovered.


Configuration PKI at Cisco IOS Routers:

R5

ntp master 5

int loop 0

ip add 5.5.5.5 255.255.255.255

exit

ip http server

crypto pki server CA

hash sha512

grant auto

no sh

(Password)

show crypto pki server

R1 Hub

ntp server 5.5.5.5

do show ntp associations

do show ntp status


crypto key generate rsa modulus 2048 lable r1.cbtnuggets.com

do show crypto mypubkey rsa r1.cbtnuggets.com

crypto pki trustpoint TRUSTED-CA

enrollment url http://5.5.5.5

rsakeypair r1.cbtnuggets.com

fqdn r1.cbtnuggets.com

subject-name CN=r1,o=cbtnuggets.com

revocation-check none

exit

crypto pki authenticate TRUSTED-CA

do show crypto pki trustpoints

do show crypto pki certificates


crypto pki enroll TRUSTED-CA

show crypto pki certificates verbose TRUSTED-CA


R2

ntp server 5.5.5.5








exit



RSA-sig IKEv2 Authentication

Implementing RSA signatures for ikev2 Authentication

New: certificate map for matching

Changes in ikev2 profile

Match on certificate map

Authentication is RSA-Sig

Trust point (CA) so won't use key ring required


R1

crypto key zeroize rsa








exit



crypto pki certificate map CMAP 10

issuer-name co cbtnuggsts

exit

crypto ikev2 proposal IKEV2-PROPOSAL

encryption aes-cbc-128

integraty sha1

group 5

exit

crypto ikev2 policy IKEV2-POLICY

proposal IKEV2-PROPOSAL

exit

crypto ikev2 profile IKEV2-PROFILE

identiy local dn

match certificate CMAP

authentication remote rsa-sig

authentication local rsa-sig

pki trustpoint TRUSTED-CA

exit

crypto ipsec transform-set OUR-TEST esp-aes esp-sha-hmac

mode transport

exit


crypto ipsec profile IPSEC-PROFILE

set transform-set OUR-TEST

set ikev2-profile IKEV2-PROFILE

exit

interface Tunnel 0

ip unnumbered loop0

tunnel source ethernet 0/0



tunnel protection ipsec profile IPSEC-PROFILE

ip ospf 1 area 0

exit

R2

crypto key zeroize rsa








exit



crypto pki certificate map CMAP 10

issuer-name co cbtnuggsts

exit



integraty sha1

group 5

exit

crypto ikev2 policy IKEV2-POLICY


exit


identiy local dn





exit


crypto ipsec transform-set OUR-TEST esp-aes esp-sha-hmac

mode transport

exit

crypto ipsec profile IPSEC-PROFILE

set transform-set OUR-TEST


exit

interface Tunnel 0

ip unnumbered loop0




tunnel protection ipsec profile IPSEC-PROFILE

ip ospf 1 area 0

exit


DVTI IKEv2 Hub and Spoke RSA-Sig

crypto pki certificate map CAMP 1

issuer-name co cbtnuggets

exit

default crypto ikev2 proposal

crypto ikev2 proposal default


integrity sha256

group 14

exit

default crypto ikev2 policy


identiy local dn






virtual-template 1

exit

default cypto ipsec transform-set

crypto ipsec transform-set default esp-gcm 256

exit

default cypto ipsec profile



exit

interface virtual-template 1 type tunnel

ip unnumbered loop0




ip ospf 1 area 0

exit

R2

crypto pki certificate map CAMP 1

issuer-name co cbtnuggets

exit

default crypto ikev2 proposal



integrity sha256

group 14

exit

default crypto ikev2 policy


identiy local dn





exit

default cypto ipsec transform-set


crypto ipsec transform-set default esp-gcm 256

exit

default cypto ipsec profile



exit

interface virtual-template 1 type tunnel

ip unnumbered loop0





ip ospf 1 area 0

exit


Show Ip route ospf


IKE V2 Pushing Policy

Current Network is Hub/DVTI and Spoke/Tunnel

R1

ip local pool FLEXPOOL 172.16.0.100 172.16.0.200

aaa new-model

aaa authorization network AUTHOR-LIST local

crypto ikev2 authorization policy default

pool FLEXPOOL

exit


aaa author group cert list AUTHOR-LIST default

exit


R2

int tunnel 0

ip add negotiated

end

R3

int tunnel 0

ip add negotiated

end

R4

int tunnel 0

ip add negotiated

end


Flex VPN Client

R1 (Same last lesson)

R2

aaa new-model


ip access-list standard ROUTE-ACL

permit 10.22.22.0 0.0.0.255

permit 10.2.2.0 0.0.0.255

exit

show run int tun 0

int tun 0

tunnel destination dynamic

exit

crypto ikev2 author policy default

route set access-list ROUTE-ACL

exit


do show crypto ikev2 author policy



exit

crypto ikev2 client flexvpn OUR-CLIENT

peer 1 15.0.0.1

connect auto

client inside loop 1

client client connect tunnel 0

exit


R3

aaa new-model


ip access-list standard R3-ROUTE-ACL

permit 10.33.33.0 0.0.0.255

permit 10.3.3.0 0.0.0.255

exit

int tun 0


exit


route set access-list R3-ROUTE-ACL

exit




exit


peer 1 15.0.0.1


connect auto



exit

show crypto engine connecions active

int loop 2

ip add 10.33.33.33 255.255.255.255

exit

R4

aaa new-model


ip access-list standard R4-ROUTE-ACL

permit 10.44.44.0 0.0.0.255

permit 10.4.4.0 0.0.0.255

exit

int tun 0


exit


route set access-list R4-ROUTE-ACL

exit




exit


peer 1 15.0.0.1

connect auto



exit


int loop 2

ip add 10.44.44.44 255.255.255.255

exit

R1

ip access-list standard HUB-ACL


route set access-list HUB-ACL

exit


Spoke 2 Spoke flex VPN

New on HUB:

IP nhrp network-id 1

IP nhrp redirect

New on Spokes

Static Tunnel +Template

Ip nhrp network-id 1

IP nhrp redirect

IP nhrp shortcut virtual-template

R1

aaa new-model

aaa authorization network default local


pool FlexPool

route set interface

route set access-list HUB-ACL

exit

ip access-list standard HUB-ACL

permit 10.0.0.0 0.255.255.255

exit

ip local pool FlexPool 172.16.0.100 172.16.0.200




integrity sha256

group 14

exit

crypto ikev2 profile default

identity local fqdn r1.cbtnuggets.com

match identity remote fdqn domain cbtnuggets.com



aaa authentication group cert list default default

virtual-template 1

exit

interface loopback 10

ip address 172.16.1.1 255.255.255.255

exit

interface Virtual-Tempelete1 type tunnel

ip unnumbered



ip nhrp redirect


R2


route set interface


route set access-list R2-Route-ACL

exit

ip access-list standard R2-Route-ACL

permit 10.2.2.0 0.0.0.255

exit



integrity sha256

group 14

exit







virtual-template 1

exit


set ikev2-profile default

exit

interface tunnel1

ip address negotiated


ip nhrp shortcut virtual-template 1


ip nhrp redirect




exit


ip unnumbered tunnel 0


ip nhrp redirect


exit

R3


route set interface


exit


permit 10.3.3.0 0.0.0.255

exit



integrity sha256

group 14

exit








virtual-template 1

exit



exit

interface tunnel1




ip nhrp redirect




exit




ip nhrp redirect


exit


R4


route set interface


exit


permit 10.4.4.0 0.0.0.255

exit



integrity sha256

group 14

exit







virtual-template 1

exit



exit

interface tunnel1





ip nhrp redirect




exit




ip nhrp redirect


exit

show crypto session

After ping on 10.2.2.2

show crypto session


show crypto ikev2 sa


show ip nhrp shotcut

Show ip route

Flex VPN troubleshooting

Verify:

Basic connectivity

IKEV2 hub to spoke

Hub net to spoke net

Routing Information

IKEV2,IPSEC configs


HSRP redirect/shortcuts

show crypto session

show crypto ikev2 sa

show ip nhrp shotcut

show crypto ikev2 client flexvpn

show run int tunnel 0

show ip nhrp traffic

show ip nhrp

show ip route

show crypto ikev2 stats

show crypto ikev2 stats exchange

show crypto ikev2 proposal

show crypto ikev2 policy

show crypto ipsec profile

show crypto ikev2 authorization policy

show run | section crypto

show crypto map

show crypto ikev2 sa details

show crypto ipsec sa

GETVPN

GET VPN

GET (Group Encrypted Transport) VPN is a VPN technology which introduces the

concept to eliminate point-to-point tunnels (site-to-site VPN) and associated overlay routing

(DMVPN) since it relies on WAN routing. It enables any-to-any VPN connectivity using a

group IPSec security paradigm.

In addition to IPSec, the following are the building blocks for GET VPN solution:

Group Domain of Interpretation (GDOI)


GDOI is a group key management protocol used to provide a set of IPSec keys to a group of

IOS devices called Group Members (GM) that wish to communicate securely i.e. GDOI is run

between a GM and a Key Server (KS). These keys are periodically refreshed on all devices

using a process called rekey.

GDOI is a "Phase 2" protocol which is protected by "Phase 1 Security Association (SA)". IKE

Phase 1 remains the same as in traditional IPSec. All Group Members authenticate themselves

using IKE to the device providing keys (called a Key Server) which is statically configured

for all Group Members. All IKE authentication methods are supported - Pre-Shared Keys

(PSK) or RSA-Signature (PKI) or RSA-Encryption.

GDOI introduces two different types of encryption keys- the Key Encryption Key (KEK) is

used to secure GET VPN control plane, and the Traffic Encryption Key (TEK) which

encrypts the data traffic.

RFC 3547 defines GDOI. GDOI runs on UDP port 848. There are six new payloads for

GDOI:

a) GDOI SA

b) SA KEK which follows the SA payload

C) SA TEK which follows the SA payload

d) Key Download Array (KD)

e) Sequence Number (SEQ)

f) Proof of Possession (POP)

Key Server (KS)

A Key Server is a Cisco IOS device which is responsible for creating and maintaining GET

VPN control plane. All IPSec policies like interesting traffic, IPSec security protocols, rekey

timers, etc are manually defined on the Key Server, and are downloaded by Group Members

using registration.

Even if a Group Member owns a particular network or not, it downloads the interesting traffic

defined on the Key Server (using ACL).

Co-operative Key Server (COOP KS)

GET VPN supports multiple KS if a KS fails or becomes unreachable. A Group Member can

be configured to register with a list of KSs.

When COOP KSs boot, all KSs assume a "secondary" role and begin election process. A KS

with highest priority wins the election (in case of a tie, the KS with highest IP Address wins)

and becomes the "primary" KS. Other KSs remain in "secondary" state.

A GM can register with either a Primary or Secondary KS. However, only Primary KS sends

rekey messages. If a Secondary KS does not "hear" from the Primary KS for a period of time,

the Secondary KS tries to contact Primary KS for updated information. If the Secondary KS

still does not hear from Primary KS, re-election takes place and a Primary KS is elected.

Group Member (GM)


A GM is an IOS device responsible to handle GET VPN data plane. These are the actual

devices who forms IPSec connections between them. A GM is statically configured with IKE

Phase 1 parameters and Key Server information. The GMs download IPSec policies and keys

from the KS during registration.

Rekeying

A KS performs rekey process (sending new keys when existing keys are about to expire)

which includes refreshing keys and distributing to the GMs. GET VPN supports two types of

rekey messages:

a) Unicast rekey: In this process, the KS generates a rekey message and sends multiple copies

of the message, one for each GM. The GM sends an ACK message upon receiving the rekey

message.

b) Multicast rekey: In this process, the KS generates a rekey message and sends a single copy

of the message to the multicast address defined in the configuration. Each GM joins the

multicast group at the time of registration and hence receives the rekey message. No ACK

messages are sent by GM upon receiving the rekey message.

Time-based Anti-Replay (TBAR)

In traditional IPSec, anti-replay capability is available using counter-based sliding window.

When the sender sends a packet with a sequence number, the receiver uses a sliding window

to determine whether a packet is acceptable, or has arrived out-of-sequence.

Due to group SA in GET VPN, counter-based sliding window is ineffective. In GET VPN, all

GMs can communicate with each other using a common IPSec policy and a shared SA.

Hence, there is no need to negotiate IPSec between GMs. GET VPN uses time-based anti-

replay which is based on a pseudotime clock maintained on the KS.

GET VPN uses Tunnel mode of IPSec, but instead of using the tunnel endpoints in the new IP

header, it reuses the original IP header as the new Tunnel header (much like IPSec Transport

mode). This provides an advantage as the existing routing infrastructure can be used and no

separate routing instance needs to be run for GET VPN.

Note

GET VPN is not suitable to run over Internet since it reuses the original IP header as Tunnel

IP header. This can cause end-to-end routing issues as the traffic from Private network will

not be able to reach the remote end.

Hence, GET VPN is best suited for Private infrastructure like MPLS VPN or VPLS.

How GDOI Works

RFC 3547 defines two new exchanges for GDOI:

i) GROUPKEY-PULL Exchange

This exchange is also called Registration. This Phase 2 exchange downloads keys for a

group's Re-key SA and Data-security SA. The Re-key SA includes Key Encryption Key


(KEK) common to the group, and the Data-security SA includes Traffic Encryption Key

(TEK) used to encrypt/decrypt data traffic.

The Group Member (Initiator) initiates and contacts the Key Server. The GM is configured

with the group identifier and acceptable Phase 1 policy. Once Phase 1 is complete, the

initiator moves to GDOI protocol. The initiator builds a NONCE payload by choosing the Ni

(Nonce value by initiator), builds an ID payload using the group identifier, and generates

HASH(1). The first GDOI message is also called Request message.

Upon receipt of the GDOI message, the Key Server (Responder) processes the NONCE and

ID payloads. It verifies that its database contains the group information for the group ID. It

constructs the second GDOI message, chooses the Nr (Nonce value by responder) for

NONCE payload, the policy for the group in the ID payload, followed by SA TEK payload

for traffic SAs and SA KEK payload, and generates HASH(2). The second GDOI message is

also called Push message.

The GM receives the second GDOI message, validates the HASH(2) and process NONCE

and SA payloads. If the group policy uses Certificates for authorization, the GM generates a

hash with Ni and Nr, and signs it. This becomes the POP payload. The CERT payload holds

the Public Key. The GM creates the third GDOI message using POP and CERT payloads, and

generates HASH(3). The third GDOI messages is also called ACK message.

Upon receipt of the third GDOI message, the KS validates the hash. It constructs a fourth

GDOI message including the SEQ payload containing the sequence number, the KD payload

containing keys corresponding to policy previously sent in SA TEK and KEK, and POP and

CERT payloads (if needed), and generates HASH(4). The fourth message is also called Key

Download message.

The GM receives the fourth GDOI message and validates the hash. It then processes the SA

TEK and KEK payloads.

The ISAKMP Header is protected by IKE Phase1 while everything after the header is

encrypted. KE payload is used if Perfect Forward Secrecy (PFS) is set.


ii) GROUPKEY-PUSH Exchange

The GROUPKEY-PUSH message replaces a Re-key SA &/or Data-security SA, and it can be

pushed using unicast or multicast. It is only a single message generated by the KS. It includes

new keys when the key-lifetime is about to finish.

Configuration Lab: R5 key server 5.5.5.5(SP MPLS)

R5


hash sha256



group 14

lifetime 180

encryption aes 256

exit


crypto key gen rsa general lable GETVPN mod 1024 exportable

crypto ipsec transform-set OUR-TSET esp-aes 192 esp-sha-hmac

exit

crypto ipsec profile GDOI-PROFILE

set transform-set OUR-TSET

set security-association lifetime seconds 300

exit

crypto gdoi group OUR-GETVPN

identity number 6783

server local

adress ipv4 5.5.5.5

rekey transport unicast

rekey lifetime seconds 600

rekey retransmit 10 number 2

rekey authentication mypubkey rsa GETVPN

sa ipsec 1

profile GDOI-PROFILE

match adress ipv4 101

replay time window-size 5

exit

exit


exit

ip access-list extended 101

permit ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255

exit

router ospf 1

net 0.0.0.0 255.255.255.255 area 0

end

R1


hash sha256


group 14

lifetime 180

encryption aes 256

exit


crypto gdoi group OUR-GETVPN

identity number 6783

server adress ipv4 5.5.5.5

exit

crypto map GETVPN-MAP gdoi

set group OUR-GETVPN

exit

interface e 0/0


crypto map GETVPN-MAP


exit

router ospf 1

net 0.0.0.0 255.255.255.255 area 0

exit

Show crypto gdoi

Show crypto gdoi ks policy


Show crypto gdoi ks rekey

Show crypto gdoi ks member


At R1

Show crypto isakmp sa

Show crypto isakmp sa detail

Show crypto gdoi




ASA IOS IKEV2 (site to site IPsec VPN)

ASA

object network INSID-NET

subnet 172.16.50.0 255.255.255.0

exit

object network R6-Network

subnet 10.6.6.0 255.255.255.0

exit

access-list CRY-ACL permit ip object INSID-NET object R6-Network

route outside 10.6.6.0 255.255.255.0 10.10.10.6 1

crypto ikev1 policy 1

hash sha


group 5

lifetime 86400

encryption aes

exit

crypto ikev1 enable outside

crypto ikev2 policy 1

encryption aes-192 aes

integrity sha256 sha

group 5 2

lifetime second 86400

exit

crypto ikev2 enable outside

crypto ipsec ikev1 transform-set OUR-TSET esp-aes esp-sha-hmac

crypto ipsec ikev2 ipsec-proposal IPSECV2-AES

protocol esp encryption aes

protocol esp integrity sha-1 md5

exit

group-policy GROUP-A internal

group-policy GROUP-A attributes

VPN-tunnel-protocol ikev1 ikev2


exit

tunnel-group 10.10.10.6 type ipsec-l2l

tunnel-group 10.10.10.6 general-attributes

default-group-policy GROUP-A

exit

tunnel-group 10.10.10.6 general-attributes

ikev1 pre-share-key cisco123

ikev2 remote-autentication pre-share-key cisco123

ikev2 local-authenntication pre-share-key cisco123

exit

crypto map OUR-MAP 1 match address CRY-ACL

crypto map OUR-MAP 1 set peer 10.10.10.6

crypto map OUR-MAP 1 set ikev1 transform-set OUR-TSeT

crypto map OUR-MAP 1 set ikev2 ipsec-proposal IPSECV2-AES

crypto map OUR-MAP interface outside

Router


hash sha


group 5

lifetime 86400

encryption aes

exit


crypto ipsec transform-set OUR-TSET esp-aes esp-sha-hmac

exit

ip access-list extended CRY-ACL

permit ip 10.6.6.0 0.0.0.255 172.16.50.0 0.0.0.255

exit

crypto map OUR-MAP ipsec-isakmp

match address CRY-ACL

set peer 10.10.10.200

set transform-set OUT-TSET

exit

int g 0/0

crypto map OUR-MAP

exit

Ping 172.16.50.100 source 10.6.6.6

show crypto isakmp sa


show crypto isakmp sa detail

Show crypto session

Show crypto engine connections active

Or on Router



integrity sha1

group 5 2

exit

crypto ikev2 policy default


exit

crypto ikev2 keyring KEYRING1

peer ASA

address 10.10.10.200

identity address 10.10.10.200

pre-shared-key local cisco123

pre-shared-key remote cisco123

exit

exit



match address local 10.10.10.6

match identity remote address 10.10.10.200

autentication remote pre-share

autentication local pre-share

keyring local KEYRING1

exit

crypto ipsec transform-set OUR-V2TSET esp-aes esp-sha-hmac

exit

ip access-list extended 102

permit ip 10.6.6.0 0.0.0.255 172.16.50.0 0.0.0.255

exit

crypto map OUR-V2MAP 1 ipsec-isakmp

match address 102

set peer 10.10.10.200

set transform-set OUR-V2TSET


exit

int e0/0

crypto map OUR-V2MAP

end


References

Cisco web site https://cisco.com

CBT Nuggets videos "SIMOS course"

Wikipedia website https://www.wikipedia.org

Others videos and stander documentations

https://cisco.com/

https://www.wikipedia.org/

Date post:	10-Aug-2015
Category:	Engineering
Upload:	mohmed-abou-elenein-attia
View:	293 times
Download:	11 times

CCNP Security SIMOS 300-209=vpn 642-648

Engineering