CCNP Security (Simos)

CCNP Security
(SIMOS)
Pretty Good Privacy(PGP)
Email and file encryption system

based on public key
cryptography.
Uses a concept call trusted

introducing.
Trusted Introducer
Two Ways To Use PKI To Secure
Messages
They can digitally sign the
messages for authenticity and
integrity with their own private key
as the sender and verify the
signature with the corresponding
private key as the receiver.
They can encrypt the message with

the public key of the other party,
and the receiver will decrypt the
message with its own private key.
Steps For User A And C To
Communicate Securely
1. User B digitally signs the public key of user A (which it
has locally) and sends it to user C.
2. User C can then verify the signature of user B (because it

has the public key of user B) and can consider the public
key of user A to be authentic.
3. User B digitally signs the public key of user C (which it

has locally) and sends it to user A.
4. User A can then verify the signature of user B (because it

has the public key of user B) and consider the public key
of user C to be authentic.
Group Encrypted Transport
VPN
Large-scale, connectionless, tunnel-free
transmission protection.
Used with Multiprotocol Label Switching

(MPLS), IP, Frame Relay, and ATM
networks.
Ideal cryptographic solution for MPLS

VPNs that need site-to-site encryption.
Uses the concept of trusted group

members.
Group Controller/Key
Servers
Authenticates all group members.
Performs admission control to the GET

VPN domain.
Creates and supplies group

authentication key as security
associations (SA) to group members
Distribute keys and policies to all

registered and authenticated group
member routers.
Group Members
Provide transmission protection
to sensitive site-to-site
(member-to-member) traffic.
All communication between a

key server and group members is
encrypted and secured using the
Internet Key Exchange (IKE)
Group Domain of Interpretation
(GDOI) protocol.
GET VPN Key Server And Group
Member
IKE GDOI Keys
TEK: A key that is used to protect

traffic between group members.
KEK: A key this is used to protect

rekeys (during a key refresh)
between key servers and group
members.
GET VPN Traffic Exchange
GET VPN group members that have valid
group IPsec SAs assume that traffic they
encrypt can be decrypted by some other
legitimate GET VPN group member.
The group member encrypts the multicast

data, with header preservation, and the
packet is switched out of the router.
The replication of the multicast packet is

performed in the core based on the
source and multicast group IP address
Packet Security Services
Packet confidentiality using
cryptographic encryption algorithms such
as AES or 3DES.
Packet integrity and authenticity using

cryptographic HMAC.
Cisco-proprietary time-based (instead of

sequence numberbased) antireplay
protection mechanism.
Differences between GDOI and IKE
GDOI IKE SAs do not need to linger

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

between all peers in a VPN, only between
each group member and the key server.
Rekeying Consideration
If most of the group members
are only unicast capable, use
unicast rekeying.
If most of the group members

are capable of multicast and the
entire enterprise network is
capable of multicast, use
multicast rekeying.
Unicast Vs Multicast
Rekeying
GET VPN Benefits
Very scalable in that the

configuration does not grow
significantly when adding group
members in a full mesh.
Provides scalable support for

multicast traffic.
GET VPN Limitation
VPN addresses must be routable in the
transport network. This is because of the use
of the original IP header, and in most cases, it
prevents GET VPNs from being used over the
Internet.
The compromise of one peer has a larger effect

because the group shares session keys.
Key servers must be available during rekeys

and registration for the entire network to
operate
IPSec IKEv1
Needs a pre-shared key for skey
calculation, which is used in order to
decrypt/encrypt Main Mode packet 5 (MM5)
and subsequent IKEv1 packets.
The skey is derived from the Diffie-Hellman

(DH) computation and the pre-shared key.
That pre-shared key needs to be

determined after MM3 (responder) or MM4
(initiator) is received, so that the skey,
which is used in MM5/MM6, can be
computed.
Keyring Selection Criteria
ASA IKEv1 Configuration
asa1(config)#crypto ikev1 policy 1
asa1(config-ikev1-policy)#authentication
pre-share
asa1(config-ikev1-policy)#encryption aes
asa1(config-ikev1-policy)#hash sha
asa1(config-ikev1-policy)#group 2
asa1(config-ikev1-polocy)#lifetime 86400
asa1(config)#crypto ikev1 enable outside
asa1(config)#crypto ipsec ikev1 transform-
set ikev1-set esp-aes esp-sha-hmac
asa1(config)#access-list ikev1-list
extended permit ip 192.168.1.0
255.255.255.0 172.16.1.0 255.255.255.0
asa1(config)#tunnel-group 10.10.10.2
type ipsec-l2l
asa1(config)#tunnel-group 10.10.10.2
ipsec-attributes
asa1(config-tunnel-ipsec)#ikev1 pre-
shared-key this_is_a_key
asa1(config)#crypto map ikev1-map 1
match address ikev1-list
asa1(config)#crypto map ikev1-map 1 set
peer 10.10.10.2
asa1(config)#crypto map ikev1-
map 1 set ikev1 transform-set
ikev1-set
asa1(config)#crypto map ikev1-
map interface outside
tunnel-group 172.16.1.1 type
ipsec-l2l
tunnel-group 172.16.1.1 ipsec-
attributes
ikev2 remote-authentication
pre-shared-key <PRESHARED
KEY>
ikev2 local-authentication pre-
shared-key <PRESHARED KEY>
Sequence Crypto Map
Crypto Map Seq_No_1
deny packets from A.3 to B
deny packets from A.3 to C
permit packets from A to B
permit packets from A to C
Crypto Map Seq_No_2

permit packets from A.3 to B
permit packets from A.3 to C
Using Dynamic Crypto Maps
Peers with dynamically assigned public IP addresses.
Both LAN-to-LAN and remote access peers can use

DHCP to obtain a public IP address. The ASA uses
this address only to initiate the tunnel.
Peers with dynamically assigned private IP

addresses.
Peers requesting remote access tunnels typically

have private IP addresses assigned by the headend.
Generally, LAN-to-LAN tunnels have a
predetermined set of private networks that are
used to configure static maps and therefore used
to establish IPsec SAs.
DMVPN Models
Hub-and-spoke: A hub-and-spoke DMVPN
requires that each branch (spoke) have a
point-to-point GRE interface that is used
to build a tunnel to the hub router.
Spoke-to-spoke: A spoke-to-spoke
DMVPN requires that each branch
(spoke) have an mGRE interface through
which dynamic spoke-to-spoke tunnels
are used for spoke-to-spoke traffic. This
model provides a scalable configuration
for all involved devices and also provides
direct spoke-to-spoke communication.
DMVPN Benefits
Hub router configuration reduction:
The DMVPN feature allows you to create a single
mGRE tunnel interface and a single IPsec profile, and
does not require crypto ACLs on the hub router.
Automatic IPsec initiation:

GRE relies on NHRP to configure and resolve peer
destination addresses.
Support for spoke routers configured with dynamic

