CCNP Security SIMOS 300-209=vpn 642-648

1 | P a g e Eng.Mohamed Abou Elenein
By
Eng. Mohamed Abou-Elenein Attia
Email: m.aboelenein89@gmail.com

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

CCNP Security SIMOS 300-209=vpn 642-648

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (11)

Similar to CCNP Security SIMOS 300-209=vpn 642-648

Similar to CCNP Security SIMOS 300-209=vpn 642-648 (20)

Recently uploaded

Recently uploaded (20)

CCNP Security SIMOS 300-209=vpn 642-648