VPN Configuration

IPSEC VPN CONFIGURATION
Virtual Private Network (VPN)  and IPsec

• Extension of a private network over a public network and VPN doesn't necessarily imply encryption. For security reason, apply IPsec securtiy framework to VPN tunnel.. IPsec is a standards based security framework. IPSec offers four frames 
• Data origin authentication
• Data integrity
• Data Confidentiality 
• Anti-replay
• Main goal for IPSec VPN is to encrypt and authenticate IPv4 or IPv6 packets over public network. 

• Goal of IPSec exchange is to establish phases using IKE
• Occurs through the main negotiation phases using IKE
• IPSec Phase 1
• Authenticate endpints and build a secure tunnel for further negotiation
• ISAKMP SA
• IPSec Phase 2
• Establish the tunnel used to protect the actual data traffic
• IPSEC SA 
• Negotiating Phase 1 ( ISAKMP SA)
• Authentication method ( authentication pre-share/rsa-encr/rsa-sig)
• Encryption type ( 3des/aes/des) 
• group ( 1/14/15/16..)
• lifetime (60-86400)
• Negotiating Phase 2 ( IPSEC SA)
• set peer ( xx.xx.xx)
• set transform-set xxx
• set address xx
• Applying the Crypto Map
• Crypto Map applies to the link level

EXAMPLE VPN NETWORK DESIGN

 

R3 CONFIGURATION

 

R2 CONFIGURATION

  

R2's VPN CONNECTION VERIFICATION

  

USEFUL CONFIGURATION VERIFICATION COMMANDS

Router # show crypto isakmp [default] policy

Router # show crypto ipsec sa

Router # show crypto isakmp sa

Router # show crypto ipsec transform-set <name>

Router # show crypto debug-condition

USEFUL DEBUGGING COMMANDS FOR TROUBLESHOOTING

Router # debug crypto isakmp

Router # debug crypto ipsec

REFERENCE

• INE_CCIE_VPN_CONFIGURATION 
• CISCO_VPN_CONFIGURATION_DOC 
• PACKETLIFE_VPN_CONFIGURATION_EXAMPLE 
• CBTNUGGETS_CCIE_VPN_CONFIGURATION 

DMVPN- Details Analysis

DMVPN - Phase1,2, and 3

• NBMA networks and all traffic broadcast and uni-cast must be sent across the network as uni-cast packets.
• This simply means multicast traffic destined for an IGP neighbor will always be encapsulated in a uni-cast packet for delivery
• Hub router always knows the identities of all the spokes for which it is the next-hop server (NHS)
• ip nhrp map multicast dynamic command on the hub is used to dynamically create mappings in the NHRP multicast table for each spoke that registers with it
• Spoke routers create a static multicast mapping for hub 
•  ip nhrp map multicast [ nbma address of hub] 
•  ip nhrp nhs [overlay address] [underlay address] multicast

PHASE I

• Only provides hub-spoke tunnel deployment. This means GRE tunnels are only build between the hub and spokes
• Traffic destined to networks behind spokes is forced to first traverse the hub.
• Restricts it form building dynamic spoke-to-spoke tunnels. Because all spoke-to-spoke traffic in DMVPN phase 1 always traverses the hub.
• Flood a default summary route to the spokes for all traffic. This is achieved in EIGRP using the ip summary-address eigrp [asn] 0.0.0.0 0.0.0.0 command under the tunnel interface

PHASE1- Configuration
Hub 
Router(config)# interface tunnel 0
Router(config-if) # ip address 172.16.1.1 255.255.255.0
Router (config-if) # no ip redirect
Router (config-if) # ip nhrp authentication cisco
Router (config-if) # ip nhrp multicast dynamic
Router (config-if) # ip nhrp network-id 1
Router (config-if) # ip summary-address eigrp 1 0.0.0.0 0.0.0.0
Router (config-if) # tunnel source G0/1
Router (config-if) # tunnnel mode gre multipoint

Spoke
Router (config) # interface tunnel 0
Router (config-if) # ip address 172.16.1.2 255.255.255.0
Router (config-if) # no ip redirect
Router (config-if) # ip nhrp authentication cisco
Router (config-if) # ip nhrp map 172.16.1.1 192.168.1.1
Router (config-if) # ip nhrp map multicast 192.168.1.1
Router (config-if) # ip nhrp network-id 1
Router (config-if) # ip nhrp nhs 172.16.1.1
Router (config-if) # tunnel source 192.168.1.2
Router (config-if) # tunnel destination 192.168.1.1

PHASE 2

• Traffic between the spokes would always hit the hub.
• The hub burdened with encapsulate/decapsulate overhead for the spoke-to-spoke traffic
• Phase 2 improved on phase 1 by allowing spokes to build a spoke-to-spoke tunnel on demand with these restrictions
• Spoke must use multipoint GRE tunnels
• The spokes must receive specific routes for all remote spoke subnets
• The next hop of the entry in the routing table must list the remote spoke as the next hop

