Category Archives: CCNP – VPN

A collection of IMPORTANT links to review and know for exam day, then a quick overview of LSA Types / OSPF Router Types!

(This post will be replacing the subnetting post in my sticky threads up top the blog)

I pulled this topology from my older posts when I took a deep dive into the world of LSA’s, how to read the Topology table like a laundry list and under stand it, and what type of routers did what.

First I want to list links that are absolutely vital to read and understand for exam day, as you will run into questions regarding these in some fashion or another, and then I will sticky this post up top so the links are available there as well:

LSA Part 1 – https://loopedback.com/2017/04/24/part-1-ospf-lsa-deep-dive-starting-with-lsa-types-1-2-3-and-an-intro-to-all-lsa-types-and-ospf-routers-types/

LSA Part 2 – https://loopedback.com/2017/04/25/part-2-ospf-lsa-deep-dive-lsa-types-4-5-and-turn-area-15-to-an-nssa-to-see-what-happens-with-the-ls-database/

LSA Part 3 – https://loopedback.com/2017/04/25/part-3-ospf-lsa-deep-dive-lsa-type-7-deep-dive-into-every-type-of-ospf-stub-area-and-how-it-impacts-lsas/

VPN types and Tunnel Modes – https://loopedback.com/2017/04/28/vpn-deep-dive-into-different-vpn-packet-types-differences-in-security-and-differences-in-modes-between-them/

OSPF Distribute-List vs Filter-List – https://loopedback.com/2017/04/27/ospf-deep-dive-distribute-list-vs-filter-list-in-and-reviewing-prefix-lists-as-they-filter-lists-use-prefixes-to-filter/

Quick methods to Subnet – https://loopedback.com/2017/05/09/important-subnetting-review-to-quickly-find-network-address-ranges-and-a-great-cheat-sheet-for-exam-day/

IPv6 Migration Strategies – https://loopedback.com/2017/03/11/ipv6-migration-strategies-from-ipv4-networks-need-to-know-details-for-exam-day-explained/comment-page-1/#comment-56

Identifying IPv6 Address Types – https://loopedback.com/2017/05/08/ipv6-quick-tips-on-some-good-to-knows-and-need-to-knows-for-ipv6-on-exam-day-may-be-adding-info-to-this-in-the-future/

EIGRP Distribute-List / Prefix-List configuration – https://loopedback.com/2017/05/10/eigrp-deep-dive-into-prefix-list-configurations-access-list-vs-prefix-list-using-prefix-lists-to-filter-eigrp-routes-with-distribute-lists/

I could keep adding posts to that list all day, as they are pretty important, but you need to have a solid understanding of VPN Types and Tunnel Modes (and what they do), LSA Types and Database understanding, the IPv6 material and knowing how to configure and apply Prefix-Lists, etc. I’d say read all my posts, but I wrote them and my mind still slips on the materials!

Now I pulled this explanation of the LSA types from an older post where I summarized them using the Topology above, so I will paste these into this post, and sticky this thread up top for visibility and move on to the next topic for review!

So first, I will start with a description of each LSA type of the 7 of them:

  • LSA Type 1 “Router” – “Router Link States” will be its header in the LSA DB, and the name is self explanatory, these LSA’s are generated by each router with updates on its local Link States, all router types generate and flood this LSA Type.
  • LSA Type 2 “Network” – “Net Link States” are only generated and sent by DR’s and BDR’s to routers in the Same Area, that are also on the same multi-access network type, LSA type stays within its own Area, only seen in NON-Point-to-Point network types
  • LSA Type 3 “Summary” – “Summary Net Link States” has nothing to do with summarization, but floods its summary of networks from one Area into others except for the Area it is part of – Not flooded into Total-Stub’d Areas (Stub or NSSA)
  • LSA Type 4 “Summary ASB” – “Summary ASB Link States” LSA type is only created by ABR’s back to the ASBR, so when redistribution is configured on the ASBR Router it flips a bit in its “Router LSA” (Type 1!), and the ABR(s) then create LSA type 4’s to pass along throughout the network giving OSPF neighbors the path back to the ASBR – Not flooded into Stub Areas.
  • LSA Type 5 “Autonomous System External Link State” – or “AS External Link States” in the OSPF LSA DB, these are your “O E1” and “O E2”  Redistributed routes, generated from the ASBR itself OUTSIDE an NSSA Area – Not flooded into Stub Areas.
  • LSA Type 6 – Not needed for the CCNP ROUTE, but it is for Multicast Extensions of OSPF (MOSPF), but again is not referenced in the the ROUTE exam, just wanted to mention for the sake of thoroughness
  • LSA Type 7 “NSSA LSA’s” – This type of LSA is generated by the ASBR INSIDE an NSSA Area does Redistribution, as Type 5 Redistribution LSA’s cannot enter an NSSA Area

Phew. So to cover what type of routers create which type of LSA’s ONE MORE TIME:

  • Type 1 – All Routers
  • Type 2 – All DR’s
  • Type 3, 4 – All ABR’s
  • Type 5 – ASBR’s OUTSIDE the NSSA Areas (NSSA’s don’t allow LSA type 5)
  • Type 6 – Reserved for MOSPF
  • Type 7 – ASBR’s INSIDE the NSSA Areas (Type 7 LSA’s [N1, N2 in route table])

 

If you don’t fully understand LSA’s, please review Part 1, 2, and 3 of the OSPF LSA posts linked above as this is crucial to exam success if you get some OSPF questions!

VPN: VRF-Lite review of behaviors, EVN Fundamentals, configuration explained, no labbing due to constraints even on 15.x IOS!

 

EVN_First_Draft

As I will not be doing a DEEP Dive or review of VRF-Lite outside of reviewing my own post on its configuration, I figured I would put the highlights of my VRF-Lite post here in terms of configuration. This way we can both get an overview of VRF-Lite, and how it compares to EVN, and how the two compare.

So the initial configuration output you see will be VRF-Lite, I will clearly indicate when we are switching gears into EVN mode, so if you want to skip straight to that it should not be too far down the page!

So to start, this is how VRF-Lite gets configured on a Cisco Router / Switch like ROAS:

R1:

R1(config)#int fa0/0
R1(config-if)#no shut
R1(config-if)#int fa0/0.2
R1(config-subif)#encap dot1q 2
R1(config-subif)#ip add 10.2.2.1 255.255.255.0
R1(config-subif)#int fa0/0.3
R1(config-subif)#encap dot1q 3
R1(config-subif)#ip add 10.3.3.1 255.255.255.0
R1(config-subif)#int fa0/0.4
R1(config-subif)#encap dot1q 4
R1(config-subif)#ip add 10.4.4.1 255.255.255.0
R1(config-subif)#

SW1:

SW1(config)#int fa0/2
SW1(config-if)#switchport mode access
SW1(config-if)#switchport access vlan 2
SW1(config-if)#int fa0/3
SW1(config-if)#switchport mode access
SW1(config-if)#switchport access vlan 3
SW1(config-if)#int fa0/4
SW1(config-if)#switchport mode access
SW1(config-if)#switchport access vlan 4
SW1(config-if)#

Like I said, exactly like (ROAS) Router on a Stick, then the actual VRF-Lite commands:

R1(config)#ip vrf VRF2
R1(config-vrf)#exit
R1(config)#ip vrf VRG3
R1(config-vrf)#EXIT
R1(config)#no ip vrf VRG3
% IP addresses from all interfaces in VRF VRG3 have been removed

R1(config)#ip vrf VRF3
R1(config-vrf)#exit
R1(config)#ip vrf VRF4
R1(config-vrf)#exit
R1(config)#

As seen I accidentally mis-typed VRF3 so upon deleting it, it shows it is removing all interfaces with it, this is because of how VRF-Lite handles routes for Virtual Route Forwarding.

Let me get one more case in point for VRF-Lite, to explain what is happening:

R1(config)#int fa0/0.2
R1(config-subif)#ip vrf forwarding VRF2
% Interface FastEthernet0/0.2 IP address 10.2.2.1 removed due to enabling VRF VRF2
R1(config-subif)#int fa0/0.3
R1(config-subif)#ip vrf forwarding VRF3
R1(config-subif)#ip add 10.3.3.1 255.255.255.0
R1(config-subif)#int fa0/0.4
R1(config-subif)#ip vrf forwarding VRF4
R1(config-subif)#ip add 10.4.4.1 255.255.255.0
R1(config-subif)#exit
R1(config)#do sh ip int bri
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            unassigned      YES NVRAM  up                    up
FastEthernet0/0.2          unassigned      YES NVRAM  up                    up
FastEthernet0/0.3          10.3.3.1        YES manual up                    up
FastEthernet0/0.4          10.4.4.1        YES manual up                    up
Serial0/0                  unassigned      YES NVRAM  administratively down down
FastEthernet0/1            unassigned      YES NVRAM  administratively down down
Serial0/1                  unassigned      YES NVRAM  administratively down down
R1(config)#

