VPN Part 2

Crypto Map Based IPSEC Overview:

"Legacy " Method of IOS IPSEC Configuration
-- Still the most common method though

> Used to form on-demand IPSEC Tunnels
-- Session initiated only when interesting traffic detect

>  No dynamic routing support through tunnel
-- Not without additional encapsulation such GRE

How Crypto Maps Work

> Crypto map is a data-plane filter
-- Matching traffic triggers an ISAKMP session to start
> Traffic is matched using ACLs
-- ACLs define proxy IDs for IPSEC Phase 2 , e.g what should be encrypted

> Allows for granular control over VPN
-- e.g only send TCP port 12345 over the VPN

 Applying Crypto Maps

> Crypto maps apply to physical (sub) interfaces
-- Only one crypto map per interface
-- always outbound with respect to traffic direction

One crypto map can apply to multiple interfaces

-- Entries processed top-down until ACL match occurs , order is important

Tunnel source defaults to interface IP
-- can be changed using crypto map local-address

Crypto Maps order of operations
-- Encryption applies after routing
   o static routing may be required

-- Encryption applies after NAT
NAT exemption may be required

-- Rule of thumb is that crypto , routing & NAT process are always independent of each
    other



High Level Configuration steps

Define phase 1 ISAKMP policy
Define phase 2 IPSEC policy
Apply crypto map
o Generating interesting traffic

 Defining Phase 1 ISAKMP Policy

> Peers must agree of four main attributes
   o Authentication o Encryption o Hash o DH Group o Lifetime (Lower value is negotiated)

> Policy is processed top-down until a match occurs by the responder
   o Based on policy priority
   o Lower priority value has higher precedence
   o order is important

> Defining phase 2 IPSEC Policy
> IPSEC policy defines 3 main attributes
who ? define peer adds, hostname , or FQDN
what ? define proxy ACL
How ? Define transform set

 Configuration Verification 
> show crypto isakmp [default ] policy
-- verify custom or default phase 1 policies
> show crypto isakmp key
-- verify pre-shared keys
> show crypto ipsec transform-set <name>
-- Verify custom or default phase 2 policies
> show crypto debug-condition
-- verify conditions / filters for debugging
> show crypto map interface <intf>
-- verify crypto-map configuration

Advanced Verification

> show crypto isakmp sa
-- show the result of phase 1 negotiations
> debug crypto isakmp
-- show the step-by-step phase 1 negotiation
> show crypto ipsec sa
-- show the result of phase 2 negotiation
> debug crypto ipsec
-- show the step by step phase 2 negotiation

refer link:
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_vpnips/configuration/xe-3s/sec-sec-for-vpns-w-ipsec-xe-3s-book/sec-ipsec-virt-tunnl.html

 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

IPSEC Verification & Troubleshooting: 
Phase 1 Verification & Troubleshooting 
o Show crypto isakmp sa [detail]
o Debug crypto isakmp 
-- state should be "QM-IDLE" and state "ACTIVE"
o debug crypto isakmp
 (shows negotiation process)
o debug crypto condition peer IPv4 <ip>
-- Restricts debugging output to relevant peer 

## is authentication working ? 
o check PSK/CA
o Failure means corrupted packets

## Do IKE v1 SA attributes match ? 
o debug will show failure to negotiate attributes

## Result will be one bidirectional ISAKMP SA 

                 Phase 2 Verification & Troubleshooting 

## Phase 1 ISAKMP IKE v1 "ACTIVE"   first 
## show crypto ipsec sa [Peer <ip> ]
o Are packets getting .....
  o en/decrypted ...
  o en / decapsulation ...
  o check both sides

## debug crypto ipsec
  o shows negotiation of ipsec SA's

o did transform sets match ?
o Are ACLs mirror images ?
o Result should be two SA's per ACL entry
(inbound & outbound )

o Unidirectional pkt conters usually mean a data plane, problem is the transit path.

++ i.e someone is filtering ESP
## clear crypto isakmp -----   delete phase 1
## clear crypto ipsec sa ----  delete phase 2


+++++++++++  Next is labe +++++++++++++