|
0:00:13
|
In our next section we are going to look at three different additional variation of LAN-to-LAN IPsec tunnels
|
|
0:00:19
|
the first of which running GRE over an IPSec tunnel
|
|
0:00:23
|
in order to allow us to run dynamic routing
|
|
0:00:26
|
the IPSec profiles
|
|
0:00:29
|
that were originally designed for DMVPN and how they can be applied
|
|
0:00:33
|
to regular GRE tunnels
|
|
0:00:35
|
and to a new format of syntax that is known as the Virtual Tunnel Interface or the VTI
|
|
0:00:41
|
thats going to allow us to have a similar result
|
|
0:00:44
|
of running GRE over IPSec
|
|
0:00:46
|
with less overhead and less
|
|
0:00:48
|
configuration that we need to maintain
|
|
0:00:53
|
Now for these three examples we are going to be configuring a tunnel between router3 and router1
|
|
0:00:59
|
where the ultimate goal is that for this LAN-to-LAN IPSec tunnel
|
|
0:01:04
|
we want to get reachability from the 172.16 network
|
|
0:01:08
|
to the 192.168 networks that are behind router1 and behind router3
|
|
0:01:15
|
Now for the previous examples where we are doing just the most basic LAN-to-LAN IPSec tunnel
|
|
0:01:21
|
we didn't talk about any of the
|
|
0:01:23
|
potential issues where we run into with basic IP routing
|
|
0:01:27
|
in conjunction with IPSec
|
|
0:01:29
|
because previously the way that the topology was configured
|
|
0:01:33
|
is that between router3 and router4
|
|
0:01:36
|
we have EIGRP running
|
|
0:01:38
|
in order to advertise the 172.16 network
|
|
0:01:43
|
from router3 to 2 to 1
|
|
0:01:45
|
we have OSPF running
|
|
0:01:48
|
there was redistribution between the OSPF and the EIGRP process
|
|
0:01:53
|
then on router1, we have static routes that were pointing
|
|
0:01:55
|
at the VLAN 117 network
|
|
0:01:58
|
and the VLAN 118 network
|
|
0:02:00
|
which were then redistributed into the OSPF process
|
|
0:02:05
|
So essentially based on simply Dynamic Routing
|
|
0:02:08
|
the host on VLAN4
|
|
0:02:10
|
have a route to the host on VLAN117
|
|
0:02:13
|
and likewise to the host on VLAN118 and vice-versa
|
|
0:02:18
|
but in a real network design, this is not the typical case that you will see
|
|
0:02:22
|
because generally the frame relay cloud
|
|
0:02:25
|
that is between router1, 2 and 3
|
|
0:02:27
|
would be representing the internet
|
|
0:02:30
|
So some sort of public IP Network
|
|
0:02:33
|
that this network as a transit provider
|
|
0:02:36
|
is not going to able to have a route
|
|
0:02:38
|
to the 172.16 network
|
|
0:02:40
|
but on the 192.168 network
|
|
0:02:42
|
because these end networks are private addressing
|
|
0:02:45
|
in the ?? 1918 space
|
|
0:02:49
|
Now there is a couple of different
|
|
0:02:50
|
ways that we can use IPSec to get around this type of design problem
|
|
0:02:54
|
where we could go to router1
|
|
0:02:56
|
and configure a static IPSec tunnel to router3
|
|
0:03:00
|
similar
|
|
0:03:01
|
where we did before we configure our ISAKMP policy
|
|
0:03:05
|
we configure our
|
|
0:03:06
|
crypto map, we configure the transform set for our phase II options
|
|
0:03:10
|
then we would simply configure a static route
|
|
0:03:13
|
on router1 to say to get to 172.16.0.0/16 network
|
|
0:03:20
|
I am going to send this packets towards router2
|
|
0:03:24
|
Now even though router2 won't have a route
|
|
0:03:27
|
to this private address space
|
|
0:03:29
|
as long as the router1 points the route
|
|
0:03:31
|
out the interface that has the crypto map applied
|
|
0:03:35
|
the router knows that, that traffic really should be going inside the IPSec tunnel
|
|
0:03:39
|
not directly to the interface as clear text traffic
|
|
0:03:43
|
So its kind of a hack that you can run on the routing process
|
|
0:03:47
|
as long as you have a crypto map applied to the interface
|
|
0:03:51
|
Now as you can imagine as the network starts to scale and we add more sites
|
|
0:03:54
|
this type of configuration with doing static routing
|
|
0:03:57
|
is something not going to be manageable
|
|
0:04:00
|
So ideally we would be able to combine both of these at the same time
|
|
0:04:03
|
that we would have the IPSec
|
|
0:04:05
|
to add the encryption between the sites
|
|
0:04:07
|
but we could also add some type of dynamic routing
|
|
0:04:10
|
So we would need to maintain static route
|
|
0:04:12
|
for all of the inter site communication
|
|
0:04:15
|
and this is generally where the tunnel interface is
|
|
0:04:18
|
the GRE tunnels or the VTI tunnels
|
|
0:04:21
|
are going to come in
|
|
0:04:23
|
to allow us to combine both of these at the same time
|
|
0:04:27
|
So the first variation, running GRE over IPSec
|
|
0:04:30
|
is today kind of consider the legacy version of this
|
|
0:04:33
|
but we will go through the different iterations where GRE offer IPSec
|
|
0:04:37
|
as the first solution for this
|
|
0:04:38
|
running IPSec profiles over GRE
|
|
0:04:41
|
is going to make our configuration little easier
|
|
0:04:43
|
then finally the newer format with the Virtual Tunnel Interface
|
|
0:04:47
|
makes the logic much more straight forward
|
|
0:04:49
|
and give us less overhead
|
|
0:04:51
|
as compared to the previous solutions with running GRE over IPSec
|
|
0:04:57
|
Now before we get into any of the encryption with IPSec
|
|
0:05:00
|
the first thing that we are going to do is configure just a basic GRE tunnel
|
|
0:05:04
|
between router1 and router3
|
|
0:05:07
|
in order to get communication from the 192.168 network
|
|
0:05:11
|
to the 172.16 network
|
|
0:05:15
|
So really there is no special configuration about this which is going to create a tunnel interface
|
|
0:05:19
|
specify where the source and destination is
|
|
0:05:21
|
assign an IPv4 subnet
|
|
0:05:23
|
and then run a routing protocol on top of it
|
|
0:05:26
|
which in this case we are going to be running EIGRP
|
|
0:05:30
|
AS34
|
|
0:05:32
|
so EIGRP is going to run on this interface, this interface
|
|
0:05:35
|
the tunnel
|
|
0:05:37
|
then those static routes that router1 has pointed
|
|
0:05:40
|
towards the ASAs multiple context
|
|
0:05:42
|
these are going to be redistributed into the EIGRP process
|
|
0:05:45
|
which will eventually give us full reachability from VLAN4
|
|
0:05:49
|
to VLAN117 and to 118
|
|
0:05:55
|
so next just take a look at the command line
|
|
0:05:58
|
and before we even get to the tunnel configuration
|
|
0:06:01
|
just like we did with the previous LAN-to-LAN IPSec config
|
|
0:06:05
|
I would want to know do I have basic reachability to router3 to start
|
|
0:06:11
|
so if router1 and router3 don't have basic IP transport
|
|
0:06:14
|
then we know we are not going configure GRE, we are not going to configure IPSec
|
|
0:06:19
|
So it doesn't hurt to spend a couple of minutes just to do this basic
|
|
0:06:22
|
reachability verification
|
|
0:06:26
|
so now that I know that router1 and router4 atleast can reach each other
|
|
0:06:29
|
next thing I am going to do is configure a basic tunnel interface
|
|
0:06:34
|
we will say interface tunnel0
|
|
0:06:37
|
we will give it an IP address, we will say that this is
|
|
0:06:40
|
to 10.0.13.1
|
|
0:06:43
|
on router1
|
|
0:06:46
|
/24
|
|
0:06:49
|
on router3, we will say the same thing
|
|
0:06:51
|
interface tunnel0
|
|
0:06:54
|
the address will be 10.0.13.3
|
|
0:06:59
|
So any other subnet is unused in the topology
|
|
0:07:03
|
router3 is going to say that the tunnel source
|
|
0:07:05
|
is its
|
|
0:07:07
|
address we previously used for the VPN tunnel so 200.0.23.3
|
|
0:07:13
|
and the tunnel
|
|
0:07:15
|
destination
|
|
0:07:16
|
is 200.0.12.1
|
|
0:07:19
|
which is router1's address
|
|
0:07:22
|
router is going to do the same thing except these values are going to swapped
|
|
0:07:26
|
So we will say that the
|
|
0:07:27
|
tunnel source
|
|
0:07:31
|
is
|
|
0:07:33
|
200.0.12.1
|
|
0:07:36
|
and the tunnel destination
|
|
0:07:39
|
is 200.0.23.3
|
|
0:07:43
|
So at this point we should see the basic tunnel come up
|
|
0:07:46
|
if I were to then ping
|
|
0:07:47
|
10.0.13.3
|
|
0:07:50
|
which is the other end of the tunnel
|
|
0:07:52
|
we could see that router1 and 3 do have basic connectivity over the
|
|
0:07:56
|
over the tunnel
|
|
0:07:58
|
next thing I am going to do is configure basic routing
|
|
0:08:01
|
on router3, if we look at the show ip eigrp neighbours
|
|
0:08:06
|
we see that we do have an adjacency with router4 already
|
|
0:08:10
|
which is an eigrp AS10
|
|
0:08:13
|
and there is really no special configuration
|
|
0:08:15
|
in this process, if we show run section router eigrp
|
|
0:08:20
|
just the basic network statement, basic no auto summary
|
|
0:08:23
|
So on to process I will edit network statement for
|
|
0:08:26
|
the 10 network which is now the tunnel
|
|
0:08:29
|
and essentially the same thing on
|
|
0:08:31
|
router1
|
|
0:08:32
|
So for eigrp34
|
|
0:08:34
|
we have network 10
|
|
0:08:38
|
no auto summary
|
|
0:08:41
|
we could see already, we do have the adjacency up with
|
|
0:08:43
|
router3
|
|
0:08:44
|
and if we look at the show ip route static
|
|
0:08:48
|
I have the two static routes that are pointing to the 117 and the 118 network
|
|
0:08:52
|
and I am going to advertise these into eigrp
|
|
0:08:55
|
I could either redistribute static or I could simply say network
|
|
0:08:59
|
and then match these to routes
|
|
0:09:04
|
So as long as the router3 has the routes to them
|
|
0:09:06
|
thats what we are concerned about
|
|
0:09:08
|
So on router3 if we now look at
|
|
0:09:10
|
the show ip route eigrp
|
|
0:09:13
|
we should see shortly here over the tunnel
|
|
0:09:16
|
that we are going to learn
|
|
0:09:20
|
these particular routes, lets say show ip eigrp neighbours
|
|
0:09:25
|
we do have the adjacency with 1
|
|
0:09:35
|
on router1 if we
|
|
0:09:38
|
show ip eigrp
|
|
0:09:41
|
interfaces show ip eigrp neighbours
|
|
0:09:48
|
we do have adjacency with 3 lets say show ip route eigrp
|
|
0:09:51
|
Hey, we are learning routes from them
|
|
0:09:54
|
and on 3 we should be learning those
|
|
0:09:56
|
two static routes
|
|
0:09:58
|
I actually may need to change this
|
|
0:10:00
|
if I were to point these
|
|
0:10:03
|
say show ip route static
|
|
0:10:04
|
if these were to point at an interface as opposed to pointing towards an ip next hop
|
|
0:10:09
|
I could use the network statement for them
|
|
0:10:12
|
but instead of playing around with the routing domain
|
|
0:10:14
|
what I am simply going to do here then instead is say redistribute static
|
|
0:10:19
|
and I will give it just a basic metric
|
|
0:10:22
|
So the details of the routing domain
|
|
0:10:25
|
really is not the focus of this
|
|
0:10:27
|
that much as long as we can get the basic
|
|
0:10:30
|
routes to be learned
|
|
0:10:32
|
which we see now they are learned over the tunnel
|
|
0:10:34
|
which would then mean I should be able to go to switch2
|
|
0:10:38
|
and ping 172.16.4.4
|
|
0:10:43
|
the same would be true if I were to send this from
|
|
0:10:46
|
switch1
|
|
0:10:50
|
Now when we visualise this in the topology
|
|
0:10:53
|
the transit paths for these packets
|
|
0:10:55
|
are coming from switch1 to the ASA
|
|
0:10:58
|
to router1
|
|
0:10:59
|
1 sends them over the tunnel to 3
|
|
0:11:03
|
3 is sending them down to 4
|
|
0:11:07
|
However we know that the connection router1 and 3 over the tunnel is not an actual physical link
|
|
0:11:13
|
so the physical transit path of the packets actually has to go to router2 first
|
|
0:11:18
|
before it back down to router3
|
|
0:11:21
|
so I am going to do next on router2
|
|
0:11:24
|
is we are going to look at the debug IP packet detail
|
|
0:11:27
|
to see the packets moving over the tunnel between router1 and router3
|
|
0:11:32
|
and there is three different types of packets that we are going to look at
|
|
0:11:36
|
we are going to look at the debug for ICMP packets
|
|
0:11:39
|
for GRE packets
|
|
0:11:41
|
and for ESP packets that are going to be
|
|
0:11:44
|
inside of the IPSec tunnel
|
|
0:11:48
|
Now in order to do this I am going to go to router2
|
|
0:11:51
|
and previously what I had configured on the
|
|
0:11:55
|
WAN sub interfaces, the frame relay sub interfaces
|
|
0:11:58
|
is that ip route cache is off
|
|
0:12:00
|
which is disabling self
|
|
0:12:04
|
and in turn allowing me to doing a debug for transit packets that are moving between the interfaces
|
|
0:12:10
|
Now additionally to make sure that I am not going to see more output than I want
|
|
0:12:14
|
I am going to configure an access list here
|
|
0:12:16
|
access list 100 that is going to permit ICMP
|
|
0:12:20
|
GRE
|
|
0:12:21
|
and ESP
|
|
0:12:24
|
So three different IP protocol numbers
|
|
0:12:27
|
then I will debug IP packet detail with
|
|
0:12:30
|
access list 100
|
|
0:12:34
|
We can see already that there are some packets being matched by the debug
|
|
0:12:39
|
and lets undebug to see these real quick
|
|
0:12:43
|
it says that the packets are going from the router3
|
|
0:12:46
|
to router1
|
|
0:12:48
|
and from 1 back to 3
|
|
0:12:51
|
in both cases
|
|
0:12:52
|
these are IP protocol number 47
|
|
0:12:55
|
which is the GRE tunnel
|
|
0:13:00
|
Now these packets we can see they are fairly small
|
|
0:13:03
|
because these are the EIGRP hellos
|
|
0:13:06
|
that are bouncing back and forth between 1 and 3 that are going over the tunnel
|
|
0:13:10
|
So just basically the EIGRP keep alives
|
|
0:13:13
|
but we will see since EIGRP is sending these every so often
|
|
0:13:16
|
this debug is going to continue to show to show up
|
|
0:13:20
|
Now I want to show here
|
|
0:13:23
|
is the difference between the a packet that is going
|
|
0:13:26
|
over the tunnel
|
|
0:13:28
|
from 1 to 3
|
|
0:13:31
|
that is going this way versus a packet that is going
|
|
0:13:34
|
just natively
|
|
0:13:36
|
on the transit path from 1 to 3
|
|
0:13:39
|
and specifically this is going to be an ICMP packet
|
|
0:13:44
|
So on router2 lets turn this debug on again, lets say debug IP
|
|
0:13:48
|
packet detail 100
|
|
0:13:50
|
and from router1
|
|
0:13:53
|
I am going to send a ping
|
|
0:13:54
|
tunnel end point that we are using on router3, which is 200.0.23.3
|
|
0:14:01
|
and I am going to set the size of the packet to be 100 bytes
|
|
0:14:06
|
so its a 100 bytes total thats going to the headers
|
|
0:14:11
|
now if we look at router2
|
|
0:14:13
|
we should have seen from the debug
|
|
0:14:15
|
that there was the ICMP packet that went between 1
|
|
0:14:19
|
to 3
|
|
0:14:21
|
then from 3 back to 1
|
|
0:14:23
|
and lets put this into
|
|
0:14:27
|
lets put this into notepad here so we can save this
|
|
0:14:30
|
this is the ICMP
|
|
0:14:33
|
Say that native ICMP flow
|
|
0:14:37
|
is from
|
|
0:14:38
|
1 to 3 with length of 100
|
|
0:14:42
|
then from 3 to 1
|
|
0:14:45
|
back to same length
|
|
0:14:48
|
so this is the key here, I specified the size was 100 Byte
|
|
0:14:53
|
Now if I were to do the same ping
|
|
0:14:56
|
but to originate this from switch2
|
|
0:15:01
|
So from switch2 I am going to ping that same address
|
|
0:15:04
|
actually not the same address, lets ping the VLAN4, so now the traffic is going over the tunnel
|
|
0:15:12
|
lets go to switch2
|
|
0:15:14
|
we will do the same ping we will say that the size is 100
|
|
0:15:18
|
and I will give it a high repeat count, so we can make sure to see these
|
|
0:15:24
|
its going to be
|
|
0:15:26
|
these two flows here
|
|
0:15:30
|
and we can see its lots of packet debug here on
|
|
0:15:40
|
router2 so
|
|
0:15:42
|
ideally you wouldn't want to do this, you would want to send that to the buffer
|
|
0:15:47
|
but this one here is going to be
|
|
0:15:49
|
the ICMP over GRE
|
|
0:15:54
|
Now the key difference
|
|
0:15:56
|
that I am showing here is that when we look at the
|
|
0:15:59
|
the packet that is going from 1 to 3 and back
|
|
0:16:03
|
it says that this is protocol number 47, so this is GRE
|
|
0:16:08
|
and the length of the packet is now 124bytes
|
|
0:16:12
|
and the reason that this is the case
|
|
0:16:14
|
is that when we look at the difference between the normal IP packet
|
|
0:16:19
|
that has our ICMP payload
|
|
0:16:23
|
when I specify
|
|
0:16:25
|
a ping of 100 Bytes, this is going to include the full
|
|
0:16:28
|
IP header
|
|
0:16:30
|
the ICMP and then whatever the actual ICMP data payload is
|
|
0:16:35
|
when we are now sending this over a GRE tunnel
|
|
0:16:39
|
we have the additional GRE encapsulation
|
|
0:16:43
|
that goes on top of the previous IP packet
|
|
0:16:48
|
which then in turn contains the ICMP and the data
|
|
0:16:55
|
So the ICMP and then the data
|
|
0:16:58
|
So we actually have a
|
|
0:16:59
|
full new IP header followed by the GRE sub header
|
|
0:17:03
|
the original IP header
|
|
0:17:05
|
and then the ICMP payload
|
|
0:17:08
|
So from here, this is where we have the 100 Bytes
|
|
0:17:12
|
and notice from this output here in the debug
|
|
0:17:15
|
the length is now 124
|
|
0:17:17
|
thats because we have an additional 24 Bytes
|
|
0:17:20
|
for this GRE overhead
|
|
0:17:24
|
So as you would assume
|
|
0:17:26
|
adding additional encapsulation is going to add
|
|
0:17:28
|
additional payload
|
|
0:17:30
|
overhead for the entire
|
|
0:17:32
|
for the entire packet
|
|
0:17:34
|
So now we are looking at a difference of 100 Bytes versus 124
|
|
0:17:38
|
Now we can also see that
|
|
0:17:39
|
in the debug on router2
|
|
0:17:41
|
this is being sent as protocol 47
|
|
0:17:44
|
which is GRE
|
|
0:17:46
|
so if you were to do a packet level
|
|
0:17:49
|
analysis like a sniffer
|
|
0:17:51
|
you would be able to see the ICMP packets inside as clear text
|
|
0:17:56
|
So this is what we would then need to use IPSec in order to prevent
|
|
0:18:00
|
where we want to be able to tunnel between router1 and router3
|
|
0:18:04
|
but if we were to use just GRE on its own
|
|
0:18:07
|
any one in the transit path like router2
|
|
0:18:09
|
is going to be able the actual clear text thats inside there
|
|
0:18:14
|
now the original solution for this
|
|
0:18:16
|
was to take the entire GRE packet
|
|
0:18:20
|
and put an additional ESP header on top of it
|
|
0:18:24
|
So this would then mean that we are taking
|
|
0:18:27
|
the IP packet
|
|
0:18:29
|
that was followed by the GRE header
|
|
0:18:33
|
with our original IP header inside
|
|
0:18:36
|
the inside ICMP
|
|
0:18:38
|
and the ICMP data
|
|
0:18:40
|
then adding a new
|
|
0:18:43
|
ESP header
|
|
0:18:44
|
on ESP trailer
|
|
0:18:47
|
and an additional IP header on top of that
|
|
0:18:51
|
So you could see as you start to add additional encapsulation
|
|
0:18:54
|
it quickly starts to get out of control, how much overhead
|
|
0:18:57
|
is going for the header and the trailer
|
|
0:18:59
|
versus the actual payload that is inside of the packet
|
|
0:19:04
|
Now this configuration though is going to be very similar to what we saw
|
|
0:19:07
|
previously in the LAN-to-LAN VPN
|
|
0:19:10
|
the only difference is that when we
|
|
0:19:12
|
categorize what is the traffic that we want to go in to the tunnel
|
|
0:19:16
|
we are going to tell router1 and router3
|
|
0:19:18
|
to look for any GRE packets
|
|
0:19:21
|
that are going between
|
|
0:19:23
|
router1 and router3
|
|
0:19:28
|
so next lets go to router1 and 3
|
|
0:19:31
|
and we are going to configure a policy that is similar to what we had
|
|
0:19:35
|
before with the regular LAN-to-LAN VPN
|
|
0:19:39
|
so we could use some of the configuration we have before where we have the
|
|
0:19:43
|
Now, the crypto ISAKMP policy
|
|
0:19:45
|
we have the pre shared key between router1 and
|
|
0:19:48
|
router3
|
|
0:19:50
|
we have the transform set
|
|
0:19:52
|
the crypto map
|
|
0:19:54
|
and then the crypto map is applied on the interface
|
|
0:19:56
|
essentially all of this configuration is going to stay the same
|
|
0:20:01
|
With the exception of one thing here
|
|
0:20:03
|
the proxy access list that is defining
|
|
0:20:06
|
what traffic is going to go inside of the tunnel
|
|
0:20:10
|
and what this is going to change to
|
|
0:20:12
|
is instead of the actual IP packets
|
|
0:20:15
|
its going to be the GRE packets
|
|
0:20:18
|
that are coming from the tunnel end point of 1
|
|
0:20:23
|
going to the tunnel end point
|
|
0:20:25
|
of 3
|
|
0:20:26
|
So from 200.0.12.1 to 200.0.23.3
|
|
0:20:32
|
then on the other way around, from router3 back to 1
|
|
0:20:36
|
to essentially going to be the same thing except the
|
|
0:20:38
|
the source and the destination is swapped
|
|
0:20:43
|
So when we compare this to the regular LAN-to-LAN configuration
|
|
0:20:46
|
running GRE over IPSec is not that much more of a stretch
|
|
0:20:50
|
the only difference is that we are changing the proxy ACL or the proxy identities
|
|
0:20:54
|
to say its specifically
|
|
0:20:56
|
protocol 47
|
|
0:20:58
|
which is GRE
|
|
0:20:59
|
between the IPSec end points
|
|
0:21:02
|
So now lets enable this on router1
|
|
0:21:07
|
and the same thing on router3
|
|
0:21:19
|
we see that the EIGRP neighbour over the tunnel goes down
|
|
0:21:23
|
then shortly we should see the neighbour come back up
|
|
0:21:27
|
and if we look at router2, who is still debugging in the transit path
|
|
0:21:33
|
what we will now see that is different
|
|
0:21:36
|
and lets undebug here
|
|
0:21:38
|
is that packets that are going from the 1 to 3
|
|
0:21:44
|
and from 3 back to 1
|
|
0:21:47
|
these are now protocol
|
|
0:21:49
|
50 for ESP
|
|
0:21:51
|
as opposed to protocol 47 which was previously for GRE
|
|
0:21:58
|
So the inside the IPSec tunnel we still have what we previously had before
|
|
0:22:03
|
which was the GRE header
|
|
0:22:05
|
followed by the IP header and then what the actual payload was
|
|
0:22:08
|
where here these packets being exchanged back and forth, these are still the EIGRP keep alives, between the neighbours
|
|
0:22:15
|
and if we were now to
|
|
0:22:18
|
to do that same debug as before
|
|
0:22:22
|
we will see only protocol 50
|
|
0:22:24
|
as opposed to protocol 47
|
|
0:22:29
|
So lets go to switch2 again
|
|
0:22:31
|
and we will do this ping
|
|
0:22:34
|
if we look at the debug
|
|
0:22:37
|
from
|
|
0:22:38
|
router2's perspective, we want to see the packets from
|
|
0:22:41
|
1 to 3 and then returning
|
|
0:22:48
|
lets undebug now
|
|
0:22:50
|
if we look at the result of this
|
|
0:22:53
|
as compared to
|
|
0:22:55
|
the previous two versions
|
|
0:22:57
|
where now we have the ICMP over GRE over IPSec
|
|
0:23:03
|
and ESP is specifically is the transform
|
|
0:23:06
|
Notice that now the
|
|
0:23:09
|
the length is increased from 124
|
|
0:23:13
|
to 176
|
|
0:23:18
|
So what this essentially means is by adding that additional ESP header and the ESP trailer
|
|
0:23:23
|
we are now adding an additional 52 Bytes of overhead
|
|
0:23:28
|
from the GRE tunnel
|
|
0:23:31
|
which again is now 76 bytes more overhead than just the native ICMP flow
|
|
0:23:38
|
what we look at this, the 100 bytes, this is almost double
|
|
0:23:42
|
just with extra overhead
|
|
0:23:44
|
what we had previously
|
|
0:23:47
|
So the advantage of this type of design is that it allows us to run dynamic routing
|
|
0:23:53
|
and since we are running IPSec, it allows us to do encryption
|
|
0:23:57
|
but the disadvantage is that, we are adding in a lot
|
|
0:24:00
|
of additional overhead
|
|
0:24:01
|
because when we look back at that packet format
|
|
0:24:04
|
we have now not only
|
|
0:24:06
|
the originating
|
|
0:24:08
|
ICMP data
|
|
0:24:10
|
we have that additional
|
|
0:24:12
|
24 bytes of overhead
|
|
0:24:15
|
for the new GRE header
|
|
0:24:17
|
and now we have
|
|
0:24:18
|
52 bytes of overhead
|
|
0:24:20
|
for the new ip header
|
|
0:24:22
|
the new ESP header and the new ESP trailer
|
|
0:24:27
|
So again we had 100, we had 124
|
|
0:24:30
|
and we had
|
|
0:24:33
|
176
|
|
0:24:35
|
Now if we look this from the of perspective router1 and router3
|
|
0:24:40
|
router3, if we look at the how ip route EIGRP
|
|
0:24:43
|
from the end host perspective
|
|
0:24:45
|
they are not really going to notice the difference
|
|
0:24:47
|
in the transport here
|
|
0:24:50
|
like if I were to do a traceroute
|
|
0:24:52
|
from, actually lets say from router1, if we were to trace
|
|
0:24:56
|
to 17.16.4.4
|
|
0:25:00
|
from a routing point of view we are still going over the tunnel and
|
|
0:25:04
|
its not going to change any of the behaviour
|
|
0:25:07
|
whether we are going over
|
|
0:25:08
|
clear text GRE or we are going over IPSec
|
|
0:25:12
|
other than just the additional encapsulation overhead
|
|
0:25:18
|
now the other two variations for this configuration
|
|
0:25:21
|
the IPSec profile
|
|
0:25:23
|
and the virtual tunnel interfaces
|
|
0:25:26
|
the first portion of the IPSec profile
|
|
0:25:30
|
its going to simplify the crypto map configuration
|
|
0:25:33
|
specially when we have multiple channels
|
|
0:25:36
|
like in the case of a Dynamic multi-point VPN, with a multi-point GRE tunnel
|
|
0:25:41
|
and the VTI, the virtual tunnel interface
|
|
0:25:45
|
is going to lower the additional overhead
|
|
0:25:48
|
that we had to use
|
|
0:25:50
|
because what we are adding , the additional GRE header
|
|
0:25:53
|
in order to allow us to do dynamic routing
|
|
0:25:57
|
Now again the reason that we would do this in the design to begin with
|
|
0:26:01
|
is that for a regular IPSec tunnel
|
|
0:26:04
|
between router1 and router3
|
|
0:26:08
|
since there is no interface that is associated with the crypto-map
|
|
0:26:12
|
we cannot run dynamic routing over it
|
|
0:26:16
|
like if we were to go to OSPF and issue the network statement
|
|
0:26:19
|
there is no ip address that we can associate to enable OSPF on the interface
|
|
0:26:24
|
So thats what running the, thats what running the GRE tunnel
|
|
0:26:27
|
is solving for us
|
|
0:26:29
|
its giving us an interface with IP
|
|
0:26:31
|
that we can run IGP on
|
|
0:26:33
|
So we can dynamic routing but we can also get the encryption at the same time
|
|
0:26:39
|
Now lets say that we have multiple tunnels
|
|
0:26:42
|
may be we have a tunnel from 1 to 3
|
|
0:26:45
|
then we have a tunnel from
|
|
0:26:47
|
from 3 to 5, may be we have a tunnel from 3 to 6
|
|
0:26:51
|
and we are trying to do encryption
|
|
0:26:53
|
between the multiple sites over the GRE tunnels
|
|
0:26:57
|
this is where it quickly starts to get out of control
|
|
0:27:01
|
because we would need to go to router3
|
|
0:27:03
|
and configure multiple access list
|
|
0:27:06
|
that are going to say, look at the GRE traffic that is coming from 3
|
|
0:27:10
|
going to 5
|
|
0:27:12
|
and from 3 to 6, from 3 to 1
|
|
0:27:15
|
then on the way back from 5 to 3, from 6 to 3 and 1 to 3
|
|
0:27:20
|
when we try to scale this type of design
|
|
0:27:22
|
becomes very unmanageable
|
|
0:27:25
|
to do this type of
|
|
0:27:26
|
static GRE over IPSec configuration
|
|
0:27:30
|
So this is what the IPSec profiles
|
|
0:27:33
|
are going to help us to solve
|
|
0:27:36
|
Now normally this goes along with the
|
|
0:27:39
|
the DMVPN configuration
|
|
0:27:43
|
and if we take a look at the documentation
|
|
0:27:45
|
this would be under
|
|
0:27:47
|
products IOS
|
|
0:27:49
|
regular IOS
|
|
0:27:52
|
12.4T
|
|
0:27:54
|
configuration guides
|
|
0:27:57
|
then under security, this is going to be securing
|
|
0:28:00
|
the secured connectivity
|
|
0:28:03
|
So this is where all of our IPSec documentation is
|
|
0:28:07
|
Now the IPSec profile
|
|
0:28:10
|
is essentially going to be a replacement for the crypto-map
|
|
0:28:14
|
where the crypto map, when we are talking about
|
|
0:28:16
|
of the phase II negotiation
|
|
0:28:18
|
remember its mainly doing three things for us
|
|
0:28:21
|
its telling us who is the tunnel going to
|
|
0:28:24
|
which is the set peer command
|
|
0:28:26
|
what is going over the tunnel, which is the match address for the proxy ACL
|
|
0:28:31
|
and then how is it being treated
|
|
0:28:33
|
with the transform set, which is set transform set command
|
|
0:28:39
|
now in DMVPN
|
|
0:28:41
|
when we are running a multi-point GRE tunnel
|
|
0:28:45
|
and we will come back to this later in more detail and talk about DMVPN
|
|
0:28:49
|
but idea about the DMVPN
|
|
0:28:52
|
is that we are going to let our dynamic routing
|
|
0:28:55
|
tell us how exactly the encryption is supposed to happen
|
|
0:28:58
|
or specifically where the encryption is going to go between
|
|
0:29:02
|
So the IPSec profile
|
|
0:29:04
|
when we look at the configuration of this
|
|
0:29:07
|
in conjunction with a GRE tunnel
|
|
0:29:10
|
there is an IPSec profile on abstract IPSec
|
|
0:29:12
|
policy with a single configuration entity which can be referenced
|
|
0:29:17
|
where the functionality such as a GRE tunnel protection with a single line of configuration
|
|
0:29:25
|
by referencing the IPSec profile the user does not have to configure an entire crypto map configuration
|
|
0:29:33
|
so essentially what this means
|
|
0:29:36
|
is that if the IPSec profile
|
|
0:29:38
|
is applied on to the tunnel interface
|
|
0:29:41
|
for whatever destination you route out the tunnel
|
|
0:29:44
|
its automatically going to inherit that transform set
|
|
0:29:49
|
So the IPSec profile is like a crypto map
|
|
0:29:51
|
but you do not set the peer
|
|
0:29:54
|
and you do not match the address
|
|
0:29:56
|
and the configuration of it is very very straight forward
|
|
0:29:59
|
if you look at the bottom portion here of
|
|
0:30:02
|
the configuration example
|
|
0:30:05
|
DMVPN, lets say example of the
|
|
0:30:07
|
the hubs configuration
|
|
0:30:10
|
we have the
|
|
0:30:13
|
crypto ipsec profile
|
|
0:30:15
|
its named VPN prof
|
|
0:30:17
|
for VPN profile
|
|
0:30:19
|
says set the transform set
|
|
0:30:21
|
to TRANS TO, transform to is the name
|
|
0:30:24
|
where crypto ipsec transform set trans to says esp des and md5
|
|
0:30:31
|
so the profile is just getting the transform set
|
|
0:30:34
|
then from the tunnel interface
|
|
0:30:37
|
we are saying that the
|
|
0:30:38
|
cyrpto profile is applied
|
|
0:30:41
|
by saying tunnel protection ipsec
|
|
0:30:43
|
profile is the VPN profile
|
|
0:30:47
|
so essentially this one command here
|
|
0:30:51
|
on the tunnel interface
|
|
0:30:54
|
So they have interface tunnel 100
|
|
0:30:57
|
that is applying the profile
|
|
0:31:01
|
the profile is
|
|
0:31:03
|
calling the transform set
|
|
0:31:07
|
and the transform set is just a normal configuration, whats defining
|
|
0:31:11
|
what
|
|
0:31:12
|
protocols are you running inside of ESP
|
|
0:31:20
|
but the key point is that
|
|
0:31:21
|
this is simplifying what we previously had to define with the crypto map
|
|
0:31:25
|
to say, the crypto map has
|
|
0:31:27
|
multiple sequence numbers
|
|
0:31:29
|
that are defining individual peers
|
|
0:31:31
|
that have different policies for what the traffic is going to be encrypted
|
|
0:31:37
|
and then what is the particular transform set
|
|
0:31:41
|
Now outside of the realm of the DMVPN which is a multipoint GRE tunnel
|
|
0:31:46
|
we can take the same type of logic
|
|
0:31:48
|
and configure it on a point to point GRE tunnel
|
|
0:31:52
|
So what essentially means that
|
|
0:31:54
|
any destination that you route out the tunnel
|
|
0:31:57
|
is then going to inherit that transform set
|
|
0:32:01
|
because if we look at the configuration
|
|
0:32:03
|
of router1
|
|
0:32:04
|
and router3
|
|
0:32:06
|
on the tunnel interface
|
|
0:32:09
|
we already know what the tunnel destination is or what the tunnel peer is
|
|
0:32:14
|
so the tunnel destination being referenced here
|
|
0:32:17
|
and then the tunnel destination also being referenced in the crypto map
|
|
0:32:21
|
is kind of redundant
|
|
0:32:23
|
because the crypto map is only used to match the tunnel
|
|
0:32:26
|
the tunnel is already calling the destination
|
|
0:32:29
|
So we could change this around
|
|
0:32:31
|
to say at the interface level
|
|
0:32:34
|
lets not reference the crypto map here
|
|
0:32:40
|
So the crypto map is getting removed from the interface
|
|
0:32:43
|
and instead we are going to replace this with a crypto profile
|
|
0:32:48
|
we will say crypto ipsec profile
|
|
0:32:52
|
and I will call this
|
|
0:33:03
|
we will call this ipsec
|
|
0:33:05
|
_ [underscore] profile
|
|
0:33:08
|
from here this is going to call
|
|
0:33:10
|
the transform set
|
|
0:33:12
|
So we will set the transform set
|
|
0:33:16
|
the name we have already configured
|
|
0:33:18
|
is esp-3des-md5
|
|
0:33:24
|
then at the tunnel interface
|
|
0:33:27
|
we will say tunnel protection
|
|
0:33:30
|
is ipsec profile
|
|
0:33:33
|
and the name which is the ipsec profile
|
|
0:33:41
|
so lets look at the change here, lets say show run section
|
|
0:33:45
|
profile or tunnel
|
|
0:33:54
|
so we have the profile to find
|
|
0:33:57
|
we will do the same thing on router3 here
|
|
0:34:03
|
then on the tunnel
|
|
0:34:06
|
tunnel protection
|
|
0:34:10
|
Ipsec profile
|
|
0:34:12
|
is the profile name
|
|
0:34:16
|
then at the interface level which I previously had the crypto map applied on
|
|
0:34:21
|
we are going to
|
|
0:34:23
|
remove this, so no
|
|
0:34:26
|
no crypto map crypto map
|
|
0:34:31
|
Now the end result of this from the anyone in the transit path
|
|
0:34:35
|
or from the end host perspective
|
|
0:34:38
|
nothing is going to change, if we look at router2
|
|
0:34:40
|
and look at the
|
|
0:34:42
|
the debug here, we debug
|
|
0:34:46
|
debug ip packet detail 100
|
|
0:34:50
|
we still see that the size of the packets
|
|
0:34:53
|
from 1 to 3
|
|
0:34:55
|
which is, this is the ping that are going out of the tunnel
|
|
0:34:58
|
is still on 167 bytes
|
|
0:35:01
|
so its not changing
|
|
0:35:03
|
anything that we previously had
|
|
0:35:05
|
in the overhead
|
|
0:35:07
|
still the exact same packet format, where we have the ip header
|
|
0:35:11
|
the esp header
|
|
0:35:13
|
the new ip GRE header
|
|
0:35:16
|
the GRE header
|
|
0:35:18
|
the original IP header, and then the ICMP payload, followed by the ESP trailer
|
|
0:35:23
|
but what it is changing
|
|
0:35:26
|
if we look at the peers of IPSec
|
|
0:35:28
|
which in this case again are router1 and router3
|
|
0:35:32
|
and we look at the ipsec sa
|
|
0:35:35
|
which again is the phase II security association, if we look at the phase II ipsec sa
|
|
0:35:42
|
the difference
|
|
0:35:43
|
is that
|
|
0:35:44
|
the proxy identities or the proxy acl
|
|
0:35:49
|
does not list
|
|
0:35:50
|
what type of traffic is going
|
|
0:35:52
|
over the tunnel
|
|
0:35:55
|
where instead its essentially saying that any
|
|
0:35:57
|
protocol 47 traffic which is GRE
|
|
0:36:01
|
that is between 1 and 3
|
|
0:36:05
|
thats what going on to the
|
|
0:36:07
|
the crypto map, or more specifically the crypto profile
|
|
0:36:11
|
and the crypto profile
|
|
0:36:13
|
says that we are using 3DES and md5
|
|
0:36:20
|
So when we look at the configuration change
|
|
0:36:24
|
and if we were to compare
|
|
0:36:25
|
what we had
|
|
0:36:27
|
previously with the
|
|
0:36:35
|
access list that is calling GRE
|
|
0:36:39
|
the crypto map that is specifying the peer
|
|
0:36:41
|
of the transform set and the access list
|
|
0:36:54
|
and the crypto map being applied at the interface
|
|
0:36:57
|
this is being replaced with the
|
|
0:37:00
|
the crypto profile which is then calling the transform set
|
|
0:37:03
|
and then is applied directly on the tunnel interface
|
|
0:37:07
|
So its a little bit more straight forward configuration
|
|
0:37:11
|
because we don't need to account
|
|
0:37:12
|
for the tunnel destinations, nor do we need to account for
|
|
0:37:15
|
what is the traffic that is actually being encrypted
|
|
0:37:19
|
Now the disadvantage of the configuration on the right here
|
|
0:37:22
|
is that we lose the granular control
|
|
0:37:25
|
as to what we do or do not want to go in the tunnel
|
|
0:37:30
|
So any type of
|
|
0:37:32
|
tunnel design where you want to be very very specific as to what you do or do want to encrypted
|
|
0:37:38
|
lets say you want just tcp port 80 to be encrypted
|
|
0:37:41
|
you would generally need to use a
|
|
0:37:43
|
crypto map for that configuration
|
|
0:37:45
|
not the tunnel protection
|
|
0:37:47
|
or not what were
|
|
0:37:49
|
leading into the next configuration which is the Virtual Tunnel Interface or the VTI
|
|
0:37:55
|
Now the VTI is basically taking this configuration that we see on the right
|
|
0:37:59
|
and taking it step further
|
|
0:38:02
|
that says the
|
|
0:38:06
|
packet level overhead
|
|
0:38:09
|
that we have in this last example
|
|
0:38:12
|
is definitely overkill because now we have three ip headers
|
|
0:38:16
|
in the packet
|
|
0:38:18
|
we have the ip header for esp, we have the ip header GRE, and then we have the IP header for the original packet
|
|
0:38:25
|
Now if we could some how eliminate
|
|
0:38:27
|
the GRE overhead
|
|
0:38:29
|
but maintain the ability to do dynamic routing
|
|
0:38:33
|
then its going to solve the problem of
|
|
0:38:35
|
needing GRE to begin with
|
|
0:38:37
|
but still allow us to
|
|
0:38:39
|
to have a little bit more efficient
|
|
0:38:41
|
of the network transport
|
|
0:38:45
|
and this is what the VTI interface is designed to do for
|
|
0:38:50
|
we will see a little bit later that there are some cases that the VTI can also replace
|
|
0:38:54
|
an easyVPN configuration
|
|
0:38:57
|
or a crypto map that has an address of 0
|
|
0:39:01
|
which is similar to what we see here for DMVPND
|
|
0:39:04
|
the ISAKMP key that has an address of 0
|
|
0:39:08
|
or a dynamic crypto map, those can both be replaced by
|
|
0:39:11
|
the Virtual Tunnel Interface
|
|
0:39:14
|
Now documentation wise if we go back to secure connectivity
|
|
0:39:18
|
this is going to be under
|
|
0:39:20
|
configuring ipsec
|
|
0:39:23
|
security with ipsec and then the
|
|
0:39:27
|
ipsec virtual tunnel interface
|
|
0:39:31
|
now there is two different types, the type we are going to look at in this example is the static
|
|
0:39:35
|
Virtual Tunnel Interface, SVTI
|
|
0:39:38
|
where the Dynamic
|
|
0:39:39
|
Virtual Tunnel Interface or DVTI
|
|
0:39:41
|
this is the replacement for the dynamic crypto map
|
|
0:39:45
|
top one is the replacement for the
|
|
0:39:48
|
the static crypto map over a GRE tunnel
|
|
0:39:52
|
Now if we look at the configuration example for this
|
|
0:39:56
|
and ideally ofcourse you would want to read through the rest of the documents to figure out what are some of the caveats
|
|
0:40:01
|
but if we look at just the configuration example
|
|
0:40:05
|
the difference between what we have now with the GRE
|
|
0:40:09
|
and the crypto profile
|
|
0:40:13
|
versus the virtual tunnel interface
|
|
0:40:16
|
is that the tunnel mode
|
|
0:40:18
|
changes from GRE IPv4
|
|
0:40:22
|
to IPSec IPv4
|
|
0:40:26
|
and essentially what this is going to do
|
|
0:40:29
|
is revert us
|
|
0:40:31
|
to a design where, I am going to run out of room here, lets see, where we have the ip header
|
|
0:40:37
|
followed by the ESP header
|
|
0:40:40
|
followed by the original ip packet
|
|
0:40:44
|
the ICMP packet and then the actual payload
|
|
0:40:48
|
so we are going to be able to cut out
|
|
0:40:50
|
the additional 24 bytes of the GRE overhead
|
|
0:40:55
|
its going to look like a normal ipsec tunnel
|
|
0:40:58
|
but we are also going to be able to run a dynamic routing overhead at the same time
|
|
0:41:03
|
and this is the main advantage of using the VTI interface versus the crypto maps
|
|
0:41:08
|
that we have an interface that has an ip address
|
|
0:41:11
|
which means we can run normal routing features
|
|
0:41:14
|
in other normal interface feature that
|
|
0:41:19
|
as opposed to be associated with the crypto config
|
|
0:41:24
|
So in this example here
|
|
0:41:27
|
lets look at the full configuration of router3 and router1 first, if we show run
|
|
0:41:31
|
section crypto
|
|
0:41:36
|
or interface
|
|
0:41:39
|
say interface
|
|
0:42:23
|
so this configuration on the right, this is showing us the
|
|
0:42:27
|
IPSec over GRE
|
|
0:42:30
|
with the crypto IPSec profile
|
|
0:42:34
|
Now , the only change we are going to add here
|
|
0:42:37
|
is that the tunnel mode
|
|
0:42:41
|
the tunnel mode is going to change to ipsec
|
|
0:42:44
|
ipv4
|
|
0:42:46
|
and we need to do this on both router
|
|
0:42:48
|
1 and on router3
|
|
0:42:55
|
So tunnel mode is now ipsec ipv4
|
|
0:43:03
|
we should see that the eigrp neighbours are going to go down and then come back
|
|
0:43:08
|
because we need to rekey the tunnel
|
|
0:43:16
|
from the end host perspective
|
|
0:43:18
|
its not going to change in either transport
|
|
0:43:21
|
but if we were to now go to router2 and look at the debug
|
|
0:43:26
|
the packets that are going between router1
|
|
0:43:29
|
and router3
|
|
0:44:05
|
we see now have
|
|
0:44:08
|
24 bytes less of overhead
|
|
0:44:10
|
So this last one, this is the
|
|
0:44:13
|
ICMP over
|
|
0:44:15
|
the IPSec VTI
|
|
0:44:21
|
Now ofcourse the native ICMP flow without the additional encryption overhead, is going to be the
|
|
0:44:26
|
the less overhead of all of these
|
|
0:44:28
|
but then we have the
|
|
0:44:30
|
the GRE tunnel which is adding an additional 24 bytes
|
|
0:44:34
|
but this one is still clear text
|
|
0:44:37
|
if we were to run this over ipsec
|
|
0:44:40
|
we see its jumping up to 176
|
|
0:44:43
|
but then by replacing the GRE header with just normal ESP
|
|
0:44:48
|
we are saving the additional
|
|
0:44:49
|
24 bytes of overhead
|
|
0:44:52
|
so kind of in the middle there between just the regular GRE tunnel
|
|
0:44:56
|
and then the GRE over the ESP
|
|
0:44:59
|
but when you think at this from a large scale point of view
|
|
0:45:02
|
lets say that over your gige connection to your internet
|
|
0:45:07
|
then an additional 24 bytes of overhead on an individual packet basis
|
|
0:45:11
|
is really going to add up over
|
|
0:45:14
|
a long term average
|
|
0:45:17
|
So configuration wise there is really not much that of a difference between the
|
|
0:45:21
|
second solution which was the
|
|
0:45:23
|
the IPSec profile
|
|
0:45:25
|
over the GRE tunnel
|
|
0:45:27
|
versus this VTI
|
|
0:45:30
|
where when we look at the show run interface
|
|
0:45:32
|
tunnel 0 on router1
|
|
0:45:36
|
it essentially just this one extra command thats changing the mode
|
|
0:45:40
|
if we look at the show crypto ipsec sa
|
|
0:45:50
|
another change here
|
|
0:45:53
|
is that the proxy acl now says 0 to 0
|
|
0:45:58
|
so its essentially anything that points at tunnel 0
|
|
0:46:02
|
thats automatically going to
|
|
0:46:04
|
hit the transform set
|
|
0:46:07
|
with the transform set here says
|
|
0:46:10
|
ESP 3DES and ESP MD5
|
|
0:46:14
|
but what none of these solutions change
|
|
0:46:18
|
is whats going on in the phase I negotiation
|
|
0:46:21
|
So when we look at the show crypto ISAKMP SA
|
|
0:46:25
|
we should still have the tunnel
|
|
0:46:27
|
thats in QM_IDLE
|
|
0:46:29
|
which means that we agreed on the authentication
|
|
0:46:32
|
the encryption, the hash algorithm
|
|
0:46:34
|
the diffy halman group
|
|
0:46:35
|
and the authentication was successful
|
|
0:46:37
|
before we can move on to this phase II negotiation
|