Then I had to re-add the IP address here:

R1(config)#int fa0/0.2
R1(config-subif)#ip add 10.2.2.1 255.255.255.0
R1(config-subif)#exit
R1(config)#do show ip int bri
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            unassigned      YES NVRAM  up                    up
FastEthernet0/0.2          10.2.2.1        YES manual up                    up
FastEthernet0/0.3          10.3.3.1        YES manual up                    up
FastEthernet0/0.4          10.4.4.1        YES manual up                    up
Serial0/0                  unassigned      YES NVRAM  administratively down down
FastEthernet0/1            unassigned      YES NVRAM  administratively down down
Serial0/1                  unassigned      YES NVRAM  administratively down down
R1(config)#

So a couple of things to note about VRF-Lite from the output above:

  • You must sub-interface and configure it to 802.1Q trunk for each instance
  • Its method of removing routes from the Global Routing Table and putting the route into its own Virtual Route Forwarding instance is to remove the IP from the interface if the VRF instance is applied to an interface with an existing IP address
  • Later on it goes into need to use different routing processes per instance for example “ospf proc 2 vrf VRF2”, “ospf proc 3 vrf VRF3”, etc and enter your network commands into separate processes.

If you do not understand VRF-Lite, I highly recommend giving this post a quick once over to familiarize yourself with what I mean with EIGRP not working and such.

As a disclaimer to that post, I thought VRF could not use EIGRP because at the time I was unfamiliar with the address-family command, so it IS possible to use with EIGRP!

 

NOW ONTO EASY VPN ROUTING NOW THAT WE UNDERSTAND OUR ROOTS OF VRF-LITE FOR VIRTUAL ROUTING NEEDS!

 

EVN essentially replaces VRF-Lite, as almost a VRF-Lite-Lite, as even at it’s most simple configuration as seen above it can become cumbersome quickly.

EVN takes path isolation for data, giving it the simplicity of Layer 2 (VLANs), and takes it to Layer 3 (VRF) without needing all the sub-interfaces and such.

Also, we get to learn a new command in the configuration, which I we love new commands and this is one I need to cover big time – “address-family”.

Before configuration, lets look at some of the main fundamentals of EVN:

  • No Sub-Interfaces, uses “vnet trunk” command on single Ethernet interface
  • Not generally used for WAN, unless in a specialized deployment
  • Does not just provide separate data paths, but separation of the Control Plane, the Data Plane, and Services as well – Like network services used by End Users
  • It supports services like DHCP, DNS, etc by keeping route in the RIB (Routing Information Base / IP Route table) while keeping them logically separated when traversing the network or being delivered to end users

Here are a few of it’s limitations, and with EVN supports:

  • It can be used on any Interface that can use 802.1Q Trunking (Ethernet), which is why I removed the NBMA from the above Topology and instead used Ethernet interfaces
  • It supports – Unicast Routing Options: OSPFv2, EIGRP, and Static Routes
  • It supports – Multicast Routing Options: PIM, MSDP, and IGMP

One final boring bullet point on the subject, here is what it requires for configuration:

  • “vnet trunk” on interface to define it is using EVN
  • “vnet tags” essentially replace VLAN tags in 802.1Q, making it a global value
  • “address-family” to defines what networks are in your “vnet tag”

OK, I have had it with this theory, lets get to some configurations!

First we will start our configuration with OSPF, which I wouldn’t normally bother posting the output, but however we get a first glimpse at the new “address-family” command in this configuration:

R1(config)#router rip
R1(config-router)#address-family ipv4 unicast
R1(config-router-af)#version 2
R1(config-router-af)#no auto
R1(config-router-af)#network 172.12.12.0
R1(config-router-af)#network 172.12.13.0
R1(config-router-af)#?
Router Address Family configuration commands:
  auto-summary            Enable automatic network number summarization
  default                 Set a command to its defaults
  default-information     Control distribution of default information
  default-metric          Set metric of redistributed routes
  distance                Define an administrative distance
  distribute-list         Filter networks in routing updates
  exit-address-family     Exit from Address Family configuration mode
  flash-update-threshold  Specify flash update threshold in second
  help                    Description of the interactive help system
  input-queue             Specify input queue depth
  maximum-paths           Forward packets over multiple paths
  neighbor                Specify a neighbor router
  network                 Enable routing on an IP network
  no                      Negate a command or set its defaults
  offset-list             Add or subtract offset from RIP metrics
  output-delay            Interpacket delay for RIP updates
  passive-interface       Suppress routing updates on an interface
  redistribute            Redistribute information from another routing
                          protocol
  timers                  Adjust routing timers
  traffic-share           How to compute traffic share over alternate paths
  validate-update-source  Perform sanity checks against source address of
                          routing updates
  version                 Set routing protocol version

R1(config-router-af)#

I used RIP because other routing protocols don’t let you get away with just “address-family ipv4 unicast” as a command with a <cr> there, and I am not opening that can of worms tonight going into multicast options.

Notice that before I did anything, I went from RIP configuration to “address-family” sub-configuration mode before I entered my usual no-auto and ver 2 commands along with my networks.

Now as highlighted in red, it shows that you must use the “exit-address-family” command from this sub-configuration mode to save the settings you configured, and here I will demonstrate you can actually put your “no auto” and “ver 2” in our out of address-family configuration mode:

R1(config)#router rip
R1(config-router)#address-family ipv4 unicast
R1(config-router-af)#no auto
R1(config-router-af)#ver 2
R1(config-router-af)#network 172.12.12.0
R1(config-router-af)#network 172.12.13.0
R1(config-router-af)#exit-address-family
R1(config-router)#exit
R1(config)#exit
R1#
*May  3 05:49:35.339: %SYS-5-CONFIG_I: Configured from console by console
R1#wr
Building configuration…

ASR#2
[Resuming connection 2 to r2 … ]

R2(config)#router rip
R2(config-router)#ver 2
R2(config-router)#no auto
R2(config-router)#address-family ipv4 unicast
R2(config-router-af)#network 172.12.12.0
R2(config-router-af)#exit-address-family
R2(config-router)#exit
R2(config)#exit
R2#wr
Building configuration…

ASR#3
[Resuming connection 3 to r3 … ]

R3#
R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#router rip
R3(config-router)#no auto
R3(config-router)#ver 2
R3(config-router)#address-family ipv4 unicast
R3(config-router-af)#network 172.12.12.0
R3(config-router-af)#network 172.12.13.0
R3(config-router-af)#exit-address-family

R3#
R3#sh ip route
Codes: C – connected, S – static, R – RIP, M – mobile, B – BGP
       D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area
       N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2
       E1 – OSPF external type 1, E2 – OSPF external type 2
       i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2
       ia – IS-IS inter area, * – candidate default, U – per-user static route
       o – ODR, P – periodic downloaded static route

Gateway of last resort is not set

     3.0.0.0/32 is subnetted, 1 subnets
C       3.3.3.3 is directly connected, Loopback3
     172.12.0.0/24 is subnetted, 3 subnets
R       172.12.12.0 [120/1] via 172.12.13.1, 00:00:26, FastEthernet0/0
C       172.12.13.0 is directly connected, FastEthernet0/0
R3#

So all is well with routing protocols, R3 can see R2 across R1, now we get into the VRF settings of the configuration.

At this point I’ve my IOS code or routers don’t really support “vnet” as an option under VRF Description or on my Ethernet faces (of course), as seen here:

R2(config-vrf)#?
VPN Routing/Forwarding instance configuration commands:
  address-family  Enter Address Family command mode
  default         Set a command to its defaults
  description     VRF specific description
  exit            Exit from VRF configuration mode
  no              Negate a command or set its defaults
  rd              Specify Route Distinguisher
  route-target    Specify Target VPN Extended Communities
  vpn             Configure VPN ID as specified in rfc2685

So we do have address-family! Unfortunately from a fairly older protocol (or at least the materials I found are 5+ years old), I am very surprised to find the function missing from my routers even running 15.x IOS.

However I will quickly type out the configurations you will need across all routers to make the EVN configuration work:

  • “vrf description (word)” Defines the VRF instance
  • R2(config-vrf)# vnet tag 10 – Works as the Layer 3 VLAN Tag type #
  • R2(config-vrf)# address-family ipv4

Repeat these 3 commands for each VRF instance, on all routers participating in EVN!

So if you wanted to make “vrf description RED” with a “vnet tag 10”, then a “vrf description BLUE” and “vnet tag 20”, etc. This needs to be configured for every router that will be passing this traffic.

Finally, on the Ethernet interfaces you will need to deploy a single command for it to recognize it is participating in EVN:

“vnet trunk”

That should be issued on all Ethernet interfaces pointing at EVN routers.

