Professional Documents
Culture Documents
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
2|Page
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
Traffic between remote sites does not need to traverse the hub (headquarter VPN router).
DMVPN deployments include mechanisms such as GRE tunneling and IPsec encryption
with Next Hop Resolution Protocol (NHRP) routing that are designed to reduce
3|Page
administrative burden and provide reliable dynamic connectivity between sites. It is in every
companys 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
4|Page
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
7|Page
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)
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
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
8|Page
Troubleshoot DMVPN
sh ip nhrp
sh ip rout eigrp
sh int tunnel 0
sh ip eigrp neighbor
sh run | tunnel 0
logging buffered 7
sh ip route
logging console 7
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 DiffieHellman 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 DiffieHellman 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
9|Page
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 doesnt.
3. IKEv2 supports MOBIKE while IKEv1 doesnt.
4. IKEv2 has built-in NAT traversal while IKEv1 doesnt.
5. IKEv2 can detect whether a tunnel is still alive while IKEv1 cannot.
10 | P a g e
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
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.
11 | P a g e
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.
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
12 | P a g e
Eng.Mohamed Abou Elenein
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 source gig 0/0
tunnel destination 15.0.0.1
tunnel mode ipsec ipv4
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
Interface tunnel 1
Service-policy output POLICY_MAP_NAME
Exit
We use it if we have more and more branches this occur between HUB Router and Spoke
IPSEC
R2
crypto isakmp policy 1
encr aes 192
authentication Pre-share
group 5
exit
crypto isakmp key cisco123 adress 0.0.0.0
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 tunnel 2
tunnel mode ipsec ipv4
ip unnumbered loopback 0
tunnel source serial 1/0
tunnel destination 15.0.0.1
tunnel protection ipsec profile OUR-IPSEC-PROFILE
exit
int loop 0
ip address 2.2.2.2 255.255.255.0
exit
router eigrp 777
no auto-summary
15 | P a g e
network 2.0.0.0
network 10.0.0.0
end
R3
crypto isakmp policy 1
encr aes 192
authentication Pre-share
group 5
exit
crypto isakmp key cisco123 adress 0.0.0.0
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 tunnel 2
tunnel mode ipsec ipv4
ip unnumbered loopback 0
tunnel source serial 1/0
tunnel destination 15.0.0.1
tunnel protection ipsec profile OUR-IPSEC-PROFILE
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
16 | P a g e
17 | P a g e
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.
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.
18 | P a g e
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
R5
If we want to change proposal
Crypto ikev2 proposal OUR-PROPOSAL
encryption XXXXXXX
group XXXXX
integrity XXXXX
20 | P a g e
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
crypto ipsec profile default
set ikev2-profile OUR-PROFILE
exit
int tunnel 3
ip unnumbered loop 0
tunnel source gig 0/1
tunnel destination 45.0.0.5
tunnel mode ipsec ipv4
ip mtu 1400
ip tcp adjust-mss 1360
tunnel protection ipsec profile default
exit
ip route 10.5.0.0 255.255.255.0 tunnel 3 200
Show crypto ikev2 sa
21 | P a g e
Certificate install
H-----ASH
A-----UHNTICATION
G-----ROUP (DH)
L------IFE time
E ------NCRYPT
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 clienttypically a web server (website) and a browser; or a mail
server and a mail client (e.g., Outlook).
22 | P a g e
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 textleaving 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 CAs 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 CAs (in this case DigiCerts) 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 organizations identity. Since the browser trusts
23 | P a g e
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 servers 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 servers 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.
24 | P a g e
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 HIPAAcompliant 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.
25 | P a g e
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 certificate database, which stores certificate requests and issues and revokes
certificates
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 entitys or individuals 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.
26 | P a g e
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
27 | P a g e
28 | P a g e
29 | P a g e
R2
ntp server 5.5.5.5
crypto key generate rsa modulus 2048 lable r2.cbtnuggets.com
crypto pki trustpoint TRUSTED-CA
enrollment url http://5.5.5.5
rsakeypair r2.cbtnuggets.com
fqdn r2.cbtnuggets.com
subject-name CN=r2,o=cbtnuggets.com
revocation-check none
exit
crypto pki authenticate TRUSTED-CA
crypto pki enroll TRUSTED-CA
Authentication is RSA-Sig
30 | P a g e
R1
crypto key zeroize rsa
crypto key generate rsa modulus 1024 lable 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
crypto pki enroll TRUSTED-CA
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
31 | P a g e
35 | P a g e
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
crypto ikev2 profile IKEV2-PROFILE
aaa author group cert list AUTHOR-LIST default
exit
36 | P a g e
R2
int tunnel 0
ip add negotiated
end
R3
int tunnel 0
ip add negotiated
end
R4
int tunnel 0
ip add negotiated
end
37 | P a g e
int tun 0
tunnel destination dynamic
exit
crypto ikev2 author policy default
route set access-list ROUTE-ACL
exit
38 | P a g e
R3
aaa new-model
aaa authorization network AUTHOR-LIST local
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
tunnel destination dynamic
exit
crypto ikev2 author policy default
route set access-list R3-ROUTE-ACL
exit
do show crypto ikev2 author policy
connect auto
client inside loop 1
client client connect tunnel 0
exit
show crypto engine connecions active
int loop 2
ip add 10.33.33.33 255.255.255.255
exit
R4
aaa new-model
aaa authorization network AUTHOR-LIST local
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
tunnel destination dynamic
exit
crypto ikev2 author policy default
route set access-list R4-ROUTE-ACL
exit
do show crypto ikev2 author policy
New on HUB:
IP nhrp network-id 1
IP nhrp redirect
New on Spokes
Ip nhrp network-id 1
IP nhrp redirect
R1
aaa new-model
aaa authorization network default local
crypto ikev2 authorization policy default
pool FlexPool
route set interface
route set access-list HUB-ACL
exit
interface loopback 10
ip address 172.16.1.1 255.255.255.255
exit
R2
crypto ikev2 authorization policy default
route set interface
42 | P a g e
interface tunnel1
ip address negotiated
ip nhrp network-id 1
ip nhrp shortcut virtual-template 1
43 | P a g e
ip nhrp redirect
tunnel source ethernet 0/0
tunnel destination 15.0.0.1
tunnel protection ipsec profile default
exit
R3
crypto ikev2 authorization policy default
route set interface
route set access-list R3-Route-ACL
exit
interface tunnel1
ip address negotiated
ip nhrp network-id 1
ip nhrp shortcut virtual-template 1
ip nhrp redirect
tunnel source ethernet 0/0
tunnel destination 15.0.0.1
tunnel protection ipsec profile default
exit
45 | P a g e
R4
crypto ikev2 authorization policy default
route set interface
route set access-list R4-Route-ACL
exit
interface tunnel1
46 | P a g e
ip address negotiated
ip nhrp network-id 1
ip nhrp shortcut virtual-template 1
ip nhrp redirect
tunnel source ethernet 0/0
tunnel destination 15.0.0.1
tunnel protection ipsec profile default
exit
47 | P a g e
Show ip route
Verify:
Basic connectivity
Routing Information
IKEV2,IPSEC configs
48 | P a g e
HSRP redirect/shortcuts
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:
49 | P a g e
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)
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).
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.
50 | P a g e
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.
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 antireplay 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.
(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.
52 | P a g e
R5
crypto isakmp policy 10
hash sha256
authentication pre-share
53 | P a g e
group 14
lifetime 180
encryption aes 256
exit
crypto key gen rsa general lable GETVPN mod 1024 exportable
sa ipsec 1
profile GDOI-PROFILE
match adress ipv4 101
replay time window-size 5
exit
exit
54 | P a g e
exit
router ospf 1
net 0.0.0.0 255.255.255.255 area 0
end
R1
crypto isakmp policy 10
hash sha256
authentication pre-share
group 14
lifetime 180
encryption aes 256
exit
interface e 0/0
55 | P a g e
router ospf 1
net 0.0.0.0 255.255.255.255 area 0
exit
56 | P a g e
57 | P a g e
At R1
Show crypto isakmp sa
58 | P a g e
59 | P a g e
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
authentication pre-share
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
60 | P a g e
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
crypto isakmp policy 1
hash sha
authentication pre-share
group 5
lifetime 86400
encryption aes
exit
crypto isakmp key cisco123 address 10.10.10.200
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
Or on Router
crypto ikev2 proposal IKEV2-PROPOSAL
encryption aes-cbc-128
integrity sha1
group 5 2
exit
crypto ikev2 policy default
proposal IKEV2-PROPOSAL
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
62 | P a g e
63 | P a g e
References
Cisco web site https://cisco.com
CBT Nuggets videos "SIMOS course"
Wikipedia website https://www.wikipedia.org
Others videos and stander documentations
64 | P a g e