addressing:
DMVPNs allow spoke routers to have dynamic interface
IP addresses and to use NHRP to register the spoke
routers interface IP address with the hub router.
Building Block Of DMVPN
mGRE: mGRE allows a single Generic Routing
Encapsulation (GRE) interface to support
multiple GRE tunnels as GRE support IP multicast
and non-IP protocols to traverse the interface as
well.
NHRP: The NHRP database maintains mappings

between the router (public, physical interface)
and the tunnel (inside the tunnel interface) IP
addresses of each spoke. Each spoke registers
its public and internal tunnel addresses when it
boots and queries the NHRP database for the
addresses of other spokes.
IPsec: Provides transmission protection for GRE

tunnels.
IP Address Domain
The enterprise addressing space, which is
sometimes referred to as the private or
inside addresses. These are the addresses
that are assigned to the (m)GRE interfaces
and are registered with the NHRP server by
each spoke.
The infrastructure addressing space, which

is sometimes referred to as the service
provider, public, or outside addresses. These
are the addresses on the routers physical
interfaces and used as addresses in tunnel
envelopes (the source and destination
addresses in the GRE/IPsec packet headers).
DMVPN Hub And Spoke
Model
DMVPN Hub And Spoke Initial Properties
The hub knows the outer and inner IP

addresses of each spoke in its NHRP
database.
Three spoke-to-hub GRE/IPsec tunnels

are created.
Any traffic from a spoke (whether to a

hub or another spoke) must travel
through the hub.
DMVPN Spoke To Spoke Tunnel
Creation
3. R2 consults its local NHRP cache for
R4s tunnel IP address and finds no
entry. It sends an NHRP query to the
NHRP server (the DMVPN hub router) to
resolve the inner (tunnel) address to an
external physical IP address on R4.
4. The NHRP server, which maintains inner

(tunnel) and outer (physical) addresses
for spoke routers, sends an NHRP reply
to R2, which informs it that the inner
tunnel IP on R4 is reachable through its
outer (physical) IP address.
Creation
1. Dynamic routing (already configured

over the permanent hub-to-spoke
GRE/IPsec tunnels) populates each
spokes routing table so that each
spoke knows about the subnets
behind the other spokes.
2. R2 consults its routing table for a

route to the subnet behind R4. The
routing table provides a next-hop IP
address of R4s tunnel IP.
DMVPN Spoke To Spoke Tunnel Creation
5. R2 receives the response from the server
and enters it into the local NHRP cache.
IPsec is triggered on R2 to create an IPsec
tunnel directly to the outer (physical)
address on R4. R2 initiates an IKE session to
the outer (physical) address of R4 using its
outer (physical) address and then negotiates
IPsec security associations (SA) for a spoke-
to-spoke GRE tunnel.
6. After the IPsec tunnel is created, R2 will

create a GRE tunnel to the outer (physical)
address on R4, and all traffic between R2
and R4 will now flow through this tunnel
with no more participation by the hub router.
Creation
7. At this point, only traffic from R2 to
R4 (one direction) has been enabled.
8. For two-way traffic, R4 needs next-

hop information for the subnet
behind R2. R4 queries the NHRP
server. After it receives the NHRP
response from the NHRP server, the
return path is mapped to the newly
built GRE tunnel and the response
traffic is now sent directly to R2,
encapsulated in the GRE/IPsec tunnel.
DMVPN Limitation
It requires PKI-based
authentication of peers to
provide scalable spoke-to-spoke
IKE authentication
It can be more complex to

troubleshoot than classic IPsec
tunnels because of the required
understanding of NHRP and
mGRE as well as GRE and IPsec.
Consideration For Deploying DMVPN
Hardware and software on existing
routers: This is needed to determine the
performance of the routers and whether
the Cisco IOS Software release supports
DMVPN features.
Cryptographic standards and security

requirements: Information concerning
local security requirements and security
policies will dictate information such as
cryptographic algorithms, key lengths,
and tunneling protocols.
DMVPN General Deployment
Guidelines
Use DMVPNs to deploy large hub-and-
spoke or full mesh VPN networks.
Use dynamic routing protocols to

route traffic across the DMVPNs.
DMVPN is a suitable technology for

providing secure paths over insecure
networks such as the Internet
because it hides internal IP
addressing.
Tunnel Interface Header Type
Support
A passenger protocol or
encapsulated protocol, such as
IP, AppleTalk, DECnet, or IPX.
A carrier protocol (GRE in this

case).
A transport protocol (IP only in

this case).
GRE Limitations
GRE provides no cryptographic protection for traffic
and must be combined with IPsec to provide it.
There is no standard way to determine the end-to-

end state of a GRE tunnel. Cisco IOS Software
provides proprietary GRE keepalives for this
purpose.
It can be CPU intensive on some platforms.
Tunnels can sometimes cause maximum

transmission unit (MTU) and IP fragmentation-
related issues.
GRE Point To Point
Configuration
They are typically used as simple point-to-
point tunnels that act like point-to-point
WAN links or as the connections from spoke
to hub router in hub-and-spoke VPNs.
There is a separate GRE tunnel interface

configured on each peer for each GRE peer.
They do not require NHRP because other

peers (their destination tunnel address) are
statically configured.
They provide support for unicast, multicast,

and broadcast traffic.
Configure GRE Interface on
Spoke
Spoke(config)# interface tunnel0
Spoke(config-if)# tunnel mode gre ip
Spoke(config-if)# tunnel source 172.17.2.4
Spoke(config-if)# tunnel destination 172.17.0.1
Spoke(config-if)# ip address 10.1.1.2

255.255.255.0
Steps To Configuring DMVPN
Hub
1. (Optional) Configure an IKE policy. Recall that if one is not created, the hub
router will use default IKE policies.
2. (Optional) Generate/configure spoke authentication credentials. This

typically involves enrolling into a PKI to obtain a certificate for
authentication purposes.
3. Configure an IPsec profile with an optional transform set. If a transform set

is not configured, the router will use default IPsec transform sets.
4. Create an mGRE tunnel interface.
5. Configure an NHRP server on the mGRE interface.
6. Associate the IPsec profile with the mGRE interface to configure tunnel
protection.
7. Configure an IP address and IP fragmentation/segmentation parameters on

the mGRE interface.
Configuring Optional IKE Policies On
Hub
crypto isakmp policy 10
authentication pre-share
group 14
crypto isakmp key cisco123 address 0.0.0.0

0.0.0.0
Configuring IPSec Profile
crypto ipsec transform-set anyt esp-3des esp-md5-hmac
crypto ipsec profile cisco
set security-association lifetime seconds 120
set transform-set anyt

GRE Point To Multipoint
Configuration
Only one tunnel interface must be
configured for a router to support multiple
GRE peers. For a hub-and-spoke network, a
single mGRE tunnel interface on the hub
can be used for many spoke peers.
Devices taking advantage of mGRE