With that I have had enough of EVN, I am a bit perplexed my routers are ONLY missing the vnet commands (even on my 15.x IOS router), so I am going to leave it here at knowledge of EVN and a good (and much needed) refresher of VRF-Lite!

I encourage you watch youtube videos such as these to get a full explanation:

VPN: DMVPN, NHRP, and mGRE – Brief initial configuration review, verification review, and a link to all the gritty details!

dmvpn_2

Since we are now efficient at all things GRE and IPSec VPN at this point, that makes for a smooth transition into DMVPN , though I want to be crystal clear that the ROUTE Blueprint mentions only “Describe DMVPN (Single Hub)” so I will not be configuring it all over again, I do have a very config heavy link provided below for that.

First I’ll go over the theory, then throw up some initial config / verification examples just to familiarize yourself with, then finally a link to the page from whence they came.

So the above Topology gives the a good visual of all the components involved including:

  • NHRP Client / Server model in action, there is a Hub (NHS) and spokes (NHC’s)
  • mGRE (Multipoint) configured on the Hub to build multiple GRE tunnels
  • Physical (Underlay) Tunnel (Overlay) address terms
  • IPSec profiles to use in GRE for Securing the DMVPN tunnels once built (GRE over IPSEC!)

Now after drilling the last 3 posts about GRE, IPSec, and GRE over IPSEC we have a huge head start on understanding the initial configurations of (minus NHRP which will be referenced in the configs on this page only):

First lets review the roles that both (m)GRE and NHRP play in this to make it work:

  • First the spokes will report their Underlay (Physical) and Overlay (Tunnel) mappings to the NHS for its Database for future NHC Query’s as illustrated here:

dmvpn_3

  • Then a spoke router can Query the NHS for the Underlay mapping to the Overlay address requested as demonstrated here:

dmvpn_4

  • And in theory if all configurations are correct and good to go, a tunnel should be formed between R2 and R3 as illustrated here:

dmvpn_5

  • And that’s how babies are made (and DMVPN tunnels).

Now as mentioned above, I will post the initial configuration of both the NHS and the two spoke NHC’s, and link to it below the configurations / verification outputs:

GRE / NHRP (NOT IPSec initial configurations from R1 / R2 / R3:

R1

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int tu0
R1(config-if)#ip a
*Mar  1 17:39:30.031: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R1(config-if)#ip address 10.0.0.1 255.255.255.0
R1(config-if)#ip nhrp map multicast dynamic
R1(config-if)#ip nhrp network-id 1
R1(config-if)#tunnel source 172.12.123.1
R1(config-if)#tunnel mode gre multipoint
R1(config-if)#
*Mar  1 17:41:20.035: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
R1(config-if)#ip mtu 1416
R1(config-if)#

R2

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#int tu0
R2(config-if)#ip add 10
*Mar  1 18:00:20.802: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R2(config-if)#ip add 10.0.0.2 255.255.255.0
R2(config-if)#ip nhrp map 10.0.0.1 172.12.123.1
R2(config-if)#ip nhrp map multicast 172.12.123.1
R2(config-if)#ip nhrp network-id 1
R2(config-if)#ip nhrp nhs 172.12.123.1
R2(config-if)#tunnel source 172.12.123.2
R2(config-if)#tunnel mode gre multipoint
R2(config-if)#
*Mar  1 18:03:10.808: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
R2(config-if)#ip mtu 1416
R2(config-if)#

R3

R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#int tu0
R3(config-if)#
*Mar  2 03:21:45.649: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R3(config-if)#ip add 10.0.0.3 255.255.255.0
R3(config-if)#ip nhrp map 10.0.0.1 172.12.123.1
R3(config-if)#ip nhrp map multicast 172.12.123.1
R3(config-if)#ip nhrp network-id 1
R3(config-if)#ip nhrp nhs 10.0.0.1
R3(config-if)#tunnel source 172.12.123.3
R3(config-if)#tunnel mode gre multipoint
R3(config-if)#ip mt
*Mar  2 03:23:05.648: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
R3(config-if)#ip mtu 1416
R3(config-if)#

Then the final piece of the configuration, the GRE over IPSec configuration, R1 only:

Only the Hub(s) are configured with the GRE over IPSec configuration:

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#crypto isakmp policy 10
R1(config-isakmp)#hash md5
R1(config-isakmp)#encryption 3des
R1(config-isakmp)#authentication pre-share
R1(config-isakmp)#exit
R1(config)#crypto isakmp key cisco123 address 0.0.0.0 0.0.0.0
R1(config)#crypto ipsec transform TRANS esp-3des
R1(cfg-crypto-trans)#exit
R1(config)#crypto ipsec profile DMVPN
R1(ipsec-profile)#set transform-set TRANS
R1(ipsec-profile)#exit
R1(config)#int tu0
R1(config-if)#tunnel protection ipsec profile DMVPN
R1(config-if)#
*Mar  1 18:07:23.742: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
R1(config-if)#

You see the IKE policy is set, the pre-shared key (PSK), the Transform-Set (Encryption), and the IPSec Profile that references the Transform set, which the Profile is then referenced by the GRE tunnel for Encryption for it’s tunnels.

Going over those configurations, I had a lot of difficulty in that lab, I don’t see that I actually configured a multi-point interface on s0/0 so I think that caused me a lot of problems (though few things work as they are expected to in my labs initially).

Speaking of discussing R1 as the Hub of this network, this is a good time to really underscore I don’t refer to it as the NBMA network Hub, but a DMVPN Hub as well – So when being referred to as a Hub in a VPN context, think DMVPN Hub router!

Ahem, moving on.

Now, to wrap this up, lets take a look at the verification command:

R1#sh ip nhrp
10.0.0.3/32 via 10.0.0.3, Tunnel0 created 00:20:01, expire 01:58:16
  Type: dynamic, Flags: unique nat registered
  NBMA address: 172.12.123.3
R1#sh dmvpn
Legend: Attrb –> S – Static, D – Dynamic, I – Incompletea
        N – NATed, L – Local, X – No Socket
        # Ent –> Number of NHRP entries with same NBMA peer

Tunnel0, Type:Hub, NHRP Peers:1,
 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 —– ————— ————— —– ——– —–
     1    172.12.123.3        10.0.0.3    UP 00:20:24 D

R1#

  • “sh ip nhrp” to see current Registered Clients, Tunnel IP’s and their corresponding Physical Interface IP addresses
  • “sh dmvpn” gives about the same information, shows Registered Client status / uptime / IP Addresses, and will also show if you are on the Hub router.

Again this is from the initial setup, I go on to troubleshoot it, but I think I completely whiffed turning the Serial0/0 interface into a Multi-Point, and that’s why I initially had a single neighbor and later a flapping second neighbor at best in this post here regarding DMVPN configuration and troubleshooting that I am pulling this info from.

However given the ROUTE blueprint only requires a candidate to “Debscribe DMVPN”, the above commands mixed with a solid understanding of again the GRE / IPSec / GRE over IPSec posts that preceded this post on DMVPN.

If you read this post, and the preceding 3 posts regarding GRE / IPSec / GRE over IPSec, you will have that 10% of the VPN Section of the blueprint locked in!

Again, the hot-link to the whole DMVPN troubleshooting page is located here.

EDIT:

I wanted to add here a couple more pieces of material from the other page, that even if you don’t look at it, you should know for exam day:

NHRP and some details about it:

  • The sending of tunnel / interface IP information to the NHRP Server, it is considered “Registering” to the NHS, including when it boots up.
  • The NHS puts it in what is called its “Binding Table” or its “NHRP Database”

Also the “Phases” of DMVPN it is more like phases of its evolution rather than Phases of a VPN tunnel, so that has been said here are my comments from my earlier studies:

  • Phase 1 – Hub and Spoke Topology only as mGRE is only configured on Hub, Spokes use point-to-point configuration so no spoke-to-spoke communication, Hub can become bottleneck from CPU or Bandwidth utilization of handling all communication
  • Phase 2 – !!NO summarizaton allowed!!, Spoke-to-Spoke communications, No default route-originate from Hub, mGRE configured on Spokes and Hub router
  • No idea, haven’t watched the hours of INE video yet, but it’s much more technical

We were configuring (and I would guess the exam tests) on Phase 2 of the 3, so I would just pay attention to the details when configured over EIGRP as I had, you cannot summarize or use default route originate on the Hub because I’d imagine it is a multi-point interface which I somehow completely missed during that lab.

Anyways, its even later, I just keep thinking over the topic and important things to note for exam day. I will try to stop updating this now, and leave the details on the other page.

VPN: DEEP Dive into GRE over IPSec configuration, explanation, and very easy actually once you are familiar with GRE and IPSec!

OSPF_GRE_Over_IPSec2So this is very odd to me after going through the last two posts of GRE and IPSec configuration, however once I found good information, configuration was a breeze.

**PLEASE READ EXAM DAY NOTE AT END OF POST FOR SCENARIOS WHERE THE ROUTES HAVE TO BE IN THE DYNAMIC ROUTING PROTOCOL FOR OTHER ROUTERS**

You do need the basic GRE Tunnel configurations plus a little extra, and you need a LOT less IPSec configuration, though I am sure there are ways to make it more complex and add configurations on top of it.

I took a step back, and took multi-area OSPF out of it, and just used the NBMA routers with a specified loopback as take the IPSec GRE tunnel.

First important thing to note, and this I’m sure changes once you spend more time with this, however from what I found that if you are using dynamic routing protocols you DO NOT want your traffic on either side participating in those that will take the VPN tunnel!

Dynamic routing protocols can help get the encrypted traffic from point A to point B by learning the path to the remote router (when traversing multiple routers), however you will want a static route with GRE over IPSec which you will see why!

(So I actually could have left OSPF off completely with this network, because all of the interfaces showed as connected, except our loopbacks which we couldn’t add)

THAT BEING SAID, LETS CONFIGURE US SOME IPSEC GRE TUNNEL!

So to begin the configuration, first we make our GRE Tunnel, just as we did before, with the addition of one command to start the tie back to IPSec:

R2(config)#int tu0
R2(config-if)#tunnel
*Mar 31 00:11:11.825: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R2(config-if)#ip add 10.1.1.2 255.255.255.0
R2(config-if)#tunnel source s0/0
R2(config-if)#tunnel destination 172.12.123.3
R2(config-if)#
*Mar 31 00:12:16.912: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
R2(config-if)#
R2(config-if)#tunnel mode ipsec ipv4

ASR#3
[Resuming connection 3 to r3 … ]

R3(config)#int tu0
R3(config-if)#tunn
*Mar 31 21:07:10.592: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R3(config-if)#ip add 10.1.1.3 255.255.255.0
R3(config-if)#tunnel source s0/2
R3(config-if)#tunnel destination 172.12.123.2
R3(config-if)#
R2(config-if)#tunnel mode ipsec ipv4

*Mar 31 21:07:55.618: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
R3(config-if)#do ping 10.1.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 156/159/168 ms

These commands break down to:

  • Creating the tunnel interface
  • Setting the IP Address / Network it belongs to (10.1.1.0 /24)
  • Tunnel Source points at the WAN or Outbound interface
  • Tunnel Destination points at the Remote physical interface IP
  • Tunnel mode ipsec ipv4 tells GRE it will be using IPSec for communication
  • Once configured on both sides, ping the remote GRE IP to confirm connectivity

Notice that from the first router, as soon as you define an IP / Source / Destination for a Tunnel interface it is Up / Up. You will see it drop again throughout the configuration, but for the initial setup, that is a good behavior to know.

Next is some IPSec configs we know, such as Policy Creation, Pre-Shared Key creation, and define a Transform Set (no need to define a tunnel mode):

R2(config)#crypto isakmp policy 10
R2(config-isakmp)# encr 3des
R2(config-isakmp)# hash md5
R2(config-isakmp)# authentication pre-share
R2(config-isakmp)#exit
R2(config)#crypto isakmp key CCNP address 172.12.123.3
R2(config)#crypto ipsec transform-set VPNLAB ah-md5-hmac
R2(cfg-crypto-trans)#exit
R2(config)#
ASR#3
[Resuming connection 3 to r3 … ]

R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#crypto isakmp policy 10
R3(config-isakmp)# encr 3des
R3(config-isakmp)# hash md5
R3(config-isakmp)# authentication pre-share
R3(config-isakmp)#exit
R3(config)#crypto isakmp key CCNP address 172.12.123.2
R3(config)#crypto ipsec transform-set VPNLAB ah-md5-hmac
R3(cfg-crypto-trans)#exit
R3(config)#

What a world of difference, no Crypto ACL’s / Crypto Maps / Lifetimes / Interface configuration / Etc. I won’t go through the above configurations as you should be familiar with these by now, and if not, you need to review this post.

However, there is one additional command that ties GRE and IPSec together, which I will demonstrate here:

R2(config)#crypto ipsec profile PROTECT
R2(ipsec-profile)#set transform-set VPNLAB
R2(ipsec-profile)#int tu0
R2(config-if)#tunnel protection ipsec profile PROTECT
R2(config-if)#
*Mar 31 00:59:19.287: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
R2(config-if)#

So almost immediately you see the IPSec ISAKMP turn on, however I think I jumped over to R3 too fast to catch Tunnel0 going down, however we do see it coming back up here:

R3(config)#crypto ipsec profile PROTECT
R3(ipsec-profile)#set transform-set VPNLAB
R3(ipsec-profile)#int tu0
R3(config-if)#tunnel protection ipsec profile PROTECT
R3(config-if)#
*Mar 31 21:55:08.017: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
R3(config-if)#
*Mar 31 21:55:10.437: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
R3(config-if)#exit
R3(config)#

So to break down these new commands:

  • The IPSec side of the commands: “crypto ipsec profile (word)” defines an IPSec profile, you will need a Transform-Set defined as it will drop you into profile mode to “set transform-set (name)” which I’ve color-coded to see where the transform-set name is derived from in the config
  • The GRE side of the commands: “tunnel protection ipsec profile PROTECT” defines the transform-set to be used to secure / encrypt data during transmission

Now here comes the tricky part to me, as there is no Crypto ACL, or Crypto Map to call out that ACL, and we aren’t applying a Crypto Map calling out a Crypto ACL on the outside facing interface – So how the heck do we define our interesting traffic?

I was able to ping, but no encaps / decaps from “sh cry ipsec sa” were incrementing. So what the answer? Static Routes!

Now this took some real attention to detail, and my brain is working at 25% today, so the struggle is real – But I found the correct syntax for your static routes:

R2(config)#ip route 33.33.33.33 255.255.255.255 10.1.1.3

And

R3(config)#ip route 22.22.22.22 255.255.255.255 10.1.1.2

I kept trying to use an exit interface of tu0, however, it needed the GRE Tunnels remote peer IP address.

I entered the outside IP of the router, the tunnel0 interface, nothing was working until I caught that – This is why you want to keep all routes using IPSec GRE tunnels out of dynamic routing protocols!

(Note that I did have to put static routes on R1 pointing to 22.22.22.22 and 33.33.33.33 because it was not learning them via a Dynamic routing protocol)

Once all of that was complete, I verified my work:

R3#ping 22.22.22.22 source 33.33.33.33

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 22.22.22.22, timeout is 2 seconds:
Packet sent with a source address of 33.33.33.33
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 184/186/193 ms
R3#sh cry ipsec sa

interface: Tunnel0
    Crypto map tag: Tunnel0-head-0, local addr 172.12.123.3

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   current_peer 172.12.123.2 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 5, #pkts encrypt: 5, #pkts digest: 5
    #pkts decaps: 5, #pkts decrypt: 5, #pkts verify: 5

There is our encaps and decaps we want to see! Looking good!

R3#sh ip int bri
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            172.12.23.3     YES NVRAM  up                    up
FastEthernet0/1            172.12.34.3     YES NVRAM  up                    up
Serial0/2                  172.12.123.3    YES NVRAM  up                    up
Serial0/3                  unassigned      YES NVRAM  administratively down down
Loopback3                  3.3.3.3         YES NVRAM  up                    up
Loopback33                 33.33.33.33     YES manual up                    up
Tunnel0                    10.1.1.3        YES manual up                    up
R3#

Our Tunnel0 interface is Up/Up just how we want to see it, aaaaand:

R3#sh cry isa sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id slot status
172.12.123.2    172.12.123.3    QM_IDLE           1001    0 ACTIVE

The Phase 1 portion of our tunnel is obviously happy as well if we are even getting to the point of encaps and decaps, so on all accounts we have success!!!

The nice thing about this is, really you can add networks via static route that can take this tunnel without any Crypto ACL’s defining the traffic, so it is much more scalable of a solution in my opinion with less configuration / things that can go wrong.

However, as I feel I have done my job here getting this to work, I’m not digging any further into this topic – Time to move onto greener pastures which I am not sure what yet but it will come in the form of another DEEP Dive soon 🙂

One final note that is VERY important for exam day:

If the route / network needs to be in a dynamic routing protocol, you may be tasked to leave it in their to propagate to other routers, and in this scenario you may need for example a Distribute-List to prevent the type 3 LSA Prefix from creating an OSPF route on the router. Be very careful to watch for this on exam day!!!

VPN: DEEP Dive into IPSec, configurations / functions, the VPN fails, but is troubleshot with debugs / verification commands to fix the issue explained!

OSPF_GRE_Over_IPSec

This is more a Part 2 of 3 in the series of 1 being building a GRE tunnel which we now have, 2 building an IPSec Tunnel which we will have shortly, and 3 placing the GRE traffic into the IPSec VPN for transmission – As IPSec only sends Unicast but GRE takes any type of traffic and encapsulates it into a Unicast packet.

As this is an incredibly long lab given the robust amount of configuration, and the troubleshooting at the end, I want to post up here at the top all of the configurations used in the lab so you don’t need to read the whole post to get the base configs / troubleshooting / verification however I highly recommend you read the entire page:

 

  • access-list 123 permit ip 172.12.34.0 0.0.0.255 172.12.23.0 0.0.0.255
  • crypto isakmp policy 10
  • – encr 3des
  • – hash md5
  • – authentication pre-share
  • crypto isakmp key 0 CCNP address 172.12.123.3 (use # 6 for encrypted key)
  • crypto ipsec security-association lifetime seconds 86400
  • crypto ipsec transform-set VPNLAB ah-md5-hmac
  • – mode tunnel
  • crypto map CCNP 100 ipsec-isakmp
  • – set peer 172.12.123.2
  • – set transform-set VPNLAB
  • – match address 123
  • int s0/0
  • – crypto map VPNLAB
  • TROUBLESHOOTING AND VERIFICATION COMMANDS BELOW
  • debug crypto ipsec
  • show crypto isakmp sa
  • show crypto ipsec sa

I color coded things that are configured together as they drop you into different configuration modes, and put the few troubleshooting and verification commands at the bottom, however I again really encourage to read through the lab as it contains a lot of important information for exam day.

Or in the event you are like me and have already gone through the lab, and just want a quick reference to all commands used handy at the top of the page 🙂

 

 

First, we enable and create an ISAKMP / IKE policy for the VPN configurations:

 

Enabling ISAKMP for the IKE policy:

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#crypto isakmp enable
R2(config)#

Check! Verifying there IS a default policy on the router:

R2#sh cry isa policy

Global IKE policy
Default protection suite

        encryption algorithm:   DES – Data Encryption Standard (56 bit keys).
        hash algorithm:         Secure Hash Standard
        authentication method:  Rivest-Shamir-Adleman Signature
        Diffie-Hellman group:   #1 (768 bit)
        lifetime:               86400 seconds, no volume limit
R2#

Check! Note the default policy is called the “Default Protection Suite” and that the command “sh crypto isakmp policy” can be used almost as a cheat sheet of the what needs to be defined when making a new policy! Now to configure our own policy:

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#crypto isakmp policy ?
  <1-10000>  Priority of protection suite

R2(config)#crypto isakmp policy 10
R2(config-isakmp)#

Quick note – The lower the policy #, the higher priority it has in being used for IKE, moving on:

R2(config)#crypto isakmp policy 10
R2(config-isakmp)#authentication pre-share
R2(config-isakmp)#encryption ?
  3des  Three key triple DES
  aes   AES – Advanced Encryption Standard.
  des   DES – Data Encryption Standard (56 bit keys).

R2(config-isakmp)#encryption 3des ?
  <cr>

R2(config-isakmp)#encryption 3des
R2(config-isakmp)#hash ?
  md5  Message Digest 5
  sha  Secure Hash Standard

R2(config-isakmp)#hash md5
R2(config-isakmp)#lifetime ?
  <60-86400>  lifetime in seconds

R2(config-isakmp)#lifetime 86400

I gave some ?’s just to see modifiers, note you get a <cr> after you choose an encryption type, so you can’t throw them all into one policy like you can in transform sets (covered shortly), and that lifetime is in seconds but it is always good to check with IOS help.

We now have 2 IKE policies:

R2#sh cry isa pol

Global IKE policy
Protection suite of priority 10

        encryption algorithm:   Three key triple DES

        hash algorithm:         Message Digest 5

        authentication method:  Pre-Shared Key

        Diffie-Hellman group:   #1 (768 bit)

        lifetime:               86400 seconds, no volume limit

Default protection suite
        encryption algorithm:   DES – Data Encryption Standard (56 bit keys).
        hash algorithm:         Secure Hash Standard
        authentication method:  Rivest-Shamir-Adleman Signature
        Diffie-Hellman group:   #1 (768 bit)
        lifetime:               86400 seconds, no volume limit
R2#

These are the parameters that are sent to the remote peer as part of Phase 1 to match IKE criteria, and needless to say if Phase 1 goes bad, we will not make it to Phase 2.

One very important thing to note, when these policies are exchanged, the only thing that DOES NOT NEED TO MATCH IS LIFETIME!

If the recipients Lifetime is equal to or lower than the initiators, the lower value is used on the initiator.

 

Now to set the field of the IKE’s ISAKMP Policy:

 

First up is setting the pre-shared key, notice as you go through it my IOS is buggy and doesn’t recognize me setting it to encrypt the key, so I have to go clear text with it:

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#crypto isakmp key 6 ?

% Unrecognized command

R2(config)#crypto isakmp key ?

  0  Specifies an UNENCRYPTED password will follow

  6  Specifies an ENCRYPTED password will follow

R2(config)#crypto isakmp key 0 ?
  WORD  The UNENCRYPTED (cleartext) user password

R2(config)#crypto isakmp key 0 CCNP ?
  address   define shared key with IP address
  hostname  define shared key with hostname

R2(config)#crypto isakmp key 0 CCNP address ?
  A.B.C.D  Peer IP address
  ipv6     define shared key with IPv6 address

R2(config)#crypto isakmp key 0 CCNP address 172.12.123.3 ?
  A.B.C.D   Peer IP subnet mask
  no-xauth  Bypasses XAuth for this peer
  <cr>

R2(config)#crypto isakmp key 0 CCNP address 172.12.123.3
R2(config)#

When configuring the Transform-Set, one important note is that the Policies must agree exactly on the encryption and algorithm being used (Top two lines in ISAKMP Policy) to create an IPSec SA (Security Association).

As I mentioned briefly earlier, multiple Transform-Set’s can be configured and sent, and the remote peer will compare each set against its own until it finds a match, once a match is found the IPSec SA is built.

Now to look at Transform-Set configuration:

R2(config)#crypto ipsec transform-set VPNLAB ?
  ah-md5-hmac   AH-HMAC-MD5 transform
  ah-sha-hmac   AH-HMAC-SHA transform
  comp-lzs      IP Compression using the LZS compression algorithm
  esp-3des      ESP transform using 3DES(EDE) cipher (168 bits)
  esp-aes       ESP transform using AES cipher
  esp-des       ESP transform using DES cipher (56 bits)
  esp-md5-hmac  ESP transform using HMAC-MD5 auth
  esp-null      ESP transform w/o cipher
  esp-seal      ESP transform using SEAL cipher (160 bits)
  esp-sha-hmac  ESP transform using HMAC-SHA auth

Look familiar? That is because it was covered in depth in our DEEP Dive of VPN Packet Types / Headers, which we reviewed the difference between them, however in the list itself it does show the word ‘cipher’ in the ESP commands indicating it will encrypt them.

For lab purposes, I am going to use an AH scheme, cause I am not overly worried about the data payload:

R2(config)#crypto ipsec transform-set VPNLAB ah-md5-hmac
R2(cfg-crypto-trans)#?
Crypto transform configuration commands:
  default  Set a command to its defaults
  exit     Exit from crypto transform configuration mode
  mode     encapsulation mode (transport/tunnel)
  no       Negate a command or set its defaults

R2(cfg-crypto-trans)#mode ?
  transport  transport (payload encapsulation) mode
  tunnel     tunnel (datagram encapsulation) mode

R2(cfg-crypto-trans)#mode tunnel ?
  <cr>

R2(cfg-crypto-trans)#mode tunnel

This is also in the VPN Packet / Header DEEP Dive, as it describes whether you are using Transport or Tunnel mode, which for this I will use Tunnel mode.

So with the “crypto ipsec transform set (name) …” command we are configuring exactly what we looked at in the VPN Packet inspection, it is all contained in the Transform-Set!

Also a side note, I could have added every transform-set type there is on the original command to configure it, this is very often seen in the real world and may end up on the exam as well, and its a perfectly legal command to use all transform-set modifiers.

Moving along, lets look at the SA lifetime configuration command:

R2(config)#crypto ipsec security-association ?
  idle-time  Automatically delete IPSec SAs after a given idle period.
  lifetime   security association lifetime

  replay     Set replay checking.

R2(config)#crypto ipsec security-association lifetime ?
  kilobytes  Volume-based key duration
  seconds    Time-based key duration

R2(config)#crypto ipsec security-association lifetime seconds ?
  <120-86400>  Security association duration in seconds

R2(config)#crypto ipsec security-association lifetime seconds 86400 ?
  <cr>

R2(config)#crypto ipsec security-association lifetime seconds 86400
R2(config)#

This is an optional, global configuration to say how long IPSec SA’s will stay up, either with the “… idle-time” set to delete the SA, or if lifetime is used to tear down the tunnel by either a matter of time, or traffic limit.

This command is not seen a lot in the real world as no company I’ve seen wants their VPN to drop in regular intervals (or ever) so this configuration is mainly exam oriented.

 

Next up is Crypto ACL’s (Interesting Traffic)

 

This is a type of ACL is created for outbound traffic flows, not to permit or deny traffic, but to define what traffic should be encrypted / go through the tunnel, and all other traffic will be permitted as normal with encryption.

On the inbound side, a permit statement on the ACL means that if traffic shows up with a source that should be encrypted but is not, it will drop the traffic. Again this will not deny all other types of traffic, but if the inbound Crypto ACL has that subnet on it, it better be encrypted, or it is getting dropped!

***One important concept with a Crypto ACL is that it won’t be applied on the “in” or “out” on an interface, the same ACL (one line usually) is read forwards (normally) for outbound traffic and backwards for inbound traffic.***

If that does not make sense right away, read it until it does. On the local router, outbound the Crypto ACL is read normally, and inbound traffic reads the same ACL backwards:

R2(config)#
R2(config)#access-list 123 permit ip 172.12.23.0 0.0.0.255 172.12.34.0 0.0.0.255
R2(config)#

BAM! Yes that was anti-climatic, but that is it, this defines traffic coming from the x.x.23.x network and destined to the x.x.34.x network as “Interesting Traffic” that should cause the VPN to build if not already up and encrypt the traffic.

Needless to say, we will need an inverse ACL on the remote peer 🙂

 

Now for the final configuration, the almighty Crypto Map!

 

This is where we call out the Crypto ACL, set the Peer IP Address, and Transform-Set to be used:

R2(config)#crypto map CCNP ?
  <1-65535>       Sequence to insert into crypto map entry
  client          Specify client configuration settings
  isakmp          Specify isakmp configuration settings
  isakmp-profile  Specify isakmp profile to use
  local-address   Interface to use for local address for this crypto map
  redundancy      High availability options for this map

R2(config)#crypto map CCNP 100 ?
  gdoi          GDOI
  ipsec-isakmp  IPSEC w/ISAKMP
  ipsec-manual  IPSEC w/manual keying
  <cr>

R2(config)#crypto map CCNP 100 ipsec-isakmp ?
  dynamic  Enable dynamic crypto map support
  profile  Enable crypto map as a crypto-profile
  <cr>

R2(config)#crypto map CCNP 100 ipsec-isakmp
% NOTE: This new crypto map will remain disabled until a peer
        and a valid access list have been configured.
R2(config-crypto-map)#

Notice it gave us a little warning on the end, that is just saying your not done yet. Also I highlighted a few things as there is a jumble of output there.

I gave it a sequence number after its unique map name, chose the ipsec-isakmp option, and that was it before I hit enter to drop me into crypto-map configuration as seen – This is where you will set your ACL / Peer IP / Transform-Set (we are getting close to done if you can believe that):

R2(config-crypto-map)#match address 123    <- Crypto ACL
R2(config-crypto-map)#set ?
identity              Identity restriction.
ip                    Interface Internet Protocol config commands
isakmp-profile        Specify isakmp Profile
nat                   Set NAT translation
peer                  Allowed Encryption/Decryption peer.


pfs                   Specify pfs settings
security-association  Security association parameters
transform-set         Specify list of transform sets in priority order

R2(config-crypto-map)#set peer ?
A.B.C.D  IP address of peer

WORD     Host name of the peer

R2(config-crypto-map)#set peer 172.12.123.3 ?
default  Reset to default peer in list in the event of a failure
<cr>

R2(config-crypto-map)#set peer 172.12.123.3

R2(config-crypto-map)#set ?
identity              Identity restriction.
ip                    Interface Internet Protocol config commands
isakmp-profile        Specify isakmp Profile
nat                   Set NAT translation
peer                  Allowed Encryption/Decryption peer.
pfs                   Specify pfs settings
security-association  Security association parameters
transform-set         Specify list of transform sets in priority order

R2(config-crypto-map)#set transform-set ?
WORD  Proposal tag

R2(config-crypto-map)#set transform-set VPNLAB ?
WORD  Proposal tag
<cr>

R2(config-crypto-map)#set transform-set VPNLAB


R2(config-crypto-map)#

Now the veeeeery last thing is to apply it to the outside interface of the router:

R2(config)#int s0/0
R2(config-if)#crypto map CCNP

R2(config-if)#
*Mar 30 23:57:59.226: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
R2(config-if)#

Like I said no “in” or “out” with this ACL, apply the Crypto Map by its name, and you should see that ISAKMP is ON message if we a rockin – Now I will configure this on the other side without displaying that huge mess of output again!

I have shut down int fa0/0 on R3 so it only knows the route to 172.12.23.0 via OSPF across the NBMA, I have also remove the static route from R2 from the previous lab that allowed traffic GRE traffic to take the tunnel.

I have set “debug ipsec crypto” on R2 and R3 just int case something starts happening immediately when configured to the outside Serial face, lets have a look:


R2#debug crypto ipsec
Crypto IPSEC debugging is on
R2#
ASR#3
[Resuming connection 3 to r3 … ]


R3#
R3#debug crypto ipsec
Crypto IPSEC debugging is on
R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#int s0/2
R3(config-if)#crypto map VPNLAB
R3(config-if)#
*Mar 31 20:08:19.690: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
R3(config-if)#

Honestly I was hoping to see some spur of life there, but like I said previously the ACL will detect VPN traffic, and that will then build the VPN tunnel (so the first few pings might … on you):

Debug output from R3:

*Mar 31 20:15:22.692: IPSEC(sa_request): ,
  (key eng. msg.) OUTBOUND local= 172.12.123.3, remote= 172.12.123.2,
    local_proxy= 172.12.34.0/255.255.255.0/0/0 (type=4),
    remote_proxy= 172.12.23.0/255.255.255.0/0/0 (type=4),
    protocol= AH, transform= NONE  (Tunnel),
    lifedur= 86400s and 4608000kb,
    spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x0
*Mar 31 20:15:24.126: IPSEC(validate_proposal_request): proposal part #1
*Mar 31 20:15:24.130: Crypto mapdb : proxy_match
        src addr     : 172.12.34.0
        dst addr     : 172.12.23.0
        protocol     : 0
        src port     : 0
        dst port     : 0
R3#
*Mar 31 20:15:24.134: IPSEC(key_engine): got a queue event with 1 KMI message(s)
*Mar 31 20:15:24.134: Crypto mapdb : proxy_match
        src addr     : 172.12.34.0
        dst addr     : 172.12.23.0
        protocol     : 0
        src port     : 0
        dst port     : 0
*Mar 31 20:15:24.138: IPSEC(crypto_ipsec_sa_find_ident_head): reconnecting with the same proxies and peer 172.12.123.2
*Mar 31 20:15:24.138: IPSEC(policy_db_add_ident): src 172.12.34.0, dest 172.12.23.0, dest_port 0
*Mar 31 20:15:24.142: IPSEC(create_sa): sa created,
  (sa) sa_dest= 172.12.123.2, sa_proto= 51,
    sa_spi= 0x616C073C(1634469692),
    sa_trans= ah-md5-hmac , sa_conn_id= 2
*Mar 31 20:15:24.142: IPSEC(update_current_outbound_sa): updated peer 172.12.123.2 current outbound sa to SPI 616C073C
R3#

 

The debug output on R2’s side is much more brief:
*Mar 30 23:21:33.479: IPSEC(key_engine): got a queue event with 1 KMI message(s)
*Mar 30 23:21:33.703: IPSEC(validate_proposal_request): proposal part #1
*Mar 30 23:21:33.703: IPSEC(validate_proposal_request): proposal part #1,
  (key eng. msg.) INBOUND local= 172.12.123.2, remote= 172.12.123.3,
    local_proxy= 172.12.23.0/255.255.255.0/0/0 (type=4),
    remote_proxy= 172.12.34.0/255.255.255.0/0/0 (type=4),
    protocol= AH, transform= ah-md5-hmac  (Tunnel),
    lifedur= 0s and 0kb,
    spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x0
*Mar 30 23:21:33.707: Crypto mapdb : proxy_match
        src addr     : 172.12.23.0
        dst addr     : 172.12.34.0
        protocol     : 0
        src port     : 0
        dst port     : 0
*Mar 30 23:21:33.731: IPSEC(key_engine): got a queue event with 1 KMI message

We seem to have a mismatch somewhere along the configuration it would appear by our debug output, and the continuous pings of course kept failing, but here is one thing to definitely note:

R2#sh crypto isa sa

IPv4 Crypto ISAKMP SA
dst             src             state          conn-id slot status
172.12.123.2    172.12.123.3    QM_IDLE           2001    0 ACTIVE

IPv6 Crypto ISAKMP SA

R2#
ASR#3
[Resuming connection 3 to r3 … ]

R3#sh cry isa sa

IPv4 Crypto ISAKMP SA
dst             src             state          conn-id slot status
172.12.123.2    172.12.123.3    QM_IDLE           1001    0 ACTIVE

IPv6 Crypto ISAKMP SA

R3#
ASR#4
[Resuming connection 4 to r4 … ]
………..

Success rate is 0 percent (0/73)
R4#

As you can see R4 continue to timeout, however the “sh crypto isakmp sa” verifies that Phase 1 negotiated and created the IPSec SA, however we are not agreeing on Phase 2 parameters, particularly the transform-set that would actually be used to encrypt the data.

THIS IS A VERY IMPORTANT DISTINCTION, AS WE IN THE VPN’S BUSINESS MUST KNOW WHAT THE FOLLOWING OUTPUT MEANS, AND HOW TO INTERPRET IT!!! :

R3#sh cry ipsec sa

interface: Serial0/2
    Crypto map tag: VPNLAB, local addr 172.12.123.3

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (172.12.34.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (172.12.23.0/255.255.255.0/0/0)
   current_peer 172.12.123.2 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 72, #pkts encrypt: 72, #pkts digest: 72
    #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 1, #recv errors 0

     local crypto endpt.: 172.12.123.3, remote crypto endpt.: 172.12.123.2
     path mtu 1500, ip mtu 1500, ip mtu idb Serial0/2
     current outbound spi: 0x616C073C(1634469692)

     inbound esp sas:

     inbound ah sas:

R3#
ASR#2
[Resuming connection 2 to r2 … ]

R2#sh cry ipsec sa

interface: Serial0/0
    Crypto map tag: CCNP, local addr 172.12.123.2

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (172.12.23.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (172.12.34.0/255.255.255.0/0/0)
   current_peer 172.12.123.3 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
    #pkts decaps: 72, #pkts decrypt: 72, #pkts verify: 72
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

     local crypto endpt.: 172.12.123.2, remote crypto endpt.: 172.12.123.3
     path mtu 1500, ip mtu 1500, ip mtu idb Serial0/0
     current outbound spi: 0xF0BC088B(4038854795)

     inbound esp sas:

     inbound ah sas:
 –More–

When you see one side that is having encaps but not decaps, your first step is to verify that destination is reachable to the router performing the tunnel / encryption:

R3#ping 172.12.34.100

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.12.34.100, timeout is 2 seconds:
..

Yep. This is not necessarily ever a VPN config problem, so don’t jump straight to debugs necessarily, in this example I had turned my lab off to do dishes and forgot to “wr mem” on SW1 so its default route pointed at R2 got wiped out.

After re-applying that default route, and pinging once again from R4:

R4#ping 172.12.23.100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.12.23.100, timeout is 2 seconds:
!!!!!

🙂

R3#sh cry ipsec sa

interface: Serial0/2
    Crypto map tag: VPNLAB, local addr 172.12.123.3

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (172.12.34.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (172.12.23.0/255.255.255.0/0/0)
   current_peer 172.12.123.2 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 138, #pkts encrypt: 138, #pkts digest: 138
    #pkts decaps: 61, #pkts decrypt: 61, #pkts verify: 61

R2#sh cry ipsec sa

interface: Serial0/0
    Crypto map tag: CCNP, local addr 172.12.123.2

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (172.12.23.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (172.12.34.0/255.255.255.0/0/0)
   current_peer 172.12.123.3 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 342, #pkts encrypt: 342, #pkts digest: 342
    #pkts decaps: 418, #pkts decrypt: 418, #pkts verify: 418

As you can see I did a happy dance before I got over to R2 to confirm it is encap’ing and decap’ing as well, meaning the traffic from R3 to R2’s Ethernet segment are now being encrypted before transmission, and my job to see this lab through to the end is done!

Now that it’s 2am I am officially fried for the night, I will be sure to wr mem on all devices this time, and our next step is to get GRE configured to take the IPSec tunnel!

To summarize, here are all the commands by themselves, no more explanations to configure and troubleshoot an IPSec VPN:

  • access-list 123 permit ip 172.12.34.0 0.0.0.255 172.12.23.0 0.0.0.255
  • crypto isakmp policy 10
  • – encr 3des
  • – hash md5
  • – authentication pre-share
  • crypto isakmp key 0 CCNP address 172.12.123.3 (use # 6 for encrypted key)
  • crypto ipsec security-association lifetime seconds 86400
  • crypto ipsec transform-set VPNLAB ah-md5-hmac
  • – mode tunnel
  • crypto map CCNP 100 ipsec-isakmp
  • – set peer 172.12.123.2
  • – set transform-set VPNLAB
  • – match address 123
  • int s0/0
  • – crypto map VPNLAB
  • TROUBLESHOOTING AND VERIFICATION COMMANDS BELOW
  • debug crypto ipsec
  • show crypto isakmp sa
  • show crypto ipsec sa

I color coded things that are configured together as they drop you into different configuration modes, and put the few troubleshooting and verification command at the bottom, I will actually put this list at the top as well to just stare at if need be.

VPN: DEEP Dive into GRE Tunnel configuration over OSPF, explanation of behaviors and how to overcome them!

OSPF_GRE_Over_IPSec

Now I’ve spent hours and hours trying to figure GRE out, this was not included in my CCNP ROUTE material except for some DMVPN using mGRE, however I did want to know for practical purposes how to encapsulate broadcast / multicast traffic over an IPSec tunnel which in turn needs a GRE tunnel as there is none.

Now GRE is not a LAN-to-LAN (L2L) tunnel as I had expected it to be, so I spent hours trying to figure out why it showed as Up / Up and debugs showed packet encapsulation and decapsulation, but my traceroutes would NOT take the tunnel interface!

After mentioned hours of researching, I found that GRE is actually a router to router tunnel, and IPSec is a L2L tunnel type. I was wondering this because, when I did a traceroute from SW1 to R3 with a default route pointed at R2 (To route it around the NBMA), it was replying back with router addresses and not the tunnels address.

So first let me get to the configuration, its so easy, I cannot believe how hard it was to configure properly:

R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#int tu0
*Mar 31 20:44:11.041: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R3(config-if)#ip add 10.1.1.3 255.255.255.0
R3(config-if)#tunnel source 172.12.123.3
R3(config-if)#tunnel dest 172.12.123.2
R3(config-if)#
*Mar 31 20:45:39.374: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
R3(config-if)#
R3(config)#router ospf 1
R3(config-router)#network 10.1.1.0 0.0.0.255 area 0
ASR#2
[Resuming connection 2 to r2 … ]

R2(config)#
R2(config)#router ospf 1
R2(config-router)#network 10.1.1.0 0.0.0.255 area 0
R2(config-router)#int tu0
*Mar 30 23:52:58.962: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R2(config-if)#ip add 10.1.1.2 255.255.255.0
R2(config-if)#tunnel source 172.12.123.2
R2(config-if)#tunnel dest 172.12.123.3
R2(config-if)#
*Mar 30 23:53:36.644: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
R2(config-if)#do sh ip int bri
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            172.12.23.2     YES manual up                    up
Serial0/0                  172.12.123.2    YES manual up                    up
FastEthernet0/1            unassigned      YES unset  administratively down down
Serial0/1                  unassigned      YES unset  administratively down down
Loopback2                  2.2.2.2         YES manual up                    up
Tunnel0                    10.1.1.2        YES manual up                    up

What I was really, reaaaally struggling with is the “recursive lookup” which essentially is a route lookup loop on the local router, which is an issue when running dynamic routing protocols, because your router will take the best path it knows how to get there and that dynamic protocol might provide it – This is why looking at GRE you see a lot of talk about default and static routing.

For example, consider this IP route table and traceroute:

R2#traceroute 172.12.34.3

Type escape sequence to abort.
Tracing the route to 172.12.34.3

  1 172.12.123.1 32 msec 32 msec 32 msec
  2 172.12.123.3 92 msec *  72 msec

If we look at the route table, there is already actually two entries that would route traffic to its destination:
R2#sh ip route

Gateway of last resort is 172.12.123.1 to network 0.0.0.0

     1.0.0.0/32 is subnetted, 1 subnets
O IA    1.1.1.1 [110/65] via 172.12.123.1, 00:40:50, Serial0/0
     2.0.0.0/32 is subnetted, 1 subnets
C       2.2.2.2 is directly connected, Loopback2
     3.0.0.0/32 is subnetted, 1 subnets
O IA    3.3.3.3 [110/65] via 172.12.123.3, 00:40:50, Serial0/0
     172.12.0.0/24 is subnetted, 4 subnets
O IA    172.12.34.0 [110/65] via 172.12.123.3, 00:32:09, Serial0/0
O IA    172.12.15.0 [110/65] via 172.12.123.1, 00:40:50, Serial0/0
C       172.12.23.0 is directly connected, FastEthernet0/0
C       172.12.123.0 is directly connected, Serial0/0
     10.0.0.0/24 is subnetted, 1 subnets
C       10.1.1.0 is directly connected, Tunnel0
O*E2 0.0.0.0/0 [110/1] via 172.12.123.1, 00:32:14, Serial0/0

Because instead of just making a static route I used “default-information originate always” on R1, so it is a Type 5 LSA (External), which of course has the same AD as any OSPF route, so both routes essentially said take OSPF and not the tunnel.

So I added a static route to get thing moving along:

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#ip route 172.12.34.0 255.255.255.0 tu0
R2(config)#exit
R2#traceroute 172.12.34.3

Type escape sequence to abort.
Tracing the route to 172.12.34.3

  1 10.1.1.3 104 msec *  92 msec
R2#

ASR#3
[Resuming connection 3 to r3 … ]

R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#ip route 2.2.2.2 255.255.255.255 tu0
R3(config)#exit
R3#traceroute
*Mar 31 21:29:59.414: %SYS-5-CONFIG_I: Configured from console by console
R3#traceroute 2.2.2.2

Type escape sequence to abort.
Tracing the route to 2.2.2.2

  1 10.1.1.2 100 msec *  100 msec
R3#

So essentially it just needed a static route so the AD would be lower than 110 from the OSPF learned routes.

How IPSec you actually create an ACL to define interesting traffic, with GRE you simply have to tell the router to route traffic to the remote destination over your tunnel interface, and make sure you have connectivity between your source ad dest IP’s.

Now that I have a thorough understanding of this, and have spent hours / days researching this topic and different approaches to GRE despite it being the oldest pile of dirt VPN there is, this is how it is not only configured but how routes are created to take the tunnel to the destination network when dynamic routing is running.

This has really cost me some DEEP Diving time so up next will be IPSec configuration, and then integrating GRE with it to encapsulate GRE traffic, but for now it is nap time to let my brain cool off!

  • Note that Cisco recommends you use a logical loopback interface as your source address, in case of a link failure, however I’ve spent so much time on this already I am just using the outside interfaces.

VPN: DEEP Dive into different VPN Packet Types, Packet Headers, and the differences between VPN Packets and their Modes!

VPN_Headers

This first image is a break down of the different types of VPN Packet Type by the headers / trailers (or lack thereof), and the following of your typical IPSec VPN Packet Type:

packet_segments_ipsec

The VPN generic representation of the IPSec VPN Packet above works for a general review, but there are details in the headers that are begging for exam questions and must be broken down and committed to memory if asked about them.

  • AH (Authentication Header) = Security, Data Origin Authentication (also offers anti-reply protection)
  • ESP (Encapsulating Security Payload) = Method of authentication / securing / encrypting the Data payload
  • IKE (Internet Key Exchange) – The protocol to negotiate security parameters and authentications keys to form an SA (Security Association)

Going from top to bottom, lets review each Packet type going down the list above from the top of the page:

  • Generic Frame = Ethernet Header | IP Header | Protocol Header | Payload
  • 1. Ethernet Header = Encapsulates Ethernet Frame
  • 2. IP Header = Source IP Address
  • 3. TCP/UDP Header = Port information, for a quick read on  TCP vs UDP Headers that link is gold for a brief but concise comparison
  • 4. Data / Payload = “Blah blah blah”

Used by GRE, which is mostly mentioned regarding mGRE for DMVPN Functionality, it can also be configured to be encapsulated INSIDE IPSec VPN tunnels because it does not have limitations that IPSec VPN’s have which is as follows:

  • 1. IPSec tunnels can Secure and Encrypt Unicast Information, but not Multicast or Broadcast traffic, which may be needed between sites
  • 2. GRE tunnels send Unicast Packets that can encapsulate Multicast and Broadcast traffic, which can than be placed into a new IPSec packet as a unicast packet so Multicast and Broadcast traffic can traverse VPN tunnels!

There will be a separate lab for GRE / IPSec that will demonstrate this concept as it is important to know both for the lab and real world as we always want more tools to get the job done!

Tunnel modes for VPN types explained in detail

First to be discussed will be the two Transport Modes, as they are hiding a field switcheroo in the packet fields you’d overlook at first glance:

  • 1. Tunnel mode will encrypt the packet, and place that packet into a new packet, which will then route on agreed IP addresses between the Tunnel Endpoints
  • 2. Transport mode will encrypt the IP packets payload, but the IPSec Header is inserted behind the IP Header, exposing the source address of the data, and only truly secures data from the Transport Layer up as the Source IP is used

So if you are not looking again at that top illustration and saying “Oh, I didn’t see that, good to know” you either already know it or did not understand what you just read 🙂

AH Tunnel / Transport Mode explained in detail

First we will review the 2 different flavors of AH Packets, explained from most protect to least, with details about each segments purpose:

  • AH Tunnel Mode = Ethernet Header | New IP Header | AH Header| IP Header | TCP/UDP Header | Payload
  • 1. Ethernet Header = Encapsulates Ethernet Frame
  • 2. New IP Header = Usually IP of the Security Gateway / Peer IP
  • 3. AH Header = Security, Data Origin Authentication, optional Anti-Replay Protection (No Data Confidentiality / Encryption)
  • 4. IP Header = Source IP Address
  • 5. TCP/UDP Header = Port information, for a quick read on  TCP vs UDP Headers that link is gold for a brief but concise comparison
  • 6. Data / Payload = “Blah blah blah”

 

  • AH Transport Mode = Ethernet Header | IP Header | AH Header | TCP/UDP Header | Payload
  • 1. Ethernet Header = Encapsulates Ethernet Frame
  • 2. AH Header = Security, Data Origin Authentication, optional Anti-Replay Protection (No Data Confidentiality / Encryption)
  • 3. IP Header = Source IP Address
  • 4. TCP/UDP Header = Port information, for a quick read on  TCP vs UDP Headers that link is gold for a brief but concise comparison
  • 5. Data / Payload = “Blah blah blah”

It is a viable VPN solution to use, as it will protect the IP Packets payload, however the Authentication it provides is not complete. As some of the IP Header fields may be changed in transmission,  the receiver cannot accurately predict the IP fields, thus making it complete but it still offers all attributes mentioned in the AH Header.

The one big strike against AH is that although it does protect the data Payload and is considered secure, the Payload is NOT encrypted so AH is considered non-Confidential.

The IP Header:

ipv4_header

The Authentication Header:

AH_Header

Next is the two more secured options of ESP, offering an ESP Header / Trailer, as well as ESP Authentication – Lets review both again, most secure to least:

  • ESP Tunnel Mode = Ethernet Header | New IP Header | ESP Header| IP Header | TCP/UDP Header | Payload | ESP Trailer | ESP Authentication
  • 1. Ethernet Header = Encapsulates Ethernet Frame
  • 2. New IP Header = Usually IP of the Security Gateway / Peer IP
  • 3. IPSec / ESP Header = Encapsulates data / Encryption, Data Confidentiality
  • 4. IP Header = Source IP Address
  • 5. TCP/UDP Header = Port information, for a quick read on  TCP vs UDP Headers that link is gold for a brief but concise comparison
  • 6. Data / Payload = “Blah blah blah”
  • 7. ESP Trailer = Encapsulates Data / Padding
  • 8. ESP Authentication =  Authentication Data / Hash Checksum

 

  • ESP Transport Mode = Ethernet Header | IP Header | ESP Header | TCP/UDP Header | Payload | ESP Trailer | ESP Authentication
  • 1. Ethernet Header = Encapsulates Ethernet Frame
  • 2. IP Header = Source IP Address
  • 3. IPSec / ESP Header = Encapsulates data / Encryption, Data Confidentiality
  • 4. TCP/UDP Header = Port information, for a quick read on  TCP vs UDP Headers that link is gold for a brief but concise comparison
  • 5. Data / Payload = “Blah blah blah”
  • 6. ESP Trailer = Encapsulates Data / Padding / Pad Length / Next Header
  • 7. ESP Authentication =  Authentication Data / Hash Checksum

Now I want to post the image at the top right here for quick comparison among all of these different methods of VPN / Modes:

VPN_Headers

So as can be seen, ESP is highly preferred over AH if you have the resources to run it, and that “Tunnel” mode is preferred over “Transport” mode because it keeps the Source IP Address secure.

Here is an image that I thought was very visual and helpful to seeing the difference in ESP Tunnel vs Transport mode:

IP_Security_IPSec_ESP_01

I am completely fried so that will be it for thd packet details, next DEEP Dive will be GRE over IPSec lab to see if we can brainwash the configuration just like all of this information – I can’t wait 🙂