|
0:00:13
|
In our next section we are going to look at the configuration of the LAN-to-LAN VPNs
|
|
0:00:18
|
from IOS to IOS
|
|
0:00:21
|
we will talk about some the basic configurations of the ISAKMP policies
|
|
0:00:25
|
the crypto maps
|
|
0:00:26
|
then look at some of the basic show commands for verification
|
|
0:00:30
|
and testing of the IPsec tunnels
|
|
0:00:34
|
Now as we talked about before IPSec
|
|
0:00:36
|
configuration and the
|
|
0:00:38
|
actual establishment of the tunnels is broken into two different phases of negotiations
|
|
0:00:42
|
we have phase I for the ISAKMP security association
|
|
0:00:46
|
and phase II for the IPSec SA
|
|
0:00:50
|
So configuration wise
|
|
0:00:51
|
likewise we are going to break this into these two logical steps
|
|
0:00:54
|
where first step is to define the phase I ISAKMP policy
|
|
0:00:59
|
inside of the policy there are four main attributes that we need to make sure thet the
|
|
0:01:03
|
peers are going to agree on
|
|
0:01:05
|
first of them is the authentication
|
|
0:01:08
|
So are we doing simple pre shared authentication
|
|
0:01:10
|
where the peers both know the password is cisco for this particular tunnel
|
|
0:01:15
|
or we doing the
|
|
0:01:17
|
RSA signatures where we are using a certificate authority server
|
|
0:01:21
|
in order to get both a public key and a private key
|
|
0:01:24
|
and then do authentication based on that
|
|
0:01:27
|
for a first example we are going to go just through this pre shared keys
|
|
0:01:30
|
then we will look at doing the certificate authority, not only on the IOS
|
|
0:01:34
|
but also on the ASA as well
|
|
0:01:38
|
next we have our encryption algorithm which is generally DES, 3DES or AES
|
|
0:01:44
|
and in the case fo AES we would also need to make sure that the
|
|
0:01:47
|
encryption length matches
|
|
0:01:50
|
as we can use different bit length, like 128 bit or 256 bit with AES
|
|
0:01:56
|
the hash algorithm, either md5 or SHA
|
|
0:02:00
|
and the Diffy Halman group which is generally 1, 2 or 5
|
|
0:02:05
|
or again the DH group is going to control
|
|
0:02:08
|
how large of a number can we generate
|
|
0:02:11
|
that is going to ultimately be used to generate the encryption and decryption key
|
|
0:02:16
|
So if we were to use a Diffy Halman group number 5
|
|
0:02:19
|
it means that we have
|
|
0:02:21
|
a more randomness to the number, as opposed to using a
|
|
0:02:25
|
Diffy Halman group of 1 or 2
|
|
0:02:27
|
but as long as the ISAKMP peers
|
|
0:02:29
|
agree on that the DH group is, what the hash, encryption and the authentication
|
|
0:02:34
|
this is really what we care about
|
|
0:02:37
|
Now one were defining this, first we are going to look at it
|
|
0:02:39
|
by using an ISAKMP policy
|
|
0:02:42
|
we will talk about some more advanced examples later like using ISAKMP profiles
|
|
0:02:46
|
and using IPSec profiles
|
|
0:02:48
|
but for the first example with the IPSec
|
|
0:02:51
|
a policy, excuse me, the IPSec policies
|
|
0:02:54
|
it works like a route map
|
|
0:02:55
|
where it is going to be processed top down until a match occurs
|
|
0:03:00
|
So this means that you are more preffered
|
|
0:03:03
|
methods of authentication, encryption, hashing and diffy halman group
|
|
0:03:07
|
those should be higher up in the ISAKMP policy
|
|
0:03:11
|
where typically in most examples you will see that
|
|
0:03:14
|
they start with number 10 and then
|
|
0:03:16
|
increment the policy numbers by 10
|
|
0:03:18
|
but its any line number that you choose, I could have policies numbered 1,2,3,4,5
|
|
0:03:24
|
the reason that we use line number 10
|
|
0:03:26
|
typically by default, is that if I want to add something more specific later
|
|
0:03:31
|
I could add a new number 5 or a number 2,3,4 etc
|
|
0:03:37
|
So once we agree on both sides whats the phase I ISAKMP policy
|
|
0:03:41
|
then we need to decide what is going to be the phase II IPSec policy
|
|
0:03:46
|
Now ultimately this is going to control where is the tunnel going
|
|
0:03:51
|
what type of traffic is going into the tunnel
|
|
0:03:53
|
and how is it going to be processed
|
|
0:03:55
|
So these three steps, the who, what and the how, this is what we need to decide with the phase II policy
|
|
0:04:02
|
So the who of this
|
|
0:04:04
|
is going to be controlled by defining the peer address
|
|
0:04:07
|
So where is the tunnel actually terminating on
|
|
0:04:10
|
the what is going to be controlled by the proxy access list with the proxy identities
|
|
0:04:15
|
this controls what traffic whether it be all IP traffic
|
|
0:04:19
|
or IP traffic from a certain subnet going to a specific subnet
|
|
0:04:24
|
or we could even get as granular as to say just tcp port 80
|
|
0:04:29
|
is going to go into this tunnel
|
|
0:04:30
|
So whatever we defined as the proxy ACL for the phase II policy
|
|
0:04:34
|
that controls what traffic goes in to the tunnel
|
|
0:04:38
|
then we need to defined how is the traffic going to be treated
|
|
0:04:41
|
this is what the IPSec transform set defines
|
|
0:04:45
|
So is it going to use AH or ESP
|
|
0:04:48
|
if its using, its using md5 or SHA
|
|
0:04:52
|
if its using ESP is it using likewise md5 or SHA
|
|
0:04:56
|
but is it also using DES, 3DES etc
|
|
0:05:01
|
Now once we define the IPSec policy
|
|
0:05:05
|
the configuration is going to be tied together with a crypto map
|
|
0:05:09
|
Now we will look at some other examples later when we look at some of the newer
|
|
0:05:13
|
configurations for this
|
|
0:05:14
|
by doing IPSec
|
|
0:05:16
|
profiles and with the VTI interfaces, the Virtual Tunnel Interfaces
|
|
0:05:21
|
but from the traditional configuration
|
|
0:05:23
|
what you could kind of consider the legacy configuration now
|
|
0:05:26
|
the crypto map is going to tie all of these together
|
|
0:05:29
|
and then be bound to the interface
|
|
0:05:33
|
Now the crypto map itself, we could think of this
|
|
0:05:35
|
as a type of data plane filter
|
|
0:05:38
|
that is going to trigger and interupt
|
|
0:05:41
|
that is ultimately going to initiate the ISAKMP process or the ISAKMP session
|
|
0:05:46
|
So traffic that is matched by an access list
|
|
0:05:49
|
were more specifically the ACL that we are using for the proxy identity
|
|
0:05:54
|
of IPSec phase II
|
|
0:05:56
|
is going to control what type of traffic is going to trigger
|
|
0:05:59
|
the crypto map to start the IKE session
|
|
0:06:03
|
So this means that if I were defined access list 100
|
|
0:06:07
|
that says match ip traffic from
|
|
0:06:09
|
segment A going to segment B
|
|
0:06:12
|
then apply the crypto map to the interface
|
|
0:06:14
|
that crypto map is going to launch for any ip traffic coming from segement A going to segment B
|
|
0:06:19
|
and if the traffic matches
|
|
0:06:22
|
then IKE session is going to initiate
|
|
0:06:25
|
So you can think of this, its kind of like a dial on demand session
|
|
0:06:28
|
where the tunnel is not automatically going to be up
|
|
0:06:31
|
unless this interesting traffic, or this traffic match by the proxy ACL
|
|
0:06:36
|
is actually going accross the interface
|
|
0:06:40
|
Now the application of the cryptomap
|
|
0:06:43
|
is either going to go to the physical interface or the sub interface where we have our IP version 4 address assigned
|
|
0:06:50
|
or in the case of you are doing IPv6
|
|
0:06:52
|
IPSec now likewise will be where the IPv6 address is
|
|
0:06:56
|
but the key point here
|
|
0:06:57
|
being that we would not apply the crypto map to a tunnel interface
|
|
0:07:02
|
there is some legacy configurations from older versions of IOS 12
|
|
0:07:07
|
.0 and 12.1
|
|
0:07:09
|
where was required to apply cryptomaps to those type of logical interfaces
|
|
0:07:13
|
like a GRE tunnel
|
|
0:07:15
|
but in the current IOS version that is not required
|
|
0:07:18
|
cryto map is going to be whatever is the outgoing interface
|
|
0:07:22
|
that has your IP address assigned
|
|
0:07:25
|
whether this be a ethernet interface or a serial sub interface
|
|
0:07:30
|
or an ATM sub interface
|
|
0:07:33
|
its going to be whatever the outgoing interface that has the IP address assigned
|
|
0:07:37
|
this likewise implies that the cryptomap is going to be triggered by the outbound traffic
|
|
0:07:43
|
not triggered by the incoming traffic from the other side
|
|
0:07:48
|
Now when we actually initiate the tunnel
|
|
0:07:51
|
the address that the router uses, or in the case of the ASA
|
|
0:07:55
|
its going to be based on the IP address that is assigned on the interface that has the cryptomap on
|
|
0:08:01
|
So if I were to use my fastethernet0/0
|
|
0:08:05
|
as the interface with the crypto map is applied
|
|
0:08:08
|
means when I start the tunnel
|
|
0:08:09
|
the actual IP packet that is used for the IKE session
|
|
0:08:14
|
then the IP packet that is used for the ESP traffic
|
|
0:08:17
|
or the AH traffic
|
|
0:08:19
|
its going to use that was the only interface that was the source
|
|
0:08:24
|
so similar to how
|
|
0:08:25
|
a ping works or a telnet works on the router
|
|
0:08:29
|
where locally generated traffic
|
|
0:08:31
|
is going to use the address that is based on the outgoing interface on the routing table
|
|
0:08:36
|
Now we can't change this with the crypto map local address command
|
|
0:08:41
|
and this would typically be used
|
|
0:08:43
|
if we were trying to bind the crypto map, lets say to like a loopback address
|
|
0:08:47
|
where may be between the two peers, I have multiple physical paths in the network
|
|
0:08:52
|
and I want to make sure that my IPSec tunnel stays up
|
|
0:08:55
|
as long as one of those paths are available
|
|
0:08:59
|
So depending on what the address you are setting as the peer
|
|
0:09:02
|
that is going to have to agree on what is the tunnel source
|
|
0:09:06
|
for the IPSec tunnel based on the crypto map
|
|
0:09:11
|
these do not agree with each other
|
|
0:09:12
|
then the ISAKMP session is not going to initiate
|
|
0:09:17
|
Now another important point here
|
|
0:09:20
|
is the order of operations
|
|
0:09:22
|
that the crypto map is processed in
|
|
0:09:24
|
and specifically how this is going to interact
|
|
0:09:27
|
with the Network Address Translation or the NAT process
|
|
0:09:31
|
and the key point being that the encyption applies after
|
|
0:09:35
|
the Network Address Translation has occured
|
|
0:09:38
|
So this means that if you have your router on the edge of your network, lets say connecting to the internet
|
|
0:09:43
|
and inside your network you have private addresses
|
|
0:09:46
|
that you are translating to a global pool
|
|
0:09:50
|
as they are going out to the public network
|
|
0:09:52
|
So may be I have the 192.168. address on inside of my network
|
|
0:09:57
|
I am translating to whatever public pool my ISP has assigned
|
|
0:10:01
|
but if I am also trying to do an IPSec VPN from that router
|
|
0:10:06
|
it means that as I sent the traffic out
|
|
0:10:09
|
if the NAT translation occurs
|
|
0:10:13
|
then that traffic is not going to properly hit the IPSec tunnel
|
|
0:10:18
|
So we will see cases when
|
|
0:10:20
|
plus Network Address Translation at the same time
|
|
0:10:23
|
you will need to do a NAT exemption
|
|
0:10:26
|
and we talked about NAT exemptions on the ASA before
|
|
0:10:30
|
we will look at the NAT exemptions on the IOS
|
|
0:10:32
|
that are specifically related to dealing with the IPSec LAN to LAN traffic
|
|
0:10:37
|
and this will also be true when we get into the remote acces configurations
|
|
0:10:41
|
of the easyVPN server and the easyVPN client
|
|
0:10:47
|
Now once we get through our basic configuration of the tunnel
|
|
0:10:51
|
we need to make sure that we know what are the different verification steps
|
|
0:10:55
|
and what are the different troubleshooting steps that we can go through if there is a problem
|
|
0:10:59
|
with the actual operation of the tunnel
|
|
0:11:02
|
and the reason why this is so important
|
|
0:11:04
|
is that there are so many ways that you can make a minor mistake in the configuration
|
|
0:11:09
|
and 99% of them are going to break the tunnel completely
|
|
0:11:13
|
so generally with IPSec, either it works a 100%
|
|
0:11:16
|
or it works 0%
|
|
0:11:18
|
there is no kind of middle of the row, that the tunnel is working sometimes but not all the time
|
|
0:11:24
|
Generally they are 100% working or 100% broken
|
|
0:11:27
|
Now if it is broken
|
|
0:11:29
|
thats why we need to be able to figure out what are the individual verification steps that we can do
|
|
0:11:34
|
and what are the troubleshooting steps we can do
|
|
0:11:37
|
to figure out where exactly is the problem
|
|
0:11:40
|
and the reason that this is such a big issue
|
|
0:11:42
|
as that there are so many possible ways that the problem can manifest
|
|
0:11:46
|
we need to be able to break them down into individual step by step processes
|
|
0:11:52
|
Now for the first examples we are going to look at 100% working configurations
|
|
0:11:56
|
I am not going to previously make any errors in the config
|
|
0:11:59
|
but we will come back in the later sections and look at
|
|
0:12:02
|
configurations that are almost working
|
|
0:12:04
|
May be there is one or two errors
|
|
0:12:06
|
and they will go through some of the show commands, debug commands to see
|
|
0:12:10
|
How can we look at the result of these
|
|
0:12:13
|
and then work backwards from there to figure out
|
|
0:12:15
|
what do I need to change in order to get this to work
|
|
0:12:18
|
and the reason this is so important
|
|
0:12:20
|
is that the IPSec configurations can get very very large
|
|
0:12:24
|
where just looking at the show run output
|
|
0:12:27
|
a lot of times is not going to help you to troubleshoot what exactly wrong with the trouble
|
|
0:12:29
|
whats exactly wrong with the tunnel
|
|
0:12:32
|
or may be it will work but you might spend
|
|
0:12:34
|
two to three times more time, trying to debug the configuration
|
|
0:12:37
|
as opposed to looking at the actual results of it
|
|
0:12:42
|
Now just like I mentioned in the configuration
|
|
0:12:45
|
that we separated into two different steps
|
|
0:12:47
|
the phase I negotiation and the phase II negotiation
|
|
0:12:50
|
same would be true of the verification and the troubleshooting
|
|
0:12:54
|
So we would want to know first, how do we know that the ISAKMP SA is working
|
|
0:12:59
|
first is going to with the show crypto isakmp sa command
|
|
0:13:03
|
what we want to see here is that it says that the state is queue and idle
|
|
0:13:07
|
which means quick mode idle
|
|
0:13:10
|
or in other words we have finished either our main mode or aggressive mode negotiation
|
|
0:13:15
|
if we moved into the quick mode negotiation
|
|
0:13:18
|
which is used for the phase II IPSec SA
|
|
0:13:22
|
So if the tunnel says queue and idle when we show crypto isakmp sa
|
|
0:13:26
|
we can guarantee that there is no problem
|
|
0:13:29
|
in phase I negotiation
|
|
0:13:32
|
Now if we do not seek quick
|
|
0:13:34
|
quick mode idle or QM idle
|
|
0:13:36
|
this is where we need to look into the more
|
|
0:13:38
|
details of what exactly going on with the ISAKMP SA
|
|
0:13:42
|
Now we could see this with the debug crypto ISAKMP command
|
|
0:13:46
|
this is going to show the
|
|
0:13:47
|
the exact steps of those six messages we used for the
|
|
0:13:51
|
the main mode or the three messages we used for the aggressive mode
|
|
0:13:56
|
to exchange the ISAKMP policies
|
|
0:13:59
|
through the proposal process
|
|
0:14:02
|
to make sure do the peers actually agree and all of these individual attributes
|
|
0:14:06
|
So some of the things you would want to look at
|
|
0:14:09
|
is the the authentication working
|
|
0:14:12
|
so for using pre shared keys
|
|
0:14:15
|
do they agree that password is the same over the using the correct peer addresses
|
|
0:14:21
|
if we are using certificate authority, are we properly enrolled
|
|
0:14:24
|
with the CA, do we have our certificate granted
|
|
0:14:28
|
is it in current valid state
|
|
0:14:31
|
an is it not in the certificate revokation list with the CRO
|
|
0:14:37
|
we would also need to make sure the other IKE
|
|
0:14:40
|
security association or the ISAKMP SA
|
|
0:14:43
|
a tribute to match, so things like the hash algorithm
|
|
0:14:47
|
the diffy halman group, the encryption
|
|
0:14:50
|
the debug cryto ISAKMP is going to tell you
|
|
0:14:53
|
whether the policy is acceptable
|
|
0:14:55
|
whether the policy is not acceptable
|
|
0:14:58
|
and generally its going to say specifically why
|
|
0:15:01
|
a policy is or is not accepted
|
|
0:15:04
|
So if I rejected, I may say, I am rejecting because
|
|
0:15:07
|
the hash algorithm is md5, and the one I am looking for is SHA
|
|
0:15:13
|
Now if we look at the show crypto ISAKMP SA
|
|
0:15:17
|
and we see that the phase I negotiation is correct
|
|
0:15:21
|
because we see QM_IDLE
|
|
0:15:23
|
then we know there is a problem in
|
|
0:15:25
|
potentially the phase II negotiation
|
|
0:15:28
|
and we could see this with the show crypto ipsec sa
|
|
0:15:32
|
this is going to show us, is the tunnel actually up
|
|
0:15:35
|
and our packets getting encrypted and decrypted
|
|
0:15:38
|
our packets getting encapsulated and decapsulated
|
|
0:15:41
|
and we would need to check this at the both ends of the tunnel
|
|
0:15:46
|
we will see that there are cases
|
|
0:15:49
|
with the tunnel negotiation with both phase I and phase II is correct
|
|
0:15:54
|
but then the actual traffic does not flow
|
|
0:15:56
|
because ther is something wrong in the data plane
|
|
0:16:00
|
where it could be, I don't have a route to the destination
|
|
0:16:03
|
or there is an order of operation problem with the network address translation process
|
|
0:16:07
|
or someone is filtering
|
|
0:16:09
|
IP protocol number 51 for ESP in the transit path
|
|
0:16:13
|
where in the case of AA to will be for protocol
|
|
0:16:16
|
number 50, actually excuse me, the other way round
|
|
0:16:21
|
But we can see based on the show output
|
|
0:16:24
|
what are the packets are being encrypted
|
|
0:16:27
|
which means that on the other side they should be decrypted
|
|
0:16:30
|
if my packets are getting encapsulated
|
|
0:16:33
|
but they are not getting decapsulated on your side or on the other side
|
|
0:16:37
|
means that there is something wrong in the transit path of the actual data plane
|
|
0:16:42
|
one potential issue here
|
|
0:16:44
|
could be at the access list or not, near images each other
|
|
0:16:48
|
where on one side of the tunnel if I am trying to encrypt traffic
|
|
0:16:51
|
from segment A to B
|
|
0:16:54
|
my acl needs to say, the source is A and the destination is B
|
|
0:16:57
|
where as on the other side
|
|
0:16:59
|
they would say that the source is B and the destination is A
|
|
0:17:03
|
So one of the very common mistakes here is that the
|
|
0:17:06
|
problem with the proxy acls
|
|
0:17:09
|
we could see this when we look at the debug crypto IPSec
|
|
0:17:11
|
thats going to show the actual negotiation of the
|
|
0:17:14
|
the IPSec SA
|
|
0:17:18
|
Now we will see for both of these the debug crypto ISAKMP
|
|
0:17:22
|
and the debug crypto IPSec,
|
|
0:17:23
|
they are very very noisy debugs
|
|
0:17:26
|
and you have to already know exactly what youare looking for
|
|
0:17:29
|
otherwise it could be very very confusing to try to sort through
|
|
0:17:32
|
exactly whats going on in that output
|
|
0:17:37
|
Now in our particular case here
|
|
0:17:40
|
for this first example we are going to be doing
|
|
0:17:42
|
a LAN-to-LAN VPN
|
|
0:17:45
|
between router1 and router3
|
|
0:17:49
|
where the goal of this
|
|
0:17:51
|
is that I want to encrypt traffic that is coming from
|
|
0:17:54
|
these two segments behind router1
|
|
0:17:57
|
essentially anything that starts 192.168.0.0/16
|
|
0:18:05
|
and is going to the other private
|
|
0:18:08
|
addressing segment behind router3 that is the 172.16.0.0/16
|
|
0:18:17
|
So before we actually configure all of the parameters of the tunnel
|
|
0:18:21
|
we need to get to some of the basic peices of information
|
|
0:18:24
|
So we configure out what are the
|
|
0:18:26
|
the attributes we are going to be using for the phase I policy
|
|
0:18:29
|
what are the attributes we are going to be use for the phase II policy
|
|
0:18:33
|
Now at this point I already know a couple of pieces of information
|
|
0:18:37
|
I know who the tunnel is going to between
|
|
0:18:40
|
which is router1 and router3
|
|
0:18:43
|
that tells me the who portion
|
|
0:18:47
|
of the phase II policy
|
|
0:18:50
|
So who are the peer addresses is going to be
|
|
0:18:53
|
they are going to be this outside interface address of router3
|
|
0:18:56
|
and this outside interface address of router1
|
|
0:19:00
|
Now it also know what I want to go into the tunnel
|
|
0:19:04
|
I want the traffic that is coming from 192.168.0.0/16
|
|
0:19:10
|
going to 172.160.0.0/16
|
|
0:19:14
|
and I want the return traffic going the other way
|
|
0:19:17
|
Now this means when I define the
|
|
0:19:19
|
proxy identities or the proxy acls
|
|
0:19:22
|
on router1, I would want to match traffic with a source of 192.168
|
|
0:19:27
|
and a destination of 172.16
|
|
0:19:30
|
then from router 3 back to 1 its going to be opposite
|
|
0:19:32
|
the source would be 172 .16
|
|
0:19:35
|
destination is going to be 192.168
|
|
0:19:39
|
now for the rest of the attributes
|
|
0:19:42
|
is fairly arbitrary from the configuration exactly how I do this
|
|
0:19:46
|
there is not going to be much of a difference syntax wise
|
|
0:19:48
|
if I choose the encryption to be
|
|
0:19:51
|
single DES or I choose the encryption to be 3DES
|
|
0:19:53
|
or if I choose the hash algorithm as md5 versus SHA
|
|
0:19:58
|
its more the understand what is the basic methodology
|
|
0:20:02
|
that we are going to be apply onto the tunnels
|
|
0:20:04
|
because we will see whether we are doing this on the IOS
|
|
0:20:07
|
or the ASA, or doing LAN to LAN or remote access
|
|
0:20:11
|
or some of the other advanced application like DMVPN or get VPN
|
|
0:20:16
|
a lot of the basic structure
|
|
0:20:18
|
of the configuration is going to be similar
|
|
0:20:23
|
Now additionally since we are doing
|
|
0:20:25
|
two configurations, one on router1 and one on router3
|
|
0:20:29
|
that are nearly identical
|
|
0:20:31
|
the method that I like to use for these IPSec tunnels
|
|
0:20:34
|
is to look at both of the configurations side by side
|
|
0:20:37
|
to make sure that I am not leaving out an individual attribute
|
|
0:20:42
|
Now within in the scope of the
|
|
0:20:44
|
CCIE lab exam or any other configuration you are doing thats related to this
|
|
0:20:48
|
you could simply take two of your text editor windows
|
|
0:20:51
|
like in this case notepad and just put them side by side
|
|
0:20:54
|
where we will have the one on the left
|
|
0:20:56
|
is going to be for router1's configuration
|
|
0:20:58
|
the one on the right is going to be for router3's configuration
|
|
0:21:03
|
So we could do our configuration
|
|
0:21:04
|
live on the command line of router1
|
|
0:21:07
|
look at the result of this,
|
|
0:21:09
|
then change it around for router3's perpective
|
|
0:21:12
|
and its less likely that we are going to leave out an individual step
|
|
0:21:16
|
in the configuration
|
|
0:21:21
|
So lets look at the command line now, we will start on router1
|
|
0:21:24
|
and before actually get into any of the IPsec configuration
|
|
0:21:29
|
there is a couple of different basic things I want to verify in the topology
|
|
0:21:33
|
first and foremost
|
|
0:21:34
|
is, Do router1 and router3 has basic IP reachability to each other ?
|
|
0:21:39
|
where router3
|
|
0:21:41
|
is going to be sending the tunnel from the address 200.0.23.23
|
|
0:21:47
|
and router1 is sending it
|
|
0:21:49
|
from 200.0.12.1
|
|
0:21:55
|
So I just want to make sure, Can router 1 and router3 ping each other
|
|
0:21:58
|
if the ping is successful
|
|
0:22:00
|
then its very likely that I have basic IP transport between the neighbours
|
|
0:22:05
|
Now that doesn't necessarily means that I have UDP
|
|
0:22:07
|
port 500
|
|
0:22:09
|
for the ISAKMP tunnel
|
|
0:22:11
|
and then I have either
|
|
0:22:13
|
protocol 50 or 51 reachability
|
|
0:22:16
|
for the actual IPSec SA
|
|
0:22:19
|
but it is a good start so I can just verify that
|
|
0:22:22
|
its more likely that the tunnel is going to work that not at this point
|
|
0:22:28
|
So next lets go to router1
|
|
0:22:30
|
and we are going to define the first portion that the neighbours need to agree on
|
|
0:22:34
|
which is the ISAKMP SA
|
|
0:22:38
|
and we are going to do this with the crypto isakmp policy command
|
|
0:22:44
|
So we are going to give it a number, I will say we will start with line number 10
|
|
0:22:48
|
and out of the policy again
|
|
0:22:51
|
four attributes
|
|
0:22:53
|
which are what are the authentication
|
|
0:22:55
|
what is the encryption, what is Diffy Halman group and what is the
|
|
0:23:00
|
the Hash vlae
|
|
0:23:02
|
now we can also specify the security association lifetime
|
|
0:23:07
|
this would control how often do I need to re key phase I
|
|
0:23:13
|
but as I mentioned before this value is negotiated down to the lower of the two
|
|
0:23:19
|
So for some reason router1 and router3 do not agree on the life time
|
|
0:23:22
|
shouldn't really matter because they are going to choose whatever the lowest one
|
|
0:23:27
|
Now from a practical point of view
|
|
0:23:30
|
probably what I would not want to do
|
|
0:23:32
|
is say something here like lifetime 60 seconds
|
|
0:23:35
|
while trying to rekey the tunnel every minute
|
|
0:23:38
|
because it does require
|
|
0:23:40
|
a good amount of overhead for the router to actually run the phase I negotiation
|
|
0:23:45
|
and if there are a lot of tunnels
|
|
0:23:47
|
I could end up having too high of a CPU utilization
|
|
0:23:50
|
and ultimately start dropping packets in the data plane
|
|
0:23:54
|
if I am spending too much time recalculating this control plane information
|
|
0:23:59
|
So for the life time value, I will just leave this as the default
|
|
0:24:02
|
what I am mainly concerned with is
|
|
0:24:04
|
whats the authentication
|
|
0:24:06
|
so we are doing pre shared keys
|
|
0:24:09
|
are we doing RSA signatures
|
|
0:24:12
|
which would be for a certificate authority
|
|
0:24:14
|
or the RSA encryption
|
|
0:24:17
|
which is the RSA encrypted
|
|
0:24:19
|
or basically the static
|
|
0:24:21
|
RSA keys between the peers
|
|
0:24:25
|
Now as I mentioned before
|
|
0:24:27
|
most of the platforms do not support this second option
|
|
0:24:31
|
this is an IOS specific implementation
|
|
0:24:34
|
most of the time you are going to be either be using pre shared keys
|
|
0:24:37
|
or you are going to be using the
|
|
0:24:38
|
the certificate authority support, the RSA signatures
|
|
0:24:43
|
So for our first example here we are just going to be using the pre shared key
|
|
0:24:48
|
So I will say authentication is pre shared
|
|
0:24:51
|
the encryption, by running
|
|
0:24:55
|
triple DES AES or single DES, we will say 3DES
|
|
0:25:00
|
what is the hash algorithm, so is an md5 or SHA
|
|
0:25:11
|
and finally what is the Diffy Halman group
|
|
0:25:15
|
Now we could see in this particular platform and version
|
|
0:25:18
|
its supports more than just group number 1, 2 or 5
|
|
0:25:22
|
where the difference between them
|
|
0:25:25
|
is what is the bit length
|
|
0:25:27
|
of the psuedo random number that you can generate
|
|
0:25:31
|
So you should have probably guessed, if you were to use a bit length of 4096
|
|
0:25:36
|
than you are going to have a
|
|
0:25:38
|
harder time guessing this
|
|
0:25:40
|
then if someone were doing an brute force attack against a 768
|
|
0:25:44
|
bit value
|
|
0:25:46
|
So in general the higher number is going to be more secure
|
|
0:25:48
|
more secure of the negotiation
|
|
0:25:51
|
I will say group 5
|
|
0:25:53
|
because the vast majority of the platforms should support group number 5
|
|
0:25:59
|
Now if we look at the result of this, if we say show run section crypto
|
|
0:26:06
|
all four of these options are puring in the configuration
|
|
0:26:09
|
what this means is that none of these four that I have picked
|
|
0:26:12
|
are the defaults for the policy
|
|
0:26:15
|
so if we saw that the encryption, the authentication, and the group number appear
|
|
0:26:20
|
but the hash did not
|
|
0:26:22
|
means that for this particular version that is the default value
|
|
0:26:32
|
Now the potential issue with this
|
|
0:26:34
|
is that different platfoms in different versions
|
|
0:26:37
|
have different defaults for this options
|
|
0:26:40
|
where in the case of IOS
|
|
0:26:42
|
we may be using the hash of the SHAby default
|
|
0:26:45
|
but may be in an older version of IOS or in a different version of ASA
|
|
0:26:50
|
thats not certainly the case
|
|
0:26:52
|
So whenever you are defining the policy
|
|
0:26:55
|
you want to make sure that you always define all four of these statically
|
|
0:26:59
|
even if it doesn't show up in the config
|
|
0:27:02
|
its a good idea to list all four of them out
|
|
0:27:08
|
Now my next step would be define
|
|
0:27:10
|
how am I actually going to do the authentication
|
|
0:27:13
|
I am saying that they are going to use a pre shared key
|
|
0:27:16
|
but now I have to actually define this
|
|
0:27:19
|
this is going to be with the crypto
|
|
0:27:23
|
the crypto ISAKMP key
|
|
0:27:27
|
So whats the actual password, I will say the password is cisco
|
|
0:27:31
|
and for what particular peer
|
|
0:27:33
|
is this going to be used for
|
|
0:27:36
|
Now in this example we are going to use just the IP address
|
|
0:27:40
|
we will comeback later and talk about doing authentication
|
|
0:27:43
|
using the host name
|
|
0:27:45
|
there some different cases where using the host name will not work
|
|
0:27:50
|
versus using the address
|
|
0:27:51
|
So we will start with the simple example then we will work toward some of the more complicated designs later
|
|
0:27:57
|
but this address here this is going to be
|
|
0:27:59
|
who is the other end of the tunnel
|
|
0:28:01
|
where in this case is router3, so 200.0..23.3
|
|
0:28:08
|
Now from router3's perpective
|
|
0:28:11
|
I need to make sure that this is the opposite
|
|
0:28:14
|
where 1 is authenticating 3
|
|
0:28:18
|
but 3 needs to authenticate 1
|
|
0:28:22
|
So as you can see, looking at the side by side
|
|
0:28:25
|
its a little less likely that I am going to make a mistake
|
|
0:28:27
|
because I were just to take this entire output and copy it to router3
|
|
0:28:31
|
its not going to work, because at the wrong address being matched there
|
|
0:28:37
|
So now I have the phase I policy defined
|
|
0:28:40
|
next thing I need to figure out what is the phase II policy
|
|
0:28:44
|
where the phase II policy again is going to determine who is the tunnel going to
|
|
0:28:49
|
what is going inside of the tunnel
|
|
0:28:57
|
So lets start with the first portion, Who is the tunnel going to ?
|
|
0:29:02
|
so on router1, we are going to create the crypto
|
|
0:29:04
|
Ipsec
|
|
0:29:11
|
excuse me cypto map
|
|
0:29:13
|
crypto map, we will give it a name, I will say that this is crypto map
|
|
0:29:19
|
and were using
|
|
0:29:22
|
we need to give it a sequence here, lets say sequence number 10
|
|
0:29:26
|
and we are using IPSec with the ISAKMP for the negotiation
|
|
0:29:30
|
you can technically use a manual key
|
|
0:29:34
|
which means you wouldn't need to use phase I
|
|
0:29:38
|
the gdoi, we will talk about this, when we get to the get VPN
|
|
0:29:42
|
for doing the secure multicast encryption or the transport based encryption
|
|
0:29:49
|
but in this case we are using
|
|
0:29:50
|
ISAKMP for the phase I negotiation
|
|
0:29:54
|
Hey, this crypto map will remain disabled
|
|
0:29:56
|
until a peer any valid access list have been configured
|
|
0:29:59
|
or again thats two pieces of the puzzle that we need
|
|
0:30:03
|
the peer is going to be the who
|
|
0:30:05
|
the access list is going to be the what
|
|
0:30:07
|
the transform set is going to be the how
|
|
0:30:11
|
so I need to say
|
|
0:30:13
|
either match or set
|
|
0:30:15
|
I need to say, set the peer
|
|
0:30:18
|
where in this case the tunnel is going to router3, so 200.0.23.3
|
|
0:30:25
|
from router3's perpective, its going to be router1's address, so its going to be the opposite
|
|
0:30:30
|
okay the next thing I need to do is to set
|
|
0:30:34
|
what is the transform set
|
|
0:30:38
|
Now I didn't defined the transform set so I can't reference it here
|
|
0:30:42
|
but thats going to be the how
|
|
0:30:45
|
and also to match the address
|
|
0:30:49
|
this is going to be the acl that is going to define
|
|
0:30:52
|
what is going inside of the tunnel
|
|
0:31:00
|
So our next step we need those the two additional pieces
|
|
0:31:06
|
we will define the access list
|
|
0:31:08
|
that says I want any traffic that is coming from 192.168.0.0/16
|
|
0:31:18
|
that is going to 172.16.0.0/16
|
|
0:31:25
|
Now with this access list you can be as broad
|
|
0:31:29
|
as a match or you could be as specific as a match, as you want
|
|
0:31:32
|
I could say that all IP traffic is going to go in the tunnel
|
|
0:31:35
|
I could say that just ICMP pings from this host to that host are going to be going in there
|
|
0:31:41
|
you really have the freedom to match whatever you want pretty much with this access list
|
|
0:31:46
|
Hey so now I know whats going in the tunnel
|
|
0:31:49
|
thats access list 100
|
|
0:31:51
|
now I need to know, how is it going to be treated, this is the crypto IPSec
|
|
0:31:56
|
transform set
|
|
0:31:58
|
we need to give it a name here
|
|
0:32:00
|
a lot of these examples, you will see for this
|
|
0:32:02
|
we will put a descriptive name here that is
|
|
0:32:05
|
self explanatory as to what exactly inside
|
|
0:32:09
|
the transform set
|
|
0:32:11
|
So something like ESP-3DES-MD5
|
|
0:32:17
|
where it says that we are going to use ESP, 3DES
|
|
0:32:23
|
for the encryption
|
|
0:32:26
|
and we are going to use ESP, MD5
|
|
0:32:30
|
for the authentication
|
|
0:32:36
|
Hey you will see that depending on the particular platform in the version you will have some options here
|
|
0:32:41
|
where this version also supports a different type of encryption that is seal
|
|
0:32:45
|
that is 160 bit encryption
|
|
0:32:48
|
we could also use AES, we could say no
|
|
0:32:52
|
which is ESP without doing any encryption
|
|
0:32:55
|
if for some reason you have a very very low powered platform
|
|
0:32:58
|
and you basically just want to
|
|
0:33:00
|
encapsulate the traffic inside of a tunnel
|
|
0:33:03
|
but not actually do any encryption
|
|
0:33:05
|
we could do that
|
|
0:33:07
|
but most of the time you would see common transform sets here saying
|
|
0:33:10
|
either 3DES or AES
|
|
0:33:13
|
and then either MD5 or SHA using ESP
|
|
0:33:17
|
and again likewise we could use AH
|
|
0:33:19
|
but thats only for authentication, its not for encryption
|
|
0:33:24
|
this would also be under the
|
|
0:33:27
|
the transform set sub configuration mode
|
|
0:33:29
|
where we would define, are we running
|
|
0:33:32
|
in tunnel mode or transport mode
|
|
0:33:36
|
where tunnel mode is going to be the default
|
|
0:33:39
|
Now if we were to change this
|
|
0:33:41
|
to run as transport mode
|
|
0:33:44
|
the IOS is processing it, this is a little bit different
|
|
0:33:47
|
that how other platforms work
|
|
0:33:49
|
where the router is going to overide
|
|
0:33:53
|
your configuration of transport and force it to tunnel
|
|
0:33:58
|
if this the source of the traffic and the destination of the traffic
|
|
0:34:02
|
are not where the
|
|
0:34:05
|
the packets are actually coming from or going to
|
|
0:34:09
|
so in other words
|
|
0:34:11
|
if , lets look at the diagram here
|
|
0:34:16
|
if the packet were coming from the test PC
|
|
0:34:20
|
and is routing this way its going to some host thats on VLAN4
|
|
0:34:25
|
router1 and router3
|
|
0:34:28
|
even if the transform set was configured to transport mode
|
|
0:34:33
|
this would be overridden with tunnel mode
|
|
0:34:37
|
because on router1, I am saying that the source of the traffic is this address here
|
|
0:34:40
|
and the destination the, other tunnel is there
|
|
0:34:44
|
IOS can only run transport mode
|
|
0:34:47
|
when that is actually the source and destination of the data packets
|
|
0:34:53
|
So IOS tranport mode is only going to be used for
|
|
0:34:56
|
if you are trying to encrypt
|
|
0:34:58
|
lets say like your management traffic to the router
|
|
0:35:01
|
|
|
0:35:03
|
SNMP over an IPSec tunnel
|
|
0:35:06
|
but I want to have to re encapsulate the packets again
|
|
0:35:10
|
then I could use tranport mode for that
|
|
0:35:14
|
otherwise if the packet is
|
|
0:35:16
|
transitting from some host on the lan going to some other
|
|
0:35:20
|
destination thats not the IPsec peer
|
|
0:35:22
|
its automatically going to be overidden by the tunnel mode
|
|
0:35:27
|
Now the real application we will see with this is when we are using GRE tunnels
|
|
0:35:30
|
and IPSec at the same time with DMVPN
|
|
0:35:34
|
So we will come back with this later with the transport mode when we get to our DMVPN configuration
|
|
0:35:40
|
but on router1, we will leave this alone
|
|
0:35:42
|
the default mode is going to be tunnel
|
|
0:35:47
|
Hey, so look at what we have so far lets say show run section crypto
|
|
0:35:53
|
we have the phase I policy
|
|
0:35:56
|
we have the pre shared key
|
|
0:35:59
|
the transform set is defined
|
|
0:36:02
|
the crypto map is defined but it says its incomplete
|
|
0:36:06
|
and the reason why is that we are missing those two other step
|
|
0:36:09
|
where we need to
|
|
0:36:11
|
say, what is the traffic
|
|
0:36:16
|
so now we can match address 100
|
|
0:36:18
|
thats access list 100 that we created
|
|
0:36:22
|
then set the transform set
|
|
0:36:25
|
transform set here is ESP-3DES-MD5
|
|
0:36:34
|
now lastly if we take a look at the routing table
|
|
0:36:38
|
the outgoing interface that router1 is using to reach
|
|
0:36:42
|
the 200.0.23.0/24
|
|
0:36:47
|
address, so this is router3's address on the tunnel
|
|
0:36:50
|
is serial0/0/0.12
|
|
0:36:55
|
So this is where my crypto map needs to be applied here
|
|
0:36:58
|
if we look at the diagram, that is the serial subinterface on router1
|
|
0:37:04
|
I would not want to put the crypto map on the main interface
|
|
0:37:11
|
I need to put it on the sub interface
|
|
0:37:14
|
So basically whatever is the outgoing interface in your routing table, thats where the crypto map would need to be applied
|
|
0:37:21
|
if you have multiple outgoing interfaces
|
|
0:37:24
|
lets say that router1 had this frame relay pbc that goes to rotuer2
|
|
0:37:30
|
but then may be it has another
|
|
0:37:31
|
point to point link that goes directly to router3
|
|
0:37:35
|
I would then want to apply them to both of them
|
|
0:37:38
|
then depending on how the traffic is routed based on the routed table
|
|
0:37:41
|
thats going to control which individual crypto map is going to be initiated
|
|
0:37:46
|
when the packets go out the length
|
|
0:37:48
|
but these type of designs, we will come back and look at, later
|
|
0:37:52
|
in some more advanced examples
|
|
0:37:57
|
So on router1, this is where we are going to
|
|
0:38:00
|
apply the crypto map,
|
|
0:38:02
|
we simply say cypto map
|
|
0:38:04
|
and then its name, which in this case is crypto map
|
|
0:38:11
|
Now notice it doesn't ask me for direction
|
|
0:38:15
|
simply apply to the interface, because its always going to be for outbound traffic
|
|
0:38:21
|
Now additionally I am going to do two extra things on router1 before we start to test it
|
|
0:38:26
|
I am going to debug crypto ISAKMP
|
|
0:38:29
|
and debug cypto IPSec
|
|
0:38:34
|
I am going to log both of these debugs to the buffer
|
|
0:38:40
|
okay, I want to make sure my buffer is large enough
|
|
0:38:43
|
to handle all of these because its a lot of debug output
|
|
0:38:48
|
then I will say clear log, we will look at the show log
|
|
0:38:53
|
right now it should be pretty much empty other that the last
|
|
0:38:57
|
configuration log that I have
|
|
0:39:00
|
okay, the same thing on router3
|
|
0:39:03
|
I will say debug cypto ipsec and debug crypto isakmp
|
|
0:39:10
|
So phase II and phase I respectively
|
|
0:39:13
|
but I want to log to the buffer
|
|
0:39:18
|
due to large size
|
|
0:39:20
|
and also what I want to say here is login console at level 6
|
|
0:39:25
|
So I don't want all of these debugs going to the console
|
|
0:39:27
|
because I potentially could lock myself out of the commandline
|
|
0:39:30
|
we will say log in console
|
|
0:39:32
|
at level 6, not at level 7
|
|
0:39:37
|
So look at router1's final config now, lets say show run section
|
|
0:39:40
|
crypto or access list
|
|
0:39:45
|
or interface
|
|
0:39:59
|
So we can take this now and change this around
|
|
0:40:02
|
to match what router 3 need
|
|
0:40:04
|
So we have the first portion which is the phase I policy
|
|
0:40:08
|
plus the phase I authentication
|
|
0:40:12
|
I have the transform set
|
|
0:40:15
|
for phase II
|
|
0:40:17
|
I have the
|
|
0:40:21
|
access list for phase II
|
|
0:40:28
|
then in the crypto map this what we define in the peer
|
|
0:40:32
|
we are calling the transform set and we are calling the acl
|
|
0:40:35
|
then lastly its applied to the interface
|
|
0:40:40
|
so from router3's perspective, everything is going to be almost exactly the same
|
|
0:40:44
|
again with the exception of changing some of the addresses around
|
|
0:40:48
|
So the crypto key for the phase I authentication
|
|
0:40:51
|
this needs to point at router1
|
|
0:40:54
|
as does the
|
|
0:40:55
|
crypto peer for phase II
|
|
0:40:59
|
the access list for phase II this needs to be a mere image
|
|
0:41:04
|
or I need to say the traffic is not coming from 192.168
|
|
0:41:07
|
it is going there
|
|
0:41:13
|
then on router3, this is going to be applied
|
|
0:41:16
|
not onto the same interface as router1 but its going to be serial1/0.23
|
|
0:41:26
|
but you can see beyond this, its nearly identical to rest of the configuration
|
|
0:41:30
|
and thats why its, why it is advantageous
|
|
0:41:33
|
to look at both of it side by side
|
|
0:41:38
|
So next lets take this configuration of router3
|
|
0:41:41
|
apply and then see if we can actually get the tunnel to work
|
|
0:41:51
|
So looks like it took all of the syntax
|
|
0:41:55
|
that once we apply the crypto map it said that
|
|
0:41:58
|
cypto isakmp says isakmp is on
|
|
0:42:02
|
So notice that there is no separate command here that turns the negotiation on
|
|
0:42:06
|
simply apply the crypto map to the interface
|
|
0:42:10
|
is going to turn the ISAKMP process on
|
|
0:42:14
|
So now we want to actually test this with the transit traffic
|
|
0:42:18
|
going between the protected segment
|
|
0:42:22
|
So I am going to be generating traffic down from switch2
|
|
0:42:27
|
going to thi slan interface of router4
|
|
0:42:30
|
assuming that the tunnel is working
|
|
0:42:33
|
I should be able to get the traffic to router1
|
|
0:42:36
|
1 is going to initiate the tunnel to 3
|
|
0:42:39
|
its going to get encapsulated inside here as ESP
|
|
0:42:44
|
come out the other end as decrypted traffic and then go to the VLAN4 interface
|
|
0:42:55
|
Now assuming that the tunnel does work
|
|
0:42:57
|
if we wanted to verify this in the data plane
|
|
0:43:01
|
to see the actual packet flow
|
|
0:43:03
|
we could go to router2
|
|
0:43:05
|
and look at the packets coming in one
|
|
0:43:08
|
WAN interface and going out the other
|
|
0:43:11
|
and look at the debug IP packet
|
|
0:43:17
|
So this is going to show us what is the actual transit traffic
|
|
0:43:20
|
between these two interface
|
|
0:43:23
|
Now in order to do this
|
|
0:43:25
|
I need to make sure that this traffic is going to be process switched
|
|
0:43:28
|
So on router2
|
|
0:43:31
|
if we look at the show ip interface brief
|
|
0:43:34
|
one thing I need to do first
|
|
0:43:36
|
is go to both of these WAN interfaces and say no ip route cache
|
|
0:43:41
|
I am turning safe off which is going to allow me to transit packet
|
|
0:43:47
|
then we will say
|
|
0:43:52
|
lets just say debug IP packet detail
|
|
0:43:55
|
So we will send all of the
|
|
0:44:01
|
all of the debug output to router2's console
|
|
0:44:06
|
So there is not too much going out on the network otherwise
|
|
0:44:09
|
there is just some basic OSPF routing
|
|
0:44:12
|
So hopefully its not going to lock us out of the console
|
|
0:44:14
|
by sending all of this to the
|
|
0:44:16
|
all these debug output to the console on router2
|
|
0:44:21
|
so next lets go to switch2, this is where we are going to test the traffic from
|
|
0:44:26
|
and I am going to ping that address on router4 172.16.4.4
|
|
0:44:34
|
this output in itself
|
|
0:44:37
|
is a pretty good indication that the tunnel is working
|
|
0:44:41
|
with the first packet was lost
|
|
0:44:44
|
and the rest of them are successful
|
|
0:44:46
|
and the reason why is that it takes a little bit of time for the routers to actually establish the tunnel
|
|
0:44:52
|
so in about 2 to 3 seconds
|
|
0:44:57
|
it took me to establish the phase I negotiation and the phase II negotiation
|
|
0:45:03
|
Now if we look at router2, who is in the transit path
|
|
0:45:06
|
what we should have seen
|
|
0:45:09
|
and if we scroll up little bit here, lets say on the bug
|
|
0:45:16
|
what I should see here on the router2
|
|
0:45:21
|
is that there was the negotiation traffic
|
|
0:45:30
|
which is here
|
|
0:45:33
|
says packets came from 200.0.12.1 going to 200.0.23.3
|
|
0:45:40
|
it is UDP source and destination 500
|
|
0:45:43
|
this is the phase I ISAKMP negotiation
|
|
0:45:48
|
Now notice on router2 that I did not see
|
|
0:45:51
|
from switch2 going to router4
|
|
0:45:54
|
I see them coming from and going to the end points of the tunnel
|
|
0:46:00
|
now if we scroll down a little bit further
|
|
0:46:02
|
what we should see once UDP 500 is done
|
|
0:46:06
|
I have protocol number 50
|
|
0:46:08
|
which again is the ESP
|
|
0:46:11
|
the ESP is going from router1 to router3
|
|
0:46:16
|
and from router3, back to router1
|
|
0:46:20
|
just based on this output alone
|
|
0:46:24
|
I can pretty much guarantee that the tunnel is working
|
|
0:46:26
|
because the protocol 50 which is ESP
|
|
0:46:29
|
is not going to be sent until the phase I negotiation is complete
|
|
0:46:33
|
and the phase II negotiation is complete
|
|
0:46:37
|
if we go to the actual end points which again are router1 and 3
|
|
0:46:42
|
there is two different verifications we are going to do again
|
|
0:46:45
|
one of them for phase I, one them for phase II
|
|
0:46:48
|
phase I is the show crypto isakmp sa
|
|
0:46:55
|
says that there is an sa that is going to router3, coming from us
|
|
0:47:01
|
the state QM_idle, for quick mode idle
|
|
0:47:06
|
it means that phase I negotiation was correct, we are now going on to phase II
|
|
0:47:11
|
if we look at the show
|
|
0:47:13
|
crypto ipsec
|
|
0:47:17
|
or show crypto
|
|
0:47:22
|
show crypto ipsec sa
|
|
0:47:25
|
this is going to show the phase II IPSec security association
|
|
0:47:31
|
says that on this particular interface I have a crypto map applied
|
|
0:47:34
|
that is sourced from my local address, 200.0.12.1
|
|
0:47:40
|
the peers address is 200.0.23.3 at port 500
|
|
0:47:46
|
thats the UDP port used for the ISAKMP negotiation
|
|
0:47:50
|
says my local identity
|
|
0:47:53
|
is 192.168.0.0/16
|
|
0:47:57
|
the remote identity
|
|
0:47:59
|
is 172.16.0.0/16
|
|
0:48:02
|
these are defined by the
|
|
0:48:04
|
the access list
|
|
0:48:06
|
these are the proxy identity so the proxy acl
|
|
0:48:11
|
then i see the actual packet comments
|
|
0:48:14
|
how many packets are being encapsulated
|
|
0:48:16
|
so going out the tunnel
|
|
0:48:17
|
how many are decapsulated how many are coming back in the tunnel
|
|
0:48:21
|
how many packets are being encrypted
|
|
0:48:24
|
how many packets are being
|
|
0:48:25
|
digested and verified
|
|
0:48:28
|
this means the authentication
|
|
0:48:31
|
so if i was running md5 or sha
|
|
0:48:34
|
i should see the digest going out and the verify coming back in
|
|
0:48:39
|
if i was only running esp with
|
|
0:48:41
|
3 des but not esp with md5
|
|
0:48:43
|
this comment here would be 0
|
|
0:48:49
|
so the first one that says how many total are coming in and out
|
|
0:48:52
|
next one says the encryption in and out
|
|
0:48:54
|
next one says the authentication in and out
|
|
0:48:59
|
we can also see some of the other details like the
|
|
0:49:02
|
the spi number
|
|
0:49:04
|
there is really no reason you would need to use this
|
|
0:49:07
|
unless there is some sort of software bug
|
|
0:49:09
|
or may be the
|
|
0:49:10
|
the spi numbers are not getting properly
|
|
0:49:13
|
properly used and
|
|
0:49:15
|
generally in production the way that you would see this problem
|
|
0:49:18
|
is just that packets are here are dropped out of the tunnel
|
|
0:49:22
|
or the tunnel just
|
|
0:49:24
|
for some reason just stops working
|
|
0:49:27
|
sometimes if it allows it on the router
|
|
0:49:29
|
you can run into these code bugs where selectively the
|
|
0:49:33
|
the spis gets messed up and then
|
|
0:49:34
|
either you need to reboot or you need to change your code version in order to fix it
|
|
0:49:39
|
but from here really what we care about
|
|
0:49:41
|
is whats the transform set
|
|
0:49:44
|
and whats the mode
|
|
0:49:45
|
of the vpn
|
|
0:49:47
|
says we are using esp with 3des and esp with md5 and its running in tunnel map
|
|
0:49:54
|
we also have the security association lifetime
|
|
0:49:58
|
the remaining lifetime
|
|
0:50:01
|
is this amount of kilobytes
|
|
0:50:04
|
and this amount of seconds
|
|
0:50:07
|
this is for the phase 2 security associate
|
|
0:50:11
|
there is going to seperate timers that are for phase 1
|
|
0:50:13
|
because we rekey them seperately
|
|
0:50:19
|
now notice that there is actually 2 security associations here for ipsec
|
|
0:50:25
|
and there is an inbound one and there is an outbound
|
|
0:50:28
|
so one from me going to router 3
|
|
0:50:34
|
then one from router 3
|
|
0:50:37
|
going to me to router 1
|
|
0:50:41
|
we will see that this is important
|
|
0:50:44
|
when we get to some
|
|
0:50:45
|
specific filtering techniques
|
|
0:50:49
|
so an interaction with network address translation
|
|
0:50:52
|
and the nat transparency and the nat reversal features
|
|
0:50:56
|
that with the ic camp
|
|
0:50:58
|
phase 1 sa
|
|
0:51:00
|
it is a bidirectional negotiation
|
|
0:51:03
|
so i send you
|
|
0:51:05
|
a udp port 500 packet and you reply
|
|
0:51:09
|
so its a normal connection oriented
|
|
0:51:11
|
conversation
|
|
0:51:13
|
but in the case of the ipsec sa for phase 2 it is 2 unidirectional sa
|
|
0:51:18
|
means that I initiate one to you
|
|
0:51:21
|
you initiate one back to me
|
|
0:51:24
|
this means that for any type of filtering like an active firewall or statefull firewall
|
|
0:51:32
|
it is generally going to have a problem of
|
|
0:51:34
|
allowing the out to in
|
|
0:51:39
|
security association back
|
|
0:51:42
|
now in this case there is no filtering in the topology so everything turn out to be fine
|
|
0:51:47
|
now we can verify this further if we were to go to switch
|
|
0:51:49
|
till they send some more packets
|
|
0:51:51
|
we should see now when we look at the show
|
|
0:51:54
|
crypto ipsec sa again
|
|
0:51:56
|
that these counters are going on
|
|
0:51:58
|
so where it was previously 9 packets now its 14
|
|
0:52:01
|
thats accounting for the 5 additional pings that i sent out
|
|
0:52:04
|
and the 5 echo replies that i am receiving back in
|
|
0:52:11
|
so next lets look at the debug upward and see
|
|
0:52:14
|
on router 1 and router 3 what do they see for the negotiation once the tunnel was actually establishing
|
|
0:52:21
|
we look at the show log output
|
|
0:52:25
|
the first thing we see
|
|
0:52:27
|
is an ipsec security association request
|
|
0:52:32
|
that i am trying to establish a tunnel
|
|
0:52:34
|
where my local address is that 12.1
|
|
0:52:37
|
i am trying to establish the tunnel to 23.3
|
|
0:52:42
|
i see whats the acl that i am using the proxy identities
|
|
0:52:46
|
the transform set is esp
|
|
0:52:48
|
with 3des and md5 in tunnel mode
|
|
0:52:53
|
where these particular security associations lifetimes
|
|
0:52:57
|
now right now the spi is 0
|
|
0:53:01
|
because this is what is used for ISAKMP
|
|
0:53:04
|
for any tunnel that comes you have that comes in with spi 0
|
|
0:53:07
|
it means that its part of the tunnel negotiation
|
|
0:53:10
|
Now the router knows it needs to establish ISAKMP
|
|
0:53:14
|
Now we see the output from the ISAKMP debug
|
|
0:53:18
|
So restoring a new peer structure for router3
|
|
0:53:24
|
says we starting in main mode
|
|
0:53:28
|
which means that there is going to be six messages we are using
|
|
0:53:32
|
says additionally I found a pre shared key thats for that peer
|
|
0:53:37
|
now at all necessarily authenticated yet but just that I have a password with them
|
|
0:53:42
|
So of the policy
|
|
0:53:44
|
for ISAKMP says that I should use pre shared authentication
|
|
0:53:47
|
I know what particular key to use
|
|
0:53:52
|
okay, next I have the packet thats actually going out
|
|
0:53:56
|
I am starting message number one of main mode
|
|
0:54:00
|
if this was aggressive mode, it would say am instead of ma
|
|
0:54:03
|
so this is main mode message number 1
|
|
0:54:06
|
or I am sending a packet to 3
|
|
0:54:09
|
I even recieved a packet in from 3
|
|
0:54:13
|
it says we are now going to mean mode exchange
|
|
0:54:17
|
which is the second message
|
|
0:54:20
|
what this is telling me at the minimum
|
|
0:54:23
|
is that router3 is configured to accept a tunnel from me
|
|
0:54:29
|
So if I say send the packet 3 but they did not have my peer address
|
|
0:54:33
|
or they didn't have ISAKMP configured at all
|
|
0:54:36
|
I would never see
|
|
0:54:38
|
router1 get to the second portion
|
|
0:54:40
|
of the negotiation
|
|
0:54:42
|
or basically this is the responder
|
|
0:54:44
|
sending the response back to the initiator
|
|
0:54:47
|
hey so now we are going to the portion where we actually exchanged
|
|
0:54:50
|
the ISAKMP policies or we go through the proposal
|
|
0:54:55
|
I am going to now send the proposal to rotuer3
|
|
0:55:00
|
says my policy that I configured has priority number 10
|
|
0:55:05
|
and specifically its running
|
|
0:55:07
|
3DES, MD5, Diffy Halman group
|
|
0:55:09
|
5 with pre shared authentication
|
|
0:55:12
|
a Security association lifetime in seconds of this value
|
|
0:55:18
|
Now that we care again what the lifetime is because thats negotiated
|
|
0:55:23
|
what I do care about is those for values
|
|
0:55:25
|
whats the encryptionl, whats the hashing whats the DH group and whats the authentication
|
|
0:55:31
|
router3 is responding to me and saying
|
|
0:55:34
|
the attributes are acceptable
|
|
0:55:36
|
this is what I need to see here
|
|
0:55:39
|
if it says the attributes are not acceptable or the attributes are rejected
|
|
0:55:44
|
its going to tell me exactly why
|
|
0:55:46
|
So it will say the policy is not acceptable because
|
|
0:55:50
|
the offered encryption was 3DES but they are responding with single DES
|
|
0:55:54
|
or you offered
|
|
0:55:55
|
pre shared authentication, they want to do RSA signatures
|
|
0:55:58
|
or they want to do RSA encrypted norms
|
|
0:56:03
|
So at this portion
|
|
0:56:05
|
now they are accepting my policy
|
|
0:56:08
|
we should see that we porceed on from
|
|
0:56:11
|
main mode message to
|
|
0:56:13
|
3 and 5 which means that
|
|
0:56:15
|
essentially they have accepted each other's policies
|
|
0:56:19
|
Now we actually do
|
|
0:56:21
|
the authentication
|
|
0:56:23
|
says I have the pre shared key of router3
|
|
0:56:29
|
and we should see here that
|
|
0:56:38
|
the SA has been athenticated
|
|
0:56:41
|
this is what we want to see
|
|
0:56:44
|
Hey now we can actually complet it , this is our final acknowledgment
|
|
0:56:48
|
says now IKE phase I is complete
|
|
0:56:52
|
we are now moving to quick M
|
|
0:56:54
|
quick mode IO, l QO IO
|
|
0:56:57
|
this means that all of the attributes were matched
|
|
0:57:00
|
the authenticaiton is successful
|
|
0:57:03
|
now we can go on to actually building the IPSec tunnel
|
|
0:57:08
|
we should see the next to bugs are going to start coming from the IP Sec process
|
|
0:57:14
|
so ISAKMP has done its job with phase I now we get into IPSec
|
|
0:57:19
|
IPSec says that we are trying to send a proposal
|
|
0:57:23
|
that has
|
|
0:57:25
|
these different attributes like tunnel mode
|
|
0:57:28
|
this is the proxy ecl
|
|
0:57:31
|
we could see the other
|
|
0:57:33
|
the other attributes her, like it says that
|
|
0:57:35
|
its ESP with 3DES and its running md5 for athentication
|
|
0:57:41
|
but again the issue
|
|
0:57:43
|
that we want look for the outpout that we look for
|
|
0:57:46
|
is that again these attributes are acceptable
|
|
0:57:50
|
so for phase II the transform says match
|
|
0:57:54
|
we see that the proxy acl match as well
|
|
0:57:57
|
otherwise i would give us an error message
|
|
0:58:00
|
and we should now be going to, actually create the essay
|
|
0:58:05
|
says there is two security assocaitions
|
|
0:58:08
|
\one of them is destined to router1
|
|
0:58:10
|
one of them is destined to router3
|
|
0:58:13
|
both of them are using protocol number 50
|
|
0:58:16
|
which again is
|
|
0:58:19
|
ESP
|