CONFIGURATION

• Need to configure mGRE on the spokes allows multiple GRE tunnels to be formed using a single tunnel interface ( tunnel mode gre multipoint)

•     Spokes must receive specific routes for all remote spoke subnets. For EIGRP, this is accomplished by disabling split horizon on the tunnel interface

• The hub uses its tunnel 0 interface to reach the networks behind the spokes. Split horizon will prevent the hub from advertising those networks to remote spokes.
• no ip split-horizon eigrp command

• After the NHRP resolution is complete, traffic will not pass through Hub anymore.
• Because the next hop for each prefix must be preserved. In Phase 2, it is not possible to summarize from the hub to the spokes

PHASE2- Configuration
Hub 
Router(config)# interface tunnel 0
Router(config-if) # ip address 172.16.1.1 255.255.255.0
Router (config-if) # no ip redirect
Router (config-if) # ip nhrp authentication cisco
Router (config-if) # ip nhrp multicast dynamic
Router (config-if) # ip nhrp network-id 1
Router (config-if) # no ip next-hop-self eigrp 1
Router (config-if) # no ip split-horion eigrp 1
Router (config-if) # tunnel source G0/1
Router (config-if) # tunnnel mode gre multipoint

Spoke
Router (config) # interface tunnel 0
Router (config-if) # ip address 172.16.1.2 255.255.255.0
Router (config-if) # no ip redirect
Router (config-if) # ip nhrp authentication cisco
Router (config-if) # ip nhrp map 172.16.1.1 192.168.1.1
Router (config-if) # ip nhrp map multicast 192.168.1.1
Router (config-if) # ip nhrp network-id 1
Router (config-if) # ip nhrp nhs 172.16.1.1
Router (config-if) # tunnel source 192.168.1.2
Router (config-if) # tunnel mode gre multipoint

PHASE 3

• Spokes register their Tunnel/NBMA mappings with the hub (or hubs). This allows the hub to dynamically discover all spokes and establish routing adjacency and routing information exchanged.
• In fact, the hub is not required to preserve the reachability information and also summarize information to send to all spokes

• Use NHRP traffic indication messages from the hub to signal to the spokes that a better path exists to reach the target network
• " ip nhrp redirect" on the hub and " ip nhrp shortcut"
• This command provides the hub to the send the NHRP traffic indication message while the shortcut command tells the spokes to accept the redirect and install the shortcut route

PHASE 3 CONFIGURATION
HUB 

Router(config)# interface tunnel 0
Router(config-if) # ip address 172.16.1.1 255.255.255.0
Router (config-if) # no ip redirect
Router (config-if) # ip nhrp authentication cisco
Router (config-if) # ip nhrp multicast dynamic
Router (config-if) # ip nhrp network-id 1
Router (config-if) # ip nhrp redirect
Router (config-if) # ip summary-address eigrp 1 0.0.0.0 0.0.0.0
Router (config-if) # tunnel source G0/1
Router (config-if) # tunnnel mode gre multipoint

SPOKE
Router (config) # interface tunnel 0
Router (config-if) # ip address 172.16.1.2 255.255.255.0
Router (config-if) # no ip redirect
Router (config-if) # ip nhrp authentication cisco
Router (config-if) # ip nhrp map 172.16.1.1 192.168.1.1
Router (config-if) # ip nhrp map multicast 192.168.1.1
Router (config-if) # ip nhrp network-id 1
Router (config-if) # ip nhrp shortcut
Router (config-if) # ip nhrp nhs 172.16.1.1
Router (config-if) # tunnel source 192.168.1.2
Router (config-if) # tunnel mode gre multipoint
 
REFERENCE

1. INE_BLOG_DMVPN_EXPLAIN
2. INE_DMVPN_VIDEO
3. CISCO_DMVPN_CONFIGURATION_DOC

DMVPN Phases

DMPVN Phases

• DMVPN Phase 1
• mGRE on hub and p-pGRE on spokes
• NHRP still required for spoke registration to hub
• No spoke-to-spoke tunnels
• Routing
• summarization/default routing at hub is allowed
• Next-hop on spokes is always changed by the hub
• DMVPN Phase 2
•  mGRE on hub and spokes
• NHRP required for spoke registration to hub
• NHRP required for spoke-to-spoke resolution
• Spoke-to-spoke tunnel triggered by spoke
• Routing
• Summarization/default routing at hub is NOT allowed
• Next-hop on spokes is always preserved by the hub
• Multi-level hierarchy requires hub daisy-chaining
• DMVPN Phase 3
• mGRE on hub and spokes
• NHRP required for spoke registration to hub
• NHRP required for spoke-to-spoke resolution
• When a hub receives and forwards packet out of same interface
• Send NHRP redirect message back to packet source
• Forward origin packet down to spoke via RIB 
• Routing
• Summarization/default routing at hub is allowed
• Results in NHRP routes for spoke-to-spoke tunnel
• With no-summary, NHO is performed for spoke-to-spoke tunnel
• Next-hop is changed from hub IP to spoke IP
• Next-hop on spokes is always changed by the hub
• Because of this, NHRP resolution is triggered by hub
• Multi-level hierarchy works without daisy-chaining
 
Reference
DMVPN_CONFIGURATION_CISCO_DOC 
DMVPN_INE_DMVPN_REVIEW 
 
 
 
 

NSSA Translator Election & Forwarding Address

OSPF NSSA Translator Election & Forwarding Address 

• RFC 3101
• With OSPF NSSA, Type 7 NSSA External LSAs are translated to Type-5 External LSAs by the ABR connecting the NSA to Area 0.
• When multiple ABRs connect the NSSA to area 0, the ABR with the highest router-id is elected as the Type7 to Type 5 translator.

CONFIGURATION

• - Before changing anything, R5 has two ABRs routers which are R1 and R2 translated to Type 7 to Type 5,
• Translator selection is based on router-id. In this network design, R2's router-id is higher than Rotuer 1. In fact, R2 elected as Type 7 to Type 5 translator.

Dynamic Multipoint VPN

Dynamic Multipoint VPN

• Point to Multi-point Layer 3 overLay VPN
• Logical hub and spoke topology
• Direct spoke to spoke traffic is supported
• DMVPN uses a combination of 
• Multipoint GRE tunnels (mGRE)
• Next Hop Resolution Protocol (NHRP)
• IPSec Crypto Profiles

Why DMVPN?

• Independent of SP access method
• Only requirement is IP connectivity
• Routing policy is not dicitated by SP
• MPLS L3 VPN restrictions (E.g)
• Highly scalable
• If properly designed

DMVPN allows on-demand full mesh IPSec tunnels with minimal configuration such as

• mGRE(Multipoint GRE Tunnnels)
• Next Hop Resolution Protocol (NHRP)
• IPsec Crypto Profiles
• Routing

Creates on-demand tunnels between nodes

• initial tunnel-mesh is hub-and-spoke (always on)
• Traffic patterns trigger spoke to spoke tunnels
• Solves management scalability problem 

Maintain tunnels based on traffic patterns  

• Spoke-to spoke tunnel is on-demand
• Spoke-to spoke tunnel lifetime is based on traffic

Requires two IGPs: Underlying and Overlay

• IPv4/IPv6 supported for both passenger and transport

 How DMVPN Works ( Hub to Spoke)

• Two main components
• DMVPN Hub/NHRP Server (NHS)
• DMVPN Spokes /NHRP Clients (NHC)

Spokes/Clients register with Hub/Server

• Spokes manually specify Hub's address
• Sent via NHRP registeration request
• Hub dynamically learns Spokes' VPN address & NBMA address

Spokes establish tunnels to Hub

• Exchange IGP routing information over the tunnel

 Spoke to Spoke ( routes via IGP)

• Learns via tunnel to Hub
• Next-hop is spoke2's VPN IP for DMVPN phase 2
• Next-hop is Hub's VPN IP for DMVPN phase 3 

Spoke1 ask Spoke2's real address

• Maps next-hop (VPN) Ip to tunnel source (NBMA) IP
• Send via NHRP resolution request

Spoke to Spoke tunnel is formed

• Hub only used for control plane exchange
• Spoke-to-spoke data plane may flow through hub initially

NHRP Important Messages

• NHRP Registration Request
• Spoke register their NBMA and VPN IP to NHS
• Required to build the spoke to hub tunnels
• NHRP Resolution Request
• Spoke queries for the NBMA-to-VPN mappings of other spokes
• Required to build spoke-to-spoke tunnels
•  NHRP Redirect
• NHS answer to a spoke-to-spoke data-plane packet through it
• Similar to IP redirects, when packet in/out interface is the same
• Used only in DMVPN Phase 3 to build spoke-to-spoke tunnels

REFERENCE

1.  INE_DMVPN_Overview
2.  cisco_doc_dmvpn_configuration

 

OSPF Stub Router Advertisement

OSPF Stub Router Advertisement

• This feature apply only stub areas routers which have  many forwarding routers to forward route to back bone or non-back bone areas
• This feature causes the router to advertise a maximum metric for non-stub destinations, making it the worst cost path to all destinations
• The result is that upon initializing the OSPF process, transit traffic will not flow through that stub router unless it is the only possible path.
• The "max-metric router-lsa" synatx unconditionally withdraw forwarding route to other areas
• Route from R5 must forward through R3 to R6.
• R1 will drop the route from R5 when " max-metric router-lsa" feature apply to specific router
  
    
  • R1 apply this feature
    
  
  
  • R5 route forward through R3 to R6
  
  

  
  REFERENCE
  1. INE_WORKBOOK_OSPF_STUB_ROUTE_ADVERTISEMENT 
  2. CISCO_DOC_GUIDE_STUB_ROUTE_ADVERTISEMENT