interfaces require the use of NHRP to build
dynamic GRE tunnels. This also provides
the option to have peers (usually spokes)
that are dynamically addressed.
mGRE interfaces also support unicast,

multicast, and broadcast traffic.
mGRE Tunnel
Configure mGRE Interface On Hub
interface tunnel0
tunnel mode gre multipoint
tunnel source GigabitEthernet0/0
tunnel key 13579
ip address 10.1.1.1 255.255.0.0
ip mtu 1400
ip tcp adjust-mss 1360
tunnel protection ipsec profile cisco

Verifying Tunnel Interface Configuration
Router# show interfaces tunnel 0
Tunnel4 is up, line protocol is down

Hardware is Routing Tunnel
MTU 1500 bytes, BW 9 Kbit, DLY 500000 usec, rely 255/255, load 1/255
Encapsulation TUNNEL, loopback not set, keepalive set (10 sec)
Tunnel source 0.0.0.0, destination 0.0.0.0
Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled
Last input never, output never, output hang never
Last clearing of show interface counters never
Output queue 0/0, 0 drops; input queue 0/75, 0 drops
Five minute input rate 0 bits/sec, 0 packets/sec
Five minute output rate 0 bits/sec,
Beneficial Notification To NHRP
Server From Spoke Router
The hub router configuration is drastically
shortened and simplified because it does not
need to know any GRE or IPsec information
about the spoke router. It is learned through
NHRP.
Adding a new spoke router to the DMVPN

requires no configuration on the hub. The spoke
is configured with the hub information and
dynamically registers with the hub router.
Dynamic routing protocols distribute information
about the spoke to the hub, which in turn
propagates the information to the other spokes.
Configuring NHRP Server On
Hub
Hub(config)# interface tunnel0
Hub(config-if)# ip nhrp network-id 1
Hub(config-if)# ip nhrp
authentication ADFqeqrDA
Hub(config-if)# ip nhrp map

multicast dynamic
Verifying NHRP Command
Output
Router# show ip nhrp
10.0.0.2/32 via 10.0.0.2, Tunnel0 created

00:17:49, expire 00:01:30
Type: dynamic, Flags: unique registered

used
NBMA address: 172.17.0.2

Group: test-group-0
Verifying DMVPN
Registration
Router# show dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I -
Incomplete
N - NATed, L - Local, X - No Socket #
Ent --> Number of NHRP entries with same
NBMA peer
Tunnel1, Type: Spoke, NBMA Peers: 3,

DMVPN Hub Implementation Guideline
For IKE peering, each hub-to-spoke peering is the

same as a classic IPsec VPN peering. However, if using
dynamic spoke-to-spoke tunnels, these too need to be
authenticated. This necessitates using a scalable
authentication method, such as PKI.
The hub and all spokes must be on the same IP subnet

on the tunnel interface. This is required for the
routing protocols to advertise the DMVPN as a single
IP subnet. This is necessary so that all next-hop
addresses appear to directly connect to the tunnel
interface.
If using redundant interfaces on the hub router, the

DMVPN can be attached to a loopback interface. The
loopback must be included in routing processes in this
case.
Configuring DMVPN Spoke
1. (Optional) Configure an IKE policy. Recall that if one is not created, the hub router
will use default IKE policies.
2. (Optional) Generate/configure spoke authentication credentials. This typically

involves enrolling into a PKI to obtain a certificate for authentication purposes.
3. As with configuring the hub, an IPsec profile with an optional transform set can
be configured. If a transform set is not configured, the router will use default
IPsec transform sets.
4. Create an mGRE tunnel interface (or a GRE interface for strict hub-and-spoke
DMVPNs).
5. Configure NHRP client parameters on the mGRE interface.
6. Associate the IPsec profile with the mGRE interface to configure tunnel
protection.
7. Configure an IP address and IP fragmentation/segmentation parameters on the

mGRE interface.
Configuring NHRP Client On
Spoke
Spoke(config)# interface tunnel0
Spoke(config-if)# ip nhrp network-id 1
Spoke(config-if)# ip nhrp authentication

ADFqeqrDA
Spoke(config-if)# ip nhrp nhs 10.1.1.1
Spoke(config-if)# ip nhrp map multicast

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

Configuring EIGRP Hub Configuration
with Hub And Spoke Topology
router(config)# router eigrp 1
router(config-router)# no auto-summary
router(config-router)# exit
!
router(config)# interface tunnel 0
router(config-if)# no ip split-horizon eigrp

1
Configuring EIGRP Hub Configuration
with Full Mesh Topology
router(config)# router eigrp 1
router(config-router)# no auto-summary
router(config-router)# exit
!
router(config-if)# no ip next-hop-self eigrp
router(config-if)# no ip split-horizon eigrp 1

Configuring OSPF Hub Configuration
with Hub And Spoke Topology
router(config-if)# ip ospf network point-to-

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

Configuring OSPF Hub Configuration
with Full Mesh Topology
router(config-if)# ip ospf network

broadcast
router(config-if)# ip ospf priority

10
NAT-T Works With
IPSec/ISAKMP
1. Detects if both ends support NAT-occurs in
ISAKMP Main Mode messages one and two.
2. If both devices support NAT-T, then NAT-

Discovery is performed in ISKAMP Main Mode
messages (packets) three and four.
3. If a NAT device has been determined to exist, NAT-

T will change the ISAKMP transport with ISAKMP
Main Mode messages five and six, at which point
all ISAKMP packets change from UDP port 500 to
UDP port 4500.
Crypto ACL Primary Function
Select outbound traffic to be protected by IPsec
(permit = protect).
Indicate the data flow to be protected by the new SAs

(specified by a single permit entry) when initiating
negotiations for IPsec security associations.
Process inbound traffic in order to filter out and discard

traffic that should have been protected by IPsec.
Determine whether or not to accept requests for IPsec

security associations on behalf of the requested data
flows when processing IKE negotiation from the IPsec
peer. Negotiation is performed only for ipsec-isakmp
crypto map entries.
Various Parts Used To Setup IPSec
SA
Which traffic should be protected by IPsec (per a crypto ACL)
The granularity of the flow to be protected by a set of SAs
Where IPsec-protected traffic should be sent (the name of the

remote IPsec peer)
The local address to be used for the IPsec traffic
What IPsec SA should be applied to this traffic (selecting from a

list of one or more transform sets)
Whether SAs are manually established or are established via

IKE
Other parameters that might be necessary to define an IPsec

SA
IPSec Recommendation
To minimize the possibility of
packet loss during rekeying, we
recommend using time-based
rather than volume-based IPsec
SA expiration.
If Using manual keying, must

configure SPI to be greater than
4096.
IPSec VPN Source Port Adapter(SPA)
Crypto-connect mode
Traditionally, VPNs are configured on the
IPsec VPN SPA by attaching crypto maps to
interface VLANs and then crypto-
connecting a physical port to the interface
VLAN.
VRF mode
The model of interface VLANs is
preserved, but the crypto connect vlan
command is not used. Instead, a route
must be installed so that packets destined
for that particular subnet in that particular
VRF are directed to that interface VLAN.
Port VLAN And Interface
Outside VLAN Outside
Port Port
Port Port
VLAN Layer 2 VLAN
502 503
Outside Port
IPSec VPN SPA
Inside Port
Interfac Interfac
e VLAN Layer 3 e VLAN
2 3
MSFC/PFC
Access Port Configuration
GigabitEthernet 1 / 2
Wan interface access port
Port VLAN 502

Crypto-connect
VLAN 2
Outside Port
Gi4/0/2
IPSec VPN SPA in slot 4 subslot 1
Inside Port Gi4/0/1
Interface
VLAN 2
192.168.100.2
54
MSFC/PFC
VRF Mode Basic Configuration
Example
ip vrf ivrf
rd 1000:1
route-target export 1000:1
route-target import 1000:1
!
crypto engine mode vrf
!
vlan 2,3
!
crypto keyring key0
pre-shared-key address 11.0.0.2 key 12345
!
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
Example
crypto isakmp profile prof1
vrf ivrf
keyring key0
match identity address 11.0.0.2 255.255.255.255
!
!
crypto ipsec transform-set proposal1 esp-3des esp-sha-hmac
!
crypto map testtag local-address Vlan3
crypto map testtag 10 ipsec-isakmp
set peer 11.0.0.2
set transform-set proposal1
set isakmp-profile prof1
match address 101
!
interface GigabitEthernet1/1
!switch inside port
ip vrf forwarding ivrf
ip address 12.0.0.1 255.255.255.0
Example
interface GigabitEthernet1/2
!switch outside port
switchport
switchport access vlan 3
switchport mode access
!
interface GigabitEthernet4/0/1
!IPsec VPN SPA inside port
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,2,1002-1005
switchport mode trunk
mtu 9216
flowcontrol receive on
flowcontrol send off
Example
interface GigabitEthernet4/0/2
!IPsec VPN SPA outside port
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,1002-1005
switchport mode trunk
mtu 9216
flowcontrol receive on
flowcontrol send off
spanning-tree portfast trunk
!
interface Vlan2
ip vrf forwarding ivrf
ip address 13.0.0.252 255.255.255.0
crypto map testtag
crypto engine slot 4/0 inside
!
interface Vlan3
ip address 11.0.0.1 255.255.255.0
crypto engine slot 4/0 outside
!
access-list 101 permit ip host 12.0.0.2 host 13.0.0.2
Benefits Of IKEv2
Dead Peer Detection and Network
Address Translation-Traversal Built-
in Support.
Certificate URLs can be refrence
through URL and hash.
Denial of Service Attack Resilience.
EAP Support.
Multiple Crypto Engines.
Reliability and State Management
(Windowing).
IKEv2 CLI Construct
IKEv2 Proposal
Encryption algorithm
Integrity algorithm
Pseudo-Random Function (PRF) algorithm
Diffie-Hellman (DH) group
IKEv2 Policy
An IKEv2 policy contains proposals that are used to
negotiate.
IKEv2 Profile
Repository of nonnegotiable parameters of the IKE SA,
such as local or remote identities and authentication
methods and services that are available to
authenticated peers that match the profile.
IKEv2 Key Ring
Repository of symmetric and asymmetric preshared
keys and is independent of the IKEv1 key ring.
Configuring Global IKEv2
Options
crypto ikev2 certificate-cache 750
crypto ikev2 cookie-challenge 450
crypto ikev2 diagnose error 500
crypto ikev2 dpd 500 50 on-demand
crypto ikev2 http-url cert
crypto ikev2 limit max-in-negotiation-sa 5000 incoming
crypto ikev2 nat keepalive 500
crypto ikev2 window 15
crypto logging ikev2
Configuring IKEv2 Fragmentation And
Proposal
crypto ikev2 fragmentation mtu

100
crypto ikev2 proposal proposal1
encryption aes-cbc-128 aes-cbc-
192
integrity sha1
group 14
prf sha256 sha512 (Mandatory if
the encryption type is AES-GCM)
Match Statements On IKEv2 Policies
An IKEv2 policy without any match statements will match all peers in
the global FVRF.
An IKEv2 policy can have only one match FVRF statement.
An IKEv2 policy can have one or more match address local statements.
When a policy is selected, multiple match statements of the same type

are logically ORed and match statements of different types are logically
ANDed.
There is no precedence between match statements of different types.
Configuration of overlapping policies is considered a misconfiguration.

In the case of multiple, possible policy matches, the first policy is
selected.
Configuring IKEv2 Policies
crypto ikev2 policy policy1
proposal proposal1
match fvrf any
match address local 10.0.0.1

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

(ECDSA) configured in the IKEv2 profile.
Secure Hashing Algorithm 2 (SHA-256 and

SHA-384) configured in the IKEv2 proposal
and IPsec transform set.
Basic IPSec VTI Tunnel
IPSec Static VTI
Configuration
Router# configure terminal
Router(config)# interface Tunnel0
Router(config-if)# description VPN tunnel to
branch office
Router(config-if)# ip unnumbered
GigabitEthernet0/0
Router(config-if)# tunnel source
GigabitEthernet0/0 Router(config-if)# tunnel
destination 192.168.2.2 Router(config-if)# tunnel
mode ipsec ipv4
Router(config-if)# tunnel protection ipsec profile
ENC-Profile
Router# copy running-config startup-config
IPSec VTI Benefits
Simplify configuration
Flexible interface feature support

Accepting features that can be applied to physical interfaces
Support for multicast
Better scalability
IPsec VTIs require fewer SAs to support all types of traffic.
Routable interface
Like GRE/IPsec, VTIs support all types of IP routing protocols
IPSec VTI Limitations
The IPsec VTI is limited to only IP
unicast and multicast traffic, while the
GRE/IPsec tunnels support a much
wider range of protocols and
applications.
Cisco IOS Software IPsec stateful

failover is not supported on VTIs,
although other redundancy features,
such as dynamic routing protocols,
can be used as alternative failover
methods.
Static VTI Deployment Steps
Step 1.
Configure Internet Key Exchange (IKE) peering between
VPN endpoints.
Step 2.
Configure an IPsec traffic protection policy on all peers.
Step 3.
Configure a static or dynamic VTI tunnel on each peer.
Step 4.
Configure static or dynamic routing over the VTI tunnels.
Dynamic VTI(DVTI)
Spoke peers attempt to create VPN
connections with the hub peer.
They appear as virtual access interfaces

that are created from information
configured in a virtual template interface
not as a tunnel interface.
The settings in the virtual template

interface include the hub IP address inside
the tunnel (unnumbered), the tunnel mode
(IPsec), and the tunnel protection, and can
optionally include NetFlow accounting or
firewall policy settings.
Virtual Template Configuration
Interface Virtual-template 1
Ip unnumbered FastEthernet0/0
Tunnel mode ipsec ipv4
Tunnel protection ipsec profile Profile1
Ip flow ingress
Zone-member security B2BVPN-Zone

Virtual Access Configuration
Interface Virtual-access 125
Ip unnumbered FastEthernet0/0
Tunnel source 10.1.1.1
Tunnel mode ipsec ipv4
Tunnel destination 10.1.1.2
Tunnel protection ipsec profile
Profile1
No tunnel protection ipsec initiate
Ip flow ingress
Zone-member security B2BVPN-
Zone
FlexVPN Spoke
aaa new-model Configuration
aaa authorization network default local
aaa session-id common
crypto ikev2 keyring Flex_key
peer Spokes
address 0.0.0.0 0.0.0.0
pre-shared-key local cisco
pre-shared-key remote cisco
!!
crypto ikev2 profile Flex_IKEv2
match identity remote address 0.0.0.0
identity local email Client1@cisco.com
authentication remote pre-share
authentication local pre-share
keyring local Flex_key
aaa authorization group psk list default default
virtual-template 1
FlexVPN Spoke
Configuration
crypto logging session
crypto ipsec profile default

set ikev2-profile Flex_IKEv2
interface Tunnel1
ip address negotiated
ip mtu 1400
ip nhrp network-id 2
ip nhrp shortcut virtual-template 1
ip nhrp redirect
tunnel source GigabitEthernet0/0
tunnel destination 172.25.1.1
tunnel path-mtu-discovery
tunnel protection ipsec profile default
FlexVPN Spoke
Configuration
interface Virtual-Template1 type
tunnel
ip unnumbered Tunnel1
ip mtu 1400
ip nhrp shortcut virtual-template 1
ip nhrp redirect
FlexVPN Basic Connectivity Hub
Configuration
aaa new-model
aaa authorization network default local
aaa session-id common

crypto ikev2 authorization policy default
pool FlexSpokes
route set interface
crypto ikev2 keyring Flex_key

peer Spokes
address 0.0.0.0 0.0.0.0
pre-shared-key local cisco
pre-shared-key remote cisco
!!
peer Client1
identity email Client1@cisco.com
pre-shared-key cisco
!!
peer Client2
identity email Client2@cisco.com
Configuration
match fvrf any
match identity remote address 0.0.0.0
match identity remote email domain cisco.com
authentication remote pre-share
authentication local pre-share
keyring local Flex_key
aaa authorization group psk list default default
virtual-template 1
no crypto ikev2 http-url cert
crypto logging session
crypto ipsec profile default

set ikev2-profile Flex_IKEv2
Configuration
interface Virtual-Template1 type tunnel

vrf forwarding IVRF
ip unnumbered Loopback100
ip mtu 1400
ip nhrp redirect
tunnel vrf INTERNET
FlexVPN Extended Connectivity Hub
Configuration
aaa attribute list Client1
attribute type interface-config "ip mtu
1300" protocol ip
attribute type interface-config "service-
policy output TEST" protocol ip
crypto ikev2 authorization policy Client1

pool FlexSpokes
aaa attribute list Client1
route set interface
FlexVPN Extended Connectivity Hub
Configuration
crypto ikev2 name-mangler GET_NAME

email username

aaa authorization group psk list default
name-mangler GET_NAME
FlexVPN Process Overview
FlexVPN Responder
3. IKEv2 Profile authorization statement
Require mangling to be done IKEv2
name
lexVPN Initiator
2. Does this remote identity mangler
Match any of my profile4.? Return a name to be used
By authorization call.
1 . Send Local Identity
IKEv2 Eg: Client@cisco.com IKEv2 profile
Profile match remote
Local identity
5. Perform authorization call as define
Identity aaa authorization network statemen
IKEv2
authorization
6. Return information fro
policy
aaa atribute list
AAA
atribute
Two Major Modes For User Traffic
Encapsulation
Full tunneling VPNs: Require VPN client
software to be installed on the remote
computer or dedicated VPN devices
(hardware clients) to enable full routed IP
access to internal resources. Cisco IOS
Software provides support for SSL VPNs and
IPsec (Easy VPN, or EZVPN) full tunneling
software clients.
Clientless VPN: Access to corporate

resources can be provided to remote users
even when the remote device is not
managed nor is there any VPN client
software.
Full Tunneling Remote Access SSL VPN
Benefits
It supports any IP application without changing the
application. It creates a transparency that creates an
environment in which it is like being inside the protected
network and having access to any corporate resource to
which the user has access.
It does not require any user training except for initiating and
terminating the VPN connection.
It can traverse most firewalls and Network Address

Translation (NAT) devices.
Because it is limited to users having the AnyConnect VPN

client on their machines, mostly used on managed devices
that are typically more trusted than unmanaged devices.
Full Tunneling Remote Access SSL
VPN Limitation
It requires that users install an

SSL VPN client on their systems.
It requires administrative
privileges to install the VPN
client because the client needs
to modify network interfaces and
the IP stack to operate
successfully.
Cisco ISR Web VPN
Technique
URL and Common Internet File System
(CIFS) file access: When the client
browser establishes the SSL session and
the user is authenticated, the gateway
can present a page with resource
bookmarks.
Port forwarding: Provides access to TCP-

based applications by mapping
application-specific ports on the remote
computer to application-specific ports
on the internal servers.
Clientless SSL VPN Benefits
It can traverse most firewalls and NAT
devices because the SSL VPN
encapsulation uses the familiar HTTPS
port (TCP 443) and looks like any other
HTTPS connection.
It does not require that users install a

VPN client on their systems.
It has no need for the user to have

administrative privileges because there
is no software to install.
Clientless SSL VPN
Limitations
It does not support all IP applications,
although most web-based client-server
applications are supported.
It might require user training because the

way users access resources can change
relative to what they are accustomed to
doing.
It can potentially allow access from untrusted

systems because any system with a web
browser can attempt a connection. A layered
security approach should be deployed to
provide additional security controls.
VPN Access Method Use
Cases
SSL/TLS Function
Authenticate the server to the client.
Authenticate the client to the server

(optional).
Select joint cryptographic algorithms.
Generate shared secrets.
Build a protected connection (SSL/TLS

tunnel) to secure TCP and UDP
connections.
Session And Key Management
Phase
Session establishment phase:

When the negotiation of
parameters and peer
authentication takes place.
Data transfer phase: User data is

exchanged securely between
encapsulating endpoints.
Three Subphase Of Session
Establishment
In subphase 1, hello messages are
exchanged to negotiate parameters
including authentication and encryption
algorithms.
In subphase 2, one-way or two-way

authentication between the client and
server is performed. A master key is also
sent by the client using the public key of
the server to start protecting the session.
In subphase 3, the session key is calculated

and the cipher suite is activated
Methods to Create Session
Keys
RSA, where a shared secret is encrypted using
the public key of the other peer.
A fixed Diffie-Hellman (DH) key exchange, which

uses a fixed DH value contained in a certificate.
An ephemeral DH key exchange, which is based

on the actual DH value signed with the private
key of the sender. This provides the best
protection because each session will have a
different set of keys.
An anonymous DH key exchange with no

certificates or signatures. This should be
IKE Built-in Extension
Properties
IKE extended authentication (XAUTH):
XAUTH provides an additional user
authentication step after IPsec peers have
mutually authenticated each other. XAUTH
supports user authentication using static
and one-time passwords.
IKE mode configuration: This allows the

gateway to configure network parameters
on the client. This feature can configure
parameters such as assigning a client a
tunnel IP address and configuring the
client DNS servers, WINS servers, and split
tunneling routes.
SSL VPN Deployment Steps
1. Configure the ISR with basic SSL VPN gateway features to include
provisioning a certificate to enable SSL/TLS server authentication.
2. Configure basic user authentication by adding user accounts with

passwords and creating an access policy for all remote users.
3. (Optional) Configure full tunneling VPN access to internal

resources if the connection requires access that is like being
connected to the internal network directly.
4. (Optional) Deploy the Cisco AnyConnect VPN client if full

tunneling is required.
5. (Optional) Configure clientless VPN access to internal resources if

the connection only requires browser-based access.
Enable SSL VPN Gateway
router(config)# webvpn gateway MY-GATEWAY
router (config-webvpn-gateway)#? ip address

172.16.1.1 port 443
router (config-webvpn-gateway)# ssl trustpoint

MY-TRUSTPOINT
router (config-webvpn-gateway)# logging

enable
router (config-webvpn-gateway)# inservice

Configure Gateway High Availability
router (config)# interface GigabitEthernet0/0
router (config-if)# standby 1 ip 172.16.1.1
router (config-if)# standby 1 name SSLVPN-

HSRP
router (config)# webvpn gateway MY-GATEWAY
router (config-webvpn-gateway)# ip address

172.16.1.1 port 443 standby SSLVPN-HSRP
Gateway Verification
router# show webvpn gateway
Gateway Name Admin

Operation
------------ -----
--------
MY-GATEWAY up up
Configuring SSL VPN
Context
router(config)# webvpn context MY-
CONTEXT
router(config-webvpn-context)# policy
group MY-POLICY
router(config-webvpn-context)# banner
Welcome to SSL VPN
router(config-webvpn-context)# default-
group-policy MY-POLICY
Enable User Authentication Using
Local AAA
router(config)# aaa authentication login
LOCAL-AUTHEN local
router(config)# username vpnuser privilege

0 secret 5
$25$05ikadSDAjaksfdjDw32PDij34214$4213

CONTEXT
router(config-webvpn-context)# aaa
authentication list LOCAL-AUTHEN
Full Tunneling Scenario
Enable Full Tunneling Access
router(config)# webvpn install svc
flash://anyconnect-win-2.4.0202-k9.bin
SSLVPN Package SSL-VPN-Client (seq:1): installed
successfully
router(config)# webvpn context MY-CONTEXT
router(config-webvpn-context)# policy group MY-

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

Configure Local IP Address
Assignment
router(config)# ip local pool MY-POOL
192.168.1.2 192.168.1.150

CONTEXT
router(config-webvpn-context)#policy
group MY-POLICY
router(config-vpn-policy)#svc address-
pool MY-POOL
Configure Client
Configuration
Router(config)# webvpn context MY-
CONTEXT
Router(config-webvpn-context)# policy
group MY-POLICY
Router(config-vpn-policy)# svc default-

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

primary 10.1.1.1
Configuring Split Tunneling
Router(config)# webvpn context MY-CONTEXT
Router(config-webvpn-context)# policy group

MY-POLICY
Router(config-vpn-policy)# svc split dns

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

10.0.0.0 255.0.0.0
Configuring Access Control
Router(config)# ip access-list extended MY-ACL
Router(config-ext-acl)# permit udp any host 10.1.1.1

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

eq www
Router(config)# webvpn context MY-CONTEXT
Router(config-webvpn-context)# policy group MY-

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

Gateway, Context And
WebVPN Gateway
Policy Group
Ip Address And WebVPN Content
Port Portal
SSL PKI Customization
Trustpoint SSL Certificate
HTTP Redirect Authentication
Port(Optional) SSL Policy(Optional)
Hostname(Optio TCP Policy(Optional)
nal) URL Lists
TCP NBNS Lists
Policy(Optional) Port Forwarding Policy Group
SSL Lists Functions
Policy(Optional) Policy Groups SVC
Default Policy Group Configuratio
WebVPN Gateway n
Gateway Timeout
Domain(Optional) values
AAA Authentication URL Lists
method NBNS Lists
AAA Authentication Port Forward
domain Lists

Verifying Operation On The SSL VPN
Gateway
Router# show webvpn session

context SSL VPN
WebVPN context name: SSL VPN

Gateway
Router# show webvpn session user user1 context all
WebVPN user name = user1 ; IP address = 10.2.1.220;

context = SSL VPN
No of connections: 0
Created 00:00:19, Last-used 00:00:18
CSD enabled
CSD Session Policy
CSD Web Browsing Allowed
CSD Port Forwarding Allowed
CSD Full Tunneling Disabled
CSD FILE Access Allowed
User Policy Parameters
Group name = ONE
Gateway
Group Policy Parameters
url list name = Cisco
idle timeout = 2100 sec
session timeout = 43200 sec
port forward name = EMAIL
tunnel mode = disabled
citrix disabled
dpd client timeout = 300 sec
dpd gateway timeout = 300 sec
keep stc installed = disabled
rekey interval = 3600 sec
rekey method = ssl
lease duration = 3600 sec
Port Forwarding Process
1. After logging in to the SSL VPN portal, the Java applet that is
downloaded from the SSL VPN portal dynamically modifies the
local hosts file. The Java applet then listens on the remote
hosts loopback address at port 3001 and forwards any
incoming connections over the SSL VPN session.
2. The user opens a Telnet client and attempts to connect to an

internal server on port 3001.
3. The local hosts file will be analyzed by the applet. It has an

entry for the internal server that points to the loopback address
(127.0.0.1) of the remote client. The Telnet client connects to
the local host on port 3001, and the Java applet forwards this
connection to the SSL VPN gateway through the tunnel.
4. The gateway extracts the TCP session from the SSL VPN session,
establishes a TCP connection with the internal target host on
the standard Telnet port, and acts as a data relay between the
two TCP sessions.
Port Forwarding Limitations
Port forwarding supports only simple,
static-port TCP applications.
Port forwarding requires preinstalled

native applications on the remote systems.
Users must change application settings

such as the destination port of the server.
Port forwarding requires administrative

privileges because it changes the local
hosts file.
Configuring SSL VPN Portal
router(config-webvpn-context)# url-list MY-WEB-BOOKMARKS
router(config-webvpn-url)# url-text Internal Web Server url-
value http://intranet.mydomain.com
router(config-webvpn-url)# exit
router(config-webvpn-context)# cifs-url-list MY-CIFS-
BOOKMARKS
url-text Internal File Server url-value cifs://w2k3s/share
router(config-webvpn-context)# nbns-list MY-AD-NAMESERVERS
router(config-webvpn-context)# nbns-server 10.10.1.1
!
router(config-webvpn-context)# policy-group MY-POLICY
router(config-webvpn-group)# url-list MY-WEB-BOOKMARKS
router(config-webvpn-group)# cifs-url-list MY-CIFS-BOOKMARKS
router(config-webvpn-group)# nbns-list MY-AD-NAMESERVERS
router(config-webvpn-group)# functions file-access
router(config-webvpn-group)# functions file-browse
router(config-webvpn-group)# functions file-entry
Configuring Optional Port
Forwarding
router(config-webvpn-context)# port-forward MY-PORT-

FORWRD
router(config-webvpn-port-fwd)# local-port 3001

remote-server 10.10.1.1 remoteport 3389 description
Terminal Services
router(config-webvpn-port-fwd)# exit
router(config-webvpn-group)# port-forward MY-PORT-

FORWRD auto-download
Configuring Optional Cisco Secure
Desktop
Router(config)# webvpn install csd

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

CONTEXT
Router(config-context)#csd enable
Configure Optional Access
Control
router(config-webvpn-context)# acl MY-PORTAL-ACL
router(config-webvpn-acl)# permit url

http://intranet.mydomain.com
router(config-webvpn-acl)# permit url cifs://w2k3s/share
router(config-webvpn-acl)# permit tcp any 10.10.1.1

255.255.255.255
router(config-webvpn-acl)# exit

Remote Access FlexVPN
Radius For Authentication Only And
Local Authorization
aaa new-model
aaa group server radius FlexVPN-AuthC-

Server-Group-1 server-private 10.7.7.129
key Cisco123
aaa authentication login FlexVPN-AuthC-

List-1 group FlexVPN-AuthC-Server-Group-1
aaa authorization network FlexVPN-AuthZ-

List-1 local
Configuring Local Authorization
Policy
ip local pool FlexVPN-Pool-1 10.8.8.100 10.8.8.200
crypto ikev2 authorization policy FlexVPN-Local-

Policy-1
pool FlexVPN-Pool-1
dns 10.7.7.129
netmask 255.255.255.0
def-domain example.com
Server Using Certificate To
Authenticate Itself
crypto pki trustpoint FlexVPN-TP-1

enrollment url
serial-number none
fqdn flex-hub.example.com
ip-address none
subject-name cn=flex-
hub.example.com
revocation-check crl
rsakeypair FlexVPN-TP-1-Key
Configuring Setting For
Connection
crypto ikev2 profile FlexVPN-IKEv2-Profile-
1
match identity remote key-id
example.com
identity local dn
authentication remote eap query-
identity
authentication local rsa-sig
pki trustpoint FlexVPN-TP-1
dpd 60 2 on-demand
aaa authentication eap FlexVPN-AuthC-
List-1
Configuring IPSec Profile Links to
IKEv2 Profile
crypto ipsec profile FlexVPN-IPsec-

Profile-1
set ikev2-profile FlexVPN-IKEv2-
Profile-1
Configuring Virtual Template
interface Virtual-Template10 type

tunnel
ip unnumbered GigabitEthernet0/0
tunnel mode ipsec ipv4
tunnel protection ipsec profile
FlexVPN-IPsec-Profile-1
Optional Negotiation For
SHA-1
crypto ikev2 proposal SHA1-only
encryption aes-cbc-256
integrity sha1
group 5
crypto ikev2 policy SHA1-only
match fvrf any
proposal SHA1-only
IPSec Common Problems
IKE SA not established
IPSec SAs not established
MTU/Fragmentation Issues
No IKE SA Troubleshooting
Step
Check for Routing.
Check for IKE SA using show and

debug.
Check for IKE Policies.

Debug Crypto ISAKMP
Example
ISAKMP:(0):Checking ISAKMP transform 1 against
priority 10 policy
ISAKMP: encryption 3DES-CBC
ISAKMP: hash SHA
ISAKMP: default group 2
ISAKMP: auth pre-share
ISAKMP: life type in seconds
ISAKMP: life duration (basic) of 7200
ISAKMP:(0):Encryption algorithm offered does not
match policy!
ISAKMP:(0):atts are not acceptable. Next payload is 0
Debug Crypto ISAKMP
Example
ISAKMP:(0):Checking ISAKMP transform 1 against priority 65535
policy
ISAKMP: encryption 3DES-CBC
ISAKMP: hash SHA
ISAKMP: default group 2
ISAKMP: auth pre-share
ISAKMP: life type in seconds
ISAKMP: life duration (basic) of 7200
ISAKMP:(0):Encryption algorithm offered does not match policy!
ISAKMP:(0):atts are not acceptable. Next payload is 0
ISAKMP:(0):no offers accepted!

ISAKMP:(0): phase 1 SA policy not acceptable! (local 30.3.1.1
remote 40.10.1.1)
No IPSec SA Troubleshooting
Steps
Check for IPSEC SA (look for
inbound and outbound SPIs).
Use IPSec Debugs to

troubleshoot.
Check the IPSec Transform Sets.
Check the Crypto ACLs.

Show Crypto IPSec SA
interface: GigabitEthernet0/1
Crypto map tag: CMAP, local addr 30.3.1.1
protected vrf: (none)
local ident (addr/mask/prot/port): (3.1.1.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (4.1.1.0/255.255.255.0/0/0)
current_peer 40.10.1.1 port 500
PERMIT, flags={origin_is_acl,}
local crypto endpt.: 30.3.1.1, remote crypto endpt.: 40.10.1.1

path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/1
current outbound spi: 0x0(0)
inbound esp sas:

inbound ah sas:
outbound esp sas:

outbound ah sas:
Debug Crypto IPSec
ISAKMP (0:1022): received packet from 40.10.1.1 dport 500
sport 500 Global (R) QM_IDLE
ISAKMP:(1022): processing SA payload. message ID =

-549695704
ISAKMP:(1022):Checking IPSec proposal 1
ISAKMP: transform 1, ESP_3DES
ISAKMP: attributes in transform:
ISAKMP: encaps is 1 (Tunnel)
ISAKMP: SA life type in seconds
ISAKMP: SA life duration (basic) of 1800
ISAKMP: SA life type in kilobytes
ISAKMP: SA life duration (VPI) of 0x0 0x46 0x50 0x0
ISAKMP: authenticator is HMAC-SHA
ISAKMP:(1022):atts are acceptable.
Debug Crypto IPSec
IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) INBOUND local= 30.3.1.1, remote= 40.10.1.1,
local_proxy= 3.1.1.0/255.255.255.0/0/0 (type=4),
remote_proxy= 4.1.1.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= NONE (Tunnel),
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x0
Crypto mapdb : proxy_match
src addr : 3.1.1.0
dst addr : 4.1.1.0
protocol : 0
src port : 0
dst port : 0
IPSEC(ipsec_process_proposal): transform proposal not supported for
identity:
{esp-3des esp-sha-hmac }
ISAKMP:(1022): IPSec policy invalidated proposal with error 256
ISAKMP:(1022): phase 2 SA policy not acceptable! (local 30.3.1.1 remote
IPSec SA Showing Anti Reply
interface: GigabitEthernet0/1 Drops
Crypto map tag: CMAP, local addr 30.3.1.1
protected vrf: (none)

current_peer 40.10.1.1 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 2900, #pkts encrypt: 2900, #pkts digest: 2900
#pkts decaps: 1909, #pkts decrypt: 1909, #pkts verify: 1909
#pkts compressed: 0, #pkts decompressed: 0
#pkts encaps failed (send) 0, #pkts decaps failed (rcv) 0
#pkts invalid prot (recv) 0, #pkts verify failed: 0
#pkts invalid identity (recv) 0, #pkts invalid len (rcv) 0
#pkts replay rollover (send): 0, #pkts replay rollover (rcv) 0
#pkts replay failed (rcv): 1000
#pkts internal err (send): 0, #pkts internal err (recv) 0
IPSec SA Showing Anti Reply
Drops
local crypto endpt.: 30.3.1.1, remote crypto endpt.: 40.10.1.1
path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/1
current outbound spi: 0xC37422AA(3279168170)
inbound esp sas:

spi: 0x135E76B1(324957873)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 41, flow_id: SW:41, crypto map: CMAP
sa timing: remaining key lifetime (k/sec): (4419198/860)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE
Verifying DMVPN Common
Issue
Verify the basic connectivity.
Verify for incompatible ISAKMP policy.
Theshow crypto isakmp sa command shows the
ISAKMP SA to be inMM_NO_STATE, meaning the
main-mode failed.
Verify for incorrect pre-shared key secret.
The router returns the"sanity check
failed"message.
Verify for incompatible IPsec transform set.
The router returns the"atts not
acceptable"message for the IPsec proposal.
Common Problem On
DMVPN
VPN Tunnel Flapping.
NHRP Registration Failing.
ISAKMP/IPSec bouncing up and down.
Traffic flow only in one direction.
Spokes are unable to establish routing

protocol neighbor relationship.
VPN Tunnel Flapping
Router#show crypto isakmp sa
IPv4 Crypto ISAKMP SA

NHRP Registration Failing
Router#show crypto IPSEC sa

#pkts encaps: 154, #pkts encrypt: 154, #pkts digest: 154
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
inbound esp sas:

spi: 0xF830FC95(4163959957)
outbound esp sas:

spi: 0xD65A7865(3596253285)
NHRP Registration Failing
Router#show ip nhrp nhs detail
Legend: E=Expecting replies, R=Responding

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

Registration Request: Reqid 4371, Ret 64 NHS 172.17.0.1
Hub And Spoke IPSec VPN
Design
FlexVPN Dual Hub Design
Dual DMVPN Cloud Topology
Single Tier HeadEnd
Architechture
Dual Tier HeadEnd
Architechture
DTLS On ASA
Allows the AnyConnect client establishing an SSL
VPN connection to use two simultaneous tunnels
an SSL tunnel and a DTLS tunnel.
DTLS (Datagram Transport Layer Security) avoids

latency and bandwidth problems associated with
SSL connections and improves the performance of
real-time applications that are sensitive to packet
delays.
By default, DTLS is enabled when SSL VPN access is

enabled on an interface.
In order for DTLS to fall back to a TLS connection,

Dead Peer Detection (DPD) must be enabled.
Cisco Evolution Of
Cryptography
Encryption
Digital Hashin
Key Exchange
Signature g
Cisco Encryption Short RSA
MD5 Diffie-Hellman
Technology Keys
Elliptic Curve
Diffie-Hellman
IPSec: 56 bit Digital 2048 bit
SHA-1 (Using P-256
Encryption Standard (DES) RSA Keys
and P-384
curves)
Elliptic
Curve
SHA-
168-bit Triple DES (3DES) Digital
256
Signature
Algorithm
128-bit AES SHA-

CCNP Security (Simos)

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

CCNP Security (Simos)

Hochgeladen von

Copyright:

Verfügbare Formate

CCNP Security

Email and file encryption system

Uses a concept call trusted

They can encrypt the message with

2. User C can then verify the signature of user B (because it

3. User B digitally signs the public key of user C (which it

4. User A can then verify the signature of user B (because it

Used with Multiprotocol Label Switching

Ideal cryptographic solution for MPLS

Uses the concept of trusted group

Performs admission control to the GET

Creates and supplies group

Distribute keys and policies to all

All communication between a

TEK: A key that is used to protect

KEK: A key this is used to protect

The group member encrypts the multicast

The replication of the multicast packet is

Packet integrity and authenticity using

Cisco-proprietary time-based (instead of

GDOI IKE SAs do not need to linger

GDOI IKE sessions do not get established

If most of the group members

Very scalable in that the

Provides scalable support for

The compromise of one peer has a larger effect

Key servers must be available during rekeys

The skey is derived from the Diffie-Hellman

That pre-shared key needs to be

Crypto Map Seq_No_2

Both LAN-to-LAN and remote access peers can use

Peers with dynamically assigned private IP

Peers requesting remote access tunnels typically

Automatic IPsec initiation:

Support for spoke routers configured with dynamic

NHRP: The NHRP database maintains mappings

IPsec: Provides transmission protection for GRE

The infrastructure addressing space, which

The hub knows the outer and inner IP

Three spoke-to-hub GRE/IPsec tunnels

Any traffic from a spoke (whether to a

4. The NHRP server, which maintains inner

1. Dynamic routing (already configured

2. R2 consults its routing table for a

6. After the IPsec tunnel is created, R2 will

8. For two-way traffic, R4 needs next-

It can be more complex to

Cryptographic standards and security

Use dynamic routing protocols to

DMVPN is a suitable technology for

A carrier protocol (GRE in this

A transport protocol (IP only in

There is no standard way to determine the end-to-

It can be CPU intensive on some platforms.

Tunnels can sometimes cause maximum

There is a separate GRE tunnel interface

They do not require NHRP because other

They provide support for unicast, multicast,

Spoke(config-if)# tunnel mode gre ip

Spoke(config-if)# tunnel source 172.17.2.4

Spoke(config-if)# tunnel destination 172.17.0.1

Spoke(config-if)# ip address 10.1.1.2

2. (Optional) Generate/configure spoke authentication credentials. This