|
0:00:14
|
So lets take a look at this on the command line now
|
|
0:00:16
|
where again we are going to configure router2 as the PKI server
|
|
0:00:20
|
then the end points to the VPN which are router1
|
|
0:00:23
|
router3 and ASA2
|
|
0:00:25
|
are going to be PKI clients
|
|
0:00:28
|
then additionally we want to make sure that times are synchronised
|
|
0:00:31
|
so we are going to configure router2 as an
|
|
0:00:32
|
NTP server as well
|
|
0:00:38
|
first step then, if we look at the
|
|
0:00:41
|
the show clock output and the do show ntp status
|
|
0:00:47
|
it says that the clock is synchronised
|
|
0:00:50
|
the reference clock is 127.127.1.1
|
|
0:00:55
|
which means that the router2 is the ntp master itself
|
|
0:00:59
|
So as we know with ntp configuration, really there is not that many
|
|
0:01:02
|
commands that go along with it
|
|
0:01:04
|
if we look at the show run
|
|
0:01:07
|
include ntp
|
|
0:01:09
|
the only thing we have right now is just the ntp master
|
|
0:01:13
|
So then the other devices in the network, router1, router2 and router3
|
|
0:01:17
|
they simply needs to point towards router2 as the ntp server
|
|
0:01:20
|
then ultimately when we look at the show ntp status
|
|
0:01:25
|
we want to make sure that the clocks are not synchronised
|
|
0:01:28
|
which we could see on router1
|
|
0:01:30
|
that the, the clock is synchronised
|
|
0:01:36
|
So next step lets actually configure the PKI server
|
|
0:01:39
|
this is going to be the crypto PKI server command in global config
|
|
0:01:44
|
we will give it a server name, we will say that this is just router2
|
|
0:01:48
|
and again there is a lot of
|
|
0:01:50
|
minor options that you can change in here, if you are doing automatic
|
|
0:01:53
|
rollover of the certificates
|
|
0:01:56
|
we could configure the database to be some sort of external server
|
|
0:01:59
|
but really the only thing that we need to do at a minimum
|
|
0:02:03
|
is simply turn the http process on
|
|
0:02:07
|
so we are listening for SF enrollments
|
|
0:02:09
|
and then if we don't want to manually
|
|
0:02:11
|
grant all the certificates
|
|
0:02:13
|
we would say just to simply
|
|
0:02:15
|
automatically grant them
|
|
0:02:17
|
otherwise once a PKI client
|
|
0:02:20
|
sends a request, we would need to go to the
|
|
0:02:21
|
the PKI server and then we would need to say
|
|
0:02:24
|
the crypto PKI server
|
|
0:02:28
|
then whatever the name is
|
|
0:02:30
|
do I want to grant the particular enrollment, do I want to reject it
|
|
0:02:35
|
or do I want to remove it from the database
|
|
0:02:38
|
but when auto enrollment is on, we should see that, once the client's enroll
|
|
0:02:42
|
and we will see this through the debug of
|
|
0:02:44
|
the debug crypto PKI
|
|
0:02:46
|
transactions
|
|
0:02:48
|
that we should see that its automatically send
|
|
0:02:50
|
and then automatically received back down by the client
|
|
0:02:55
|
Now the server isn't actually
|
|
0:02:57
|
active, until we issue no shut down command
|
|
0:03:01
|
under the crypto PKI server mode
|
|
0:03:04
|
so assuming that you are done with all of the other options and you don't want change thing
|
|
0:03:08
|
that would be your very last step
|
|
0:03:10
|
So on addition to just enabling the service, I need to turn the http server on
|
|
0:03:16
|
that if we go back under the
|
|
0:03:18
|
the server will simply say no shutdown
|
|
0:03:26
|
we can see that the router now automatically is generating the RSA keys
|
|
0:03:31
|
which will be similar to the same process we would do for SSH
|
|
0:03:35
|
we could generate this manually
|
|
0:03:37
|
we could also control what is the bit length
|
|
0:03:40
|
for the signing keys versus the other keys that were using
|
|
0:03:44
|
but we could see just what the
|
|
0:03:46
|
the very basic minimum configuration
|
|
0:03:49
|
the routers going to choose most of these options automatically
|
|
0:03:52
|
if we now look at the show run section crypto
|
|
0:03:57
|
we see now we have the
|
|
0:04:00
|
the CA certificates
|
|
0:04:02
|
which is what we are going to be signing
|
|
0:04:06
|
the other devices
|
|
0:04:07
|
public keys with, in order to generate their certificates
|
|
0:04:10
|
and then this is what
|
|
0:04:12
|
they are going to be using to compare
|
|
0:04:14
|
their certificates between each other
|
|
0:04:16
|
to make sure that they are agreeing
|
|
0:04:17
|
on who the trusted certificate authority is
|
|
0:04:20
|
and then those certificates are actually valid
|
|
0:04:24
|
Now we can see these
|
|
0:04:25
|
certificates in detail, if we were to look at the show crypto
|
|
0:04:29
|
PKI certificates
|
|
0:04:32
|
we see we have our own certificates, this is the one that we are using
|
|
0:04:35
|
for signing
|
|
0:04:39
|
the issuer in the subject, this is where we would have the
|
|
0:04:43
|
things like the common name, the organizational unit, the country
|
|
0:04:48
|
that type of stuff, so in advanced implementation of this
|
|
0:04:52
|
you can put specific fields
|
|
0:04:54
|
inside the CAs certificate
|
|
0:04:57
|
and inside the actual clients certificate
|
|
0:05:00
|
that you can then use the matched
|
|
0:05:03
|
in particular authentication designs
|
|
0:05:06
|
like in the case of the ASA
|
|
0:05:08
|
we could match the tunnel group
|
|
0:05:10
|
based on these specific fields that we define in the signature
|
|
0:05:15
|
Now for this example for the most basic configuration of PKI
|
|
0:05:19
|
we are going to be matching the tunnel groups, still based on simply IP address
|
|
0:05:23
|
which is the same as the peer address that we are matching under the crypto map
|
|
0:05:28
|
but can't get very detail in the implementations that you can do with
|
|
0:05:31
|
the other certificates
|
|
0:05:33
|
Now if you do want to see some more information about this later
|
|
0:05:37
|
and try out some other additional advanced examples
|
|
0:05:40
|
if you go to the main documentation
|
|
0:05:44
|
then under technology
|
|
0:05:47
|
go down to security
|
|
0:05:55
|
then under security go to ipsec
|
|
0:05:57
|
and IKE
|
|
0:06:00
|
then to configuration examples
|
|
0:06:03
|
and you will see here a lot of good examples
|
|
0:06:05
|
of using certificates with the IOS
|
|
0:06:08
|
also with the ASA and with the VPN client
|
|
0:06:12
|
some of the more advanced type designs, that you could get into
|
|
0:06:17
|
Now within the scope of the CCIE security lab exam
|
|
0:06:20
|
I doubt that we are going to get that specific on this implementations
|
|
0:06:24
|
as long as you know how to do the basic PKI server configuration
|
|
0:06:27
|
the basic enrollment
|
|
0:06:29
|
and then to integrate those with your lan to lan vpns
|
|
0:06:32
|
and your remote access vpns
|
|
0:06:34
|
anything beyond that, you should ideally be able to use the documentation
|
|
0:06:38
|
in order to piece a configuration together
|
|
0:06:44
|
So our next step would then be to go to the PKI clients
|
|
0:06:49
|
which again the router2, is the PKI server, or the certificate authority server
|
|
0:06:54
|
the clients are going to be router1, router3
|
|
0:06:56
|
and the ASA
|
|
0:07:01
|
So the next thing we need to do on the end clients
|
|
0:07:04
|
is to generate their
|
|
0:07:06
|
public and private key pairs
|
|
0:07:08
|
So just like we would do for enabling SSH
|
|
0:07:13
|
this means that we need to have a domain name
|
|
0:07:16
|
So we will say, from global config, ip domain name, ine.com
|
|
0:07:21
|
we already have our host name globally configured
|
|
0:07:23
|
both of those together are going to generate our
|
|
0:07:25
|
fully qualified domain name
|
|
0:07:27
|
which we can then use inside of the
|
|
0:07:30
|
the public to private keys
|
|
0:07:32
|
So next we will say crypto key generate
|
|
0:07:36
|
we want to generate an RSA key
|
|
0:07:38
|
we could then choose the bit length
|
|
0:07:41
|
an as you could probably guess the longer the bit length is, the more secure the key is going to be
|
|
0:07:45
|
where typically a common one, now a days would be like
|
|
0:07:48
|
1024 bit key length
|
|
0:07:54
|
next we need to configure router1
|
|
0:07:56
|
to authenticate
|
|
0:07:58
|
the certificate authority server
|
|
0:08:00
|
and then to actually do the enrollment
|
|
0:08:03
|
So what we are doing this, there is a debug that we are going to look
|
|
0:08:05
|
look at which is the debug crypto
|
|
0:08:08
|
PKI
|
|
0:08:10
|
transaction
|
|
0:08:11
|
this is going to show us the actual authentication
|
|
0:08:15
|
from the packet level authentication with the certificate authority
|
|
0:08:17
|
and then our actual enrollment
|
|
0:08:20
|
Now if there is a problem with
|
|
0:08:22
|
us getting their CA certificates
|
|
0:08:25
|
or us getting our own certificate
|
|
0:08:28
|
this debug is going to us most of those potential issue
|
|
0:08:32
|
So now for the client configuration
|
|
0:08:36
|
we do this with the crypto
|
|
0:08:38
|
crypto PKI trust mode
|
|
0:08:41
|
or in older versions this was the crypto CA trust mode
|
|
0:08:46
|
So this is the CA server name
|
|
0:08:48
|
this doesn't necessarily have to match the one that we configured on router2
|
|
0:08:53
|
we could configure this as, as any locally significant value
|
|
0:08:56
|
because really what the certificate is going to be matched on
|
|
0:09:00
|
is the common name inside CA's certificate
|
|
0:09:05
|
So behind the scenes when we actually use the certificates for the ISAKMP authentication
|
|
0:09:10
|
the router's and the ASA are going to automatically figure out
|
|
0:09:12
|
which is the particular certificate authority's
|
|
0:09:15
|
certificate
|
|
0:09:16
|
that we would need to use for that particular authentication
|
|
0:09:21
|
Now under here the minimum configuration that we need to do
|
|
0:09:25
|
is basically tell the router, how exactly do we enroll
|
|
0:09:28
|
since we are using the Simple Certificate Enrollment Protocol or SCEP
|
|
0:09:33
|
we need to say, What is the enrollment url ?
|
|
0:09:38
|
and SCEP uses http
|
|
0:09:40
|
So essentially I need to put some addresses thats on router2
|
|
0:09:46
|
which in this case, this is a loopback on router2, the
|
|
0:09:49
|
the 200.0.0.2 address
|
|
0:09:54
|
So again this is going assume that we do already have basic ip reachability
|
|
0:09:58
|
and that we have tcp transport toward that particular destination
|
|
0:10:03
|
Now one of the other defaults here that you may need consider with the CA enrollment
|
|
0:10:09
|
and the actual authentication
|
|
0:10:11
|
Is whether you are doing the certificate revocation
|
|
0:10:15
|
list checking or the CRL check
|
|
0:10:18
|
which is used to determine if someone's certificate has been compromised
|
|
0:10:23
|
and removed as valid from the CA server
|
|
0:10:28
|
So lets say for example, we have routers 1,2,3 and
|
|
0:10:31
|
4 that have enrolled with the CA
|
|
0:10:34
|
but that some one was able to get illegitimate access to router4
|
|
0:10:37
|
and get its private key
|
|
0:10:40
|
then we would want to go to the CA server and revoke or delete
|
|
0:10:44
|
router4's certificate
|
|
0:10:46
|
So that it cannot be used for any illegitimate type of request
|
|
0:10:51
|
So in order to do that there is an automated with
|
|
0:10:53
|
automated method
|
|
0:10:55
|
called the Certificate Revocation List or the CRL checking
|
|
0:10:59
|
then when we do the authentication
|
|
0:11:01
|
we can first ask the CA server
|
|
0:11:03
|
is this certificate in the revocation list
|
|
0:11:06
|
and if it is, it means that its not valid for the authentication
|
|
0:11:12
|
but the key point being here, that if we are going to use the CRL, we need to configure it on the PKI server
|
|
0:11:18
|
and thats now one of the options that we
|
|
0:11:20
|
I have configured on router2
|
|
0:11:22
|
So if we do not want to do this, I am going say that the revocation check
|
|
0:11:25
|
should not be done
|
|
0:11:28
|
but above and beyond this, this is the basic minimum configuration that we need for the
|
|
0:11:33
|
the trust mode
|
|
0:11:35
|
we look at the show run section
|
|
0:11:38
|
crypto
|
|
0:11:41
|
we have the rest of our regular policy configured
|
|
0:11:44
|
we have the isakmp policy, we have the isakmp
|
|
0:11:47
|
key for phase I authentication
|
|
0:11:50
|
we have the transform set for our phase II
|
|
0:11:53
|
we have the crypto map, rest of this is just the standard ipsec config
|
|
0:11:57
|
So only other thing different we have done so
|
|
0:11:59
|
far is define who the PKI trust point is
|
|
0:12:04
|
So next step we need to authenticate with them and we need to enroll with them
|
|
0:12:08
|
So we will say crypto
|
|
0:12:10
|
PKI authenticate
|
|
0:12:12
|
and then whats the particular CA server's name, which in this case I named it router2
|
|
0:12:20
|
Now at this point, what we should see from this debug
|
|
0:12:24
|
is essentially the http headers
|
|
0:12:27
|
that we are sending the SCEP request to router2
|
|
0:12:31
|
and that we are getting the response back in
|
|
0:12:34
|
if we get the response back in, its going to say
|
|
0:12:37
|
you have the certificate signature
|
|
0:12:42
|
and then do we want to accept this or not
|
|
0:12:45
|
So in this case, Yes I do want to accept the certificate
|
|
0:12:50
|
Now if we look at the show crypto PKI certificates
|
|
0:12:55
|
we see now we have the CA certificate
|
|
0:13:00
|
So essentially what this is me as seen in CA for the their public key
|
|
0:13:06
|
This is now what I am going to use to
|
|
0:13:08
|
sign, or essentially decrypt
|
|
0:13:11
|
someone else's certificate
|
|
0:13:14
|
in order to see if the authentication is correct
|
|
0:13:17
|
and the key point in this field of the CA certificate
|
|
0:13:20
|
is the common name of the issuer
|
|
0:13:24
|
So when router1 goes to authenticate router3
|
|
0:13:28
|
they are going compare what is the issuer field here
|
|
0:13:31
|
match up
|
|
0:13:33
|
I want to use the same certificate authority server that you are using
|
|
0:13:36
|
then we are going to use the CA certificate to do the signing
|
|
0:13:39
|
and see if the md5 patch is resolved to same thing
|
|
0:13:42
|
which also means that the authentication would be successful
|
|
0:13:48
|
So next I need to actually get my certificate from the them
|
|
0:13:52
|
So router1 is going to send its
|
|
0:13:54
|
public key to the CA
|
|
0:13:56
|
CA is going to sign that with the private key
|
|
0:13:58
|
the result thats coming back is my own certificate
|
|
0:14:02
|
and we get this by saying crypto pki enroll
|
|
0:14:06
|
with the CA server which is router2
|
|
0:14:10
|
Now this password here, this can be anything random
|
|
0:14:14
|
you essentially don't need that you can see its
|
|
0:14:16
|
it says unless you want to revoke your certificate
|
|
0:14:20
|
to put it into the revocation list
|
|
0:14:23
|
says do you want to include the router serial number
|
|
0:14:25
|
you can't do this, you don't necessarily have to
|
|
0:14:28
|
same would be with the ip address
|
|
0:14:30
|
this could be used again
|
|
0:14:32
|
for those advanced authentication
|
|
0:14:34
|
designs
|
|
0:14:36
|
where I could be matching tunnel groups against the particular address
|
|
0:14:40
|
lets say I match it against router1's
|
|
0:14:42
|
loopback address
|
|
0:14:44
|
and then do a specific set of authentication based on that
|
|
0:14:51
|
but from all of these outputs, what I should ultimately see
|
|
0:14:57
|
is that
|
|
0:14:58
|
I received a router certificate
|
|
0:15:00
|
and that the certificate was received from the authority
|
|
0:15:06
|
so essentially if I see anything besides this
|
|
0:15:09
|
comeback once the enrollment is done
|
|
0:15:11
|
then I know that there is a problem with the communication
|
|
0:15:15
|
from the PKI client to the server
|
|
0:15:17
|
or may be some sort of
|
|
0:15:19
|
issue with, like the time
|
|
0:15:21
|
because we can see whats the start date and end date here
|
|
0:15:26
|
for the certificate
|
|
0:15:27
|
versus what the router's time is
|
|
0:15:31
|
So if router1 is not properly configured with its clock
|
|
0:15:35
|
then there is going to be an issue with the certificate
|
|
0:15:40
|
Now again if we look at the show crypto
|
|
0:15:43
|
PKI certificates
|
|
0:15:45
|
we should now see two separate certificates
|
|
0:15:49
|
the one that is the CAs
|
|
0:15:51
|
public key
|
|
0:15:53
|
which is what we saw before
|
|
0:15:54
|
and now also my router certificate
|
|
0:15:58
|
that is my general purpose one
|
|
0:16:01
|
we could see that the issuer is router2 thats the common name
|
|
0:16:05
|
then the other data thats in the subject
|
|
0:16:08
|
like fully qualified domain name, my address, my serial number
|
|
0:16:12
|
these fields again, this can be used for the advanced authentication type designs
|
|
0:16:18
|
but the key is that the
|
|
0:16:19
|
the certificate was received
|
|
0:16:21
|
and it is currently valid
|
|
0:16:23
|
this is mainly what I care about
|
|
0:16:27
|
So lets do the same process on router3
|
|
0:16:30
|
and we will do this on ASA
|
|
0:16:34
|
So on router3, it will say
|
|
0:16:36
|
again we need to generate our own keys
|
|
0:16:40
|
we will say crypto key generate
|
|
0:16:43
|
RSA
|
|
0:16:45
|
we need to have a domain name, because need a fully qualified domain name
|
|
0:16:49
|
I will say ip domain name
|
|
0:16:52
|
is ine.com
|
|
0:16:54
|
Now I could generate my keys
|
|
0:17:02
|
next we are going to configure the
|
|
0:17:04
|
the trust point, we will say crypto
|
|
0:17:07
|
PKI trust point
|
|
0:17:09
|
I will say again this is router2
|
|
0:17:12
|
the enrollment url, I need to know
|
|
0:17:15
|
whats the address of router2
|
|
0:17:18
|
and for the revocation check
|
|
0:17:21
|
right now, not going to do that, because I don't have the PKI server setup with a CRL or a Certificate Revocation List
|
|
0:17:29
|
Now just to show what the error would be
|
|
0:17:33
|
in the authentication of the enrollment process
|
|
0:17:35
|
what I am going to do here in addition to saying debug crypto
|
|
0:17:38
|
PKI transactions
|
|
0:17:43
|
is to change the clock of router3
|
|
0:17:45
|
So it has the incorrect time
|
|
0:17:49
|
So on router3, I will say clock set
|
|
0:17:52
|
and I will say with any random value, lets say 0.0.0.0
|
|
0:17:57
|
January 1st, 2000
|
|
0:18:04
|
next what we should see, once we try to authenticate
|
|
0:18:06
|
the CA and enroll with the CA
|
|
0:18:10
|
router3's local time
|
|
0:18:12
|
is now going to be out of the valid range of the certificate
|
|
0:18:16
|
so it is not going to be accepted from the server
|
|
0:18:20
|
and again there is two steps with this, the actual
|
|
0:18:22
|
authentication and then the enrollment
|
|
0:18:26
|
where we say crypto PKI authenticate
|
|
0:18:29
|
the CA's name
|
|
0:18:32
|
we could see it says, the return code was that
|
|
0:18:38
|
status is failed
|
|
0:18:40
|
the reason why
|
|
0:18:42
|
If we go down to the bottom, it says
|
|
0:18:45
|
the certificate is not yet valid or
|
|
0:18:50
|
it is expired
|
|
0:18:52
|
and the reason why is that
|
|
0:18:54
|
it says it expires
|
|
0:18:59
|
Tuesday September 20, 2011 but the start date is
|
|
0:19:07
|
actually down here, the
|
|
0:19:08
|
the start date
|
|
0:19:11
|
is there is an end date, and is 2014
|
|
0:19:14
|
but the problem is router3's clock is now configured as 2000
|
|
0:19:17
|
year 2000, so its outside the valid range
|
|
0:19:21
|
we now look at the show crypto
|
|
0:19:24
|
PKI certificates
|
|
0:19:26
|
we do not have the CA's certificate
|
|
0:19:30
|
So again typically to avoid this problem, we simply run network time protocol
|
|
0:19:35
|
toward here atleast that the clock is going to be synchronised on all of the client
|
|
0:19:38
|
and on the CA server
|
|
0:19:43
|
So lets change this back now, lets say clock set
|
|
0:19:47
|
and I will set whatever the
|
|
0:19:50
|
the start date is here
|
|
0:19:54
|
20th September, 2011
|
|
0:19:59
|
and now we will do our authentication again
|
|
0:20:18
|
we could see now we have the CA certificate, if we look at the
|
|
0:20:20
|
the do show crypto PKI certificates
|
|
0:20:23
|
we have the CA certificate that we can use for the signing
|
|
0:20:28
|
if we now do our enrollment, we say crypto
|
|
0:20:30
|
PKI
|
|
0:20:32
|
enroll
|
|
0:20:34
|
with router2
|
|
0:20:38
|
again any random password
|
|
0:20:40
|
I don't necessarily need to put the serial number, nor the ip address
|
|
0:20:44
|
but I do want to request their certificate
|
|
0:20:48
|
then the result should be
|
|
0:20:50
|
that the certificate was received, that the certificate was granted
|
|
0:20:55
|
we now again look at the
|
|
0:20:59
|
show crypto PKI certificates
|
|
0:21:03
|
I should see two separate ones
|
|
0:21:05
|
my router certificates
|
|
0:21:07
|
which is the general purpose one
|
|
0:21:09
|
and then the CA certificate which we are using for the sign
|
|
0:21:16
|
from the ASA's perspective
|
|
0:21:18
|
its going to be very similar here
|
|
0:21:20
|
we look at the show ntp status
|
|
0:21:22
|
I want to first make sure that my clock is synchronised
|
|
0:21:26
|
where router2 is the reference
|
|
0:21:28
|
if we show run ntp
|
|
0:21:31
|
we see its a very straight forward configuration, only one command, just what is the ntp server
|
|
0:21:39
|
next time going to configure the CA, so crypto
|
|
0:21:42
|
in this case its called crypto ca as opposed to crypto pki
|
|
0:21:47
|
the crypto ca trust point
|
|
0:21:49
|
I will say is router2
|
|
0:21:52
|
where the enrollment
|
|
0:21:55
|
url
|
|
0:21:57
|
just like the routers, I need to specify, how are we getting to router2
|
|
0:22:05
|
I need my public and private key pairs, so crypto
|
|
0:22:10
|
key generate RSA
|
|
0:22:20
|
then I am going to authenticate the CA and do the enrollment
|
|
0:22:24
|
So crypto
|
|
0:22:26
|
ca authenticate router2
|
|
0:22:32
|
got the certificate
|
|
0:22:33
|
and crypto
|
|
0:22:35
|
ca enroll
|
|
0:22:38
|
with router2
|
|
0:22:44
|
again I could include the serial number
|
|
0:22:46
|
I could include the ip address, I don't necessarily have to
|
|
0:22:49
|
as long as I request it
|
|
0:22:51
|
we could see that the ASA is generating a log
|
|
0:22:55
|
It created an outbound tcp connection, going to the server at port 80
|
|
0:22:59
|
thats because we are using SCEP
|
|
0:23:01
|
then the certificate has been granted
|
|
0:23:03
|
this is what I want to see
|
|
0:23:07
|
So now at this point all three of the end points
|
|
0:23:10
|
router1, router3 and the ASA
|
|
0:23:13
|
have properly done the enrollment
|
|
0:23:15
|
they have both the CA's certificate
|
|
0:23:18
|
and they have their own local certificates
|
|
0:23:22
|
Now the final step is to change our ISAKMP policy
|
|
0:23:27
|
to switch from the pre shared keys
|
|
0:23:29
|
to using RSA signature
|
|
0:23:32
|
where essentially on the router, this is only going to be one command
|
|
0:23:36
|
where when we go to router1
|
|
0:23:39
|
if we were to look at the
|
|
0:23:42
|
the show run section crypto
|
|
0:23:44
|
on our isakmp policy
|
|
0:23:47
|
we are going to change from saying
|
|
0:23:49
|
authentication pre shared
|
|
0:23:51
|
to authentication rsa-set
|
|
0:23:56
|
Now before I actually do this, one thing I want to check
|
|
0:24:00
|
is are the ipsec tunnels currently working
|
|
0:24:03
|
with the rest of the options, so the rest of the isakmp policy
|
|
0:24:07
|
the pre shared keys
|
|
0:24:10
|
the crypto
|
|
0:24:11
|
the crypto map which is made up of the transform
|
|
0:24:13
|
set, the proxy acl and the peer address
|
|
0:24:16
|
I want to make sure that there is nothing else
|
|
0:24:18
|
wrong with the ipsec config
|
|
0:24:20
|
before I introduce the extra complexity of the certificate authority
|
|
0:24:26
|
So to do this from switch2, I am going to ping router4
|
|
0:24:30
|
and from router6, I am going to ping router4
|
|
0:24:33
|
the end result if we look at router3
|
|
0:24:36
|
and look at the show crypto isakmp and the show crypto ipsec sa
|
|
0:24:41
|
which will see two separate tunnels
|
|
0:24:43
|
one from router3 to 1
|
|
0:24:46
|
another from router3 to the ASA
|
|
0:24:52
|
So on router6
|
|
0:24:54
|
I will ping 172.16.4.4
|
|
0:25:00
|
we see there is connectivity
|
|
0:25:02
|
and on switch2 likewise
|
|
0:25:03
|
ping 172.16.4.4
|
|
0:25:09
|
on router3, if I now look at the show crypto
|
|
0:25:12
|
isakmp sa
|
|
0:25:15
|
I have two separate tunnel
|
|
0:25:16
|
one of them, thats going to router1
|
|
0:25:19
|
and one of them, thats going to ASA
|
|
0:25:21
|
both of them say QM_IDLE
|
|
0:25:23
|
which can mean quick mode idle
|
|
0:25:25
|
phase I was complete and now going to phase II
|
|
0:25:29
|
we look at the show
|
|
0:25:31
|
crypto ipsec sa
|
|
0:25:35
|
I have one security association that is going towards router1
|
|
0:25:40
|
packets are getting encapsulated and decapsulated
|
|
0:25:44
|
and we should have a second tunnel thats going to the ASA
|
|
0:25:48
|
and likewise, the packets are
|
|
0:25:50
|
actually working
|
|
0:25:54
|
So next I am going to delete these tunnels
|
|
0:25:56
|
we will change the isakmp policy
|
|
0:25:58
|
and then look at the debugs of phase I
|
|
0:26:01
|
to make sure that the new authentication type is actually working
|
|
0:26:05
|
on router3, lets say
|
|
0:26:07
|
clear crypto isakmp
|
|
0:26:10
|
clear crypto sa
|
|
0:26:12
|
thats going to delete both our phase I and our phase II tunnel
|
|
0:26:17
|
same thing on router1
|
|
0:26:24
|
and on ASA
|
|
0:26:29
|
clear crypto isakmp and clear crypto
|
|
0:26:33
|
ipsec sa
|
|
0:26:38
|
Now on router1, lets say, show run section crypto
|
|
0:26:42
|
isakmp
|
|
0:26:43
|
I want to change the policy here
|
|
0:26:46
|
So as opposed to saying authentication pre shared
|
|
0:26:49
|
we will simply say authentication RSA-signatures
|
|
0:26:57
|
additionally we are going to look at the debug
|
|
0:26:59
|
debug crypto isakmp
|
|
0:27:03
|
on router3, we are going to do the same thing, show run section crypto isakmp
|
|
0:27:10
|
policy number 10 is changing from
|
|
0:27:13
|
authentication being pre shared
|
|
0:27:16
|
to RSA signature
|
|
0:27:19
|
then we will debug crypto
|
|
0:27:21
|
crypto isakmp
|
|
0:27:27
|
again we will initiate the tunnel
|
|
0:27:29
|
if we now look at the result of the debug, we have router1, being the initiator
|
|
0:27:34
|
and router3 being the
|
|
0:27:37
|
the responder
|
|
0:27:39
|
Now on switch2 we could see
|
|
0:27:41
|
that the ping did not actually go through
|
|
0:27:46
|
So lets look at the phase I negotiation and see exactly whats going on with the debug
|
|
0:27:51
|
what we can see now because if the tunnel previously was working
|
|
0:27:56
|
and the only thing that I changed
|
|
0:27:58
|
was to use the certificate authority
|
|
0:28:01
|
as opposed to using the pre shared keys
|
|
0:28:04
|
its very likely that there is something wrong with the CA config
|
|
0:28:08
|
or atleast the interaction between ipsec and the ca
|
|
0:28:11
|
versus the rest of the tunnel
|
|
0:28:15
|
so lets see what router1 did in the
|
|
0:28:17
|
the negotiation
|
|
0:28:19
|
says first we are starting the tunnel to router3
|
|
0:28:23
|
we are going to through main mode negotiation
|
|
0:28:27
|
which means that we are going to send the proposal
|
|
0:28:31
|
which we sent a propose lets says the attributes are acceptable, this is what we want to see
|
|
0:28:35
|
and the authentication is RSA signatures
|
|
0:28:39
|
the next step is that, once the proposal is accepted
|
|
0:28:42
|
we should now go on to the actual authentication
|
|
0:28:45
|
so router1 and 3 are going to check
|
|
0:28:47
|
do we agree on who the CA is
|
|
0:28:50
|
it should say that
|
|
0:28:53
|
we are using router2
|
|
0:28:56
|
trust point key pair to sign
|
|
0:29:01
|
sending it back to router3, this is main mode
|
|
0:29:04
|
key exchange, this is what we are doing the actual authentication
|
|
0:29:14
|
and lets see what router3
|
|
0:29:16
|
says
|
|
0:29:23
|
so router3 should be receiving the eproposal, lets undebug here
|
|
0:29:31
|
router3 receives the proposal, lets say the attributes are acceptable
|
|
0:29:35
|
the authentication is the RSA signatures, thats all we want to see
|
|
0:29:39
|
So next lets look whats going on when you are actually doing the authentication
|
|
0:29:47
|
we have the certificate request
|
|
0:29:50
|
the peer wants did you certificates, x.509 signatures
|
|
0:29:55
|
the peer wants the certificate that was issued by the
|
|
0:29:58
|
common name R2
|
|
0:30:00
|
which again, this is the key
|
|
0:30:02
|
that based on the subject
|
|
0:30:04
|
that is inside the CA's certificate
|
|
0:30:08
|
we know who is CA that we are trusting
|
|
0:30:13
|
So next we should actually see this the
|
|
0:30:17
|
certificate exchange
|
|
0:30:24
|
says the certificate is invalid or not yet valid
|
|
0:30:28
|
certificate change validation is changed
|
|
0:30:31
|
the validity period starts on 17.26.03
|
|
0:30:35
|
TC September 20th, 2011
|
|
0:30:40
|
what this means
|
|
0:30:42
|
as you probably guess is that there is a problem with the time
|
|
0:30:45
|
because I changed router3 previously to stop using ntp
|
|
0:30:51
|
Now it doesn't believe that router1 certificate
|
|
0:30:54
|
is within the current valid time
|
|
0:30:56
|
So if we look at the
|
|
0:30:58
|
the time
|
|
0:31:00
|
that router1 was sending there
|
|
0:31:03
|
which was
|
|
0:31:06
|
this value here, we look at the show clock
|
|
0:31:12
|
my clock 17:32:49
|
|
0:31:16
|
if we look at the show ntp status, right now I am unsynchronised
|
|
0:31:21
|
So lets try this, lets remove
|
|
0:31:25
|
router2 as the NTP server
|
|
0:31:32
|
then we will reapply the ntp config
|
|
0:31:57
|
and look at the show ntp status
|
|
0:32:02
|
this may take a few minutes here, what we want to see
|
|
0:32:05
|
is that the clock is going to change
|
|
0:32:07
|
from unsynchronised to synchronised
|
|
0:34:10
|
Now we can see from the output on router3 that
|
|
0:34:12
|
the clock is still not yet synchronised
|
|
0:34:15
|
but is slowly sewing closer and closer to the correct time
|
|
0:34:20
|
So from switch2, I have
|
|
0:34:22
|
sent the pings again
|
|
0:34:24
|
and since router3 now has the
|
|
0:34:26
|
the closer to correct time, not the 100% accurate time
|
|
0:34:30
|
but here atleast within the delivery period of the certificates
|
|
0:34:34
|
if we now look at the show crypto
|
|
0:34:37
|
isakmp sa
|
|
0:34:39
|
we could see that we now do have the tunnel
|
|
0:34:41
|
between router1 and router3
|
|
0:34:44
|
if we look at the result of the debug
|
|
0:34:49
|
lets try this again, lets say clear crypto
|
|
0:34:53
|
isakmp and clear crypto sa
|
|
0:34:56
|
on both router1 and router3
|
|
0:35:00
|
then we will look at the debug crypto
|
|
0:35:02
|
debug crypto isakmp
|
|
0:35:07
|
likewise on router1
|
|
0:35:14
|
then from switch2 we are going to generate the
|
|
0:35:18
|
the pings, now from the initiator, router1
|
|
0:35:22
|
we should see that once the
|
|
0:35:24
|
the certificate is found and exchanged
|
|
0:35:28
|
then it tells us that the authentication
|
|
0:35:30
|
is acceptable
|
|
0:35:35
|
where the sa authentication
|
|
0:35:37
|
status is authenticated, this is what we want to see
|
|
0:35:41
|
Now notice here, it gives us a couple of different
|
|
0:35:43
|
errors, it says that the
|
|
0:35:45
|
we are unable to get the distinguished name from the certificate
|
|
0:35:49
|
the certificate presented by the peer contains no
|
|
0:35:51
|
organizational unit field
|
|
0:35:54
|
so the peer matches none of the profiles
|
|
0:35:57
|
what this means
|
|
0:35:59
|
again as that those
|
|
0:36:00
|
fields inside of the subject
|
|
0:36:02
|
of the certificate
|
|
0:36:04
|
we can use them
|
|
0:36:05
|
to map to different tunnel groups
|
|
0:36:08
|
or in our case here, different
|
|
0:36:10
|
profiles for isakmp
|
|
0:36:12
|
in order to choose exactly
|
|
0:36:14
|
how one tunnel should be
|
|
0:36:15
|
processed versus another
|
|
0:36:18
|
but in this case since I didn't configured any of the advanced
|
|
0:36:21
|
options inside of the certificates
|
|
0:36:24
|
essentially router1 and router3
|
|
0:36:26
|
are matched each other's certificate
|
|
0:36:28
|
could be based on the ip address
|
|
0:36:31
|
that is the IKE identifier
|
|
0:36:34
|
and this is the
|
|
0:36:35
|
basically the address that is exchanged between them
|
|
0:36:38
|
when we are doing the phase I authentication
|
|
0:36:41
|
but the end result
|
|
0:36:43
|
that we saw is that the
|
|
0:36:45
|
authentication is successful
|
|
0:36:48
|
where router3 says
|
|
0:36:50
|
I am sending
|
|
0:36:52
|
my certificate to router1
|
|
0:36:55
|
then router1 should reply that
|
|
0:36:57
|
that says the
|
|
0:37:00
|
phase I is complete
|
|
0:37:01
|
So this means authentication was successfully
|
|
0:37:04
|
that we will see when we go the phase II negotiation which is talking about the
|
|
0:37:08
|
the crypto transform set
|
|
0:37:11
|
then we go down to actually built the ipsec sa
|
|
0:37:18
|
So next lets look at the tunnel between the ASA
|
|
0:37:21
|
and router3
|
|
0:37:23
|
where we are going to initiate
|
|
0:37:25
|
the traffic on router6
|
|
0:37:27
|
6 is going to be pinging router4
|
|
0:37:30
|
we saw previously that tunnel was functional
|
|
0:37:33
|
so if it is not working now, we know that it is related, specifically to
|
|
0:37:37
|
the, the PKI config
|
|
0:37:40
|
So both on router3
|
|
0:37:41
|
and the ASA
|
|
0:37:44
|
lets look at the
|
|
0:37:46
|
the debug
|
|
0:37:47
|
crypto isakmp
|
|
0:37:50
|
then on ASA we have logging on
|
|
0:37:53
|
and I am logging to the console
|
|
0:37:55
|
at level7
|
|
0:37:59
|
on router3, we already have the debug
|
|
0:38:01
|
crypto isakmp
|
|
0:38:11
|
next lets go to router6 and send
|
|
0:38:12
|
the packets toward 4
|
|
0:38:24
|
and again we can see previously the tunnel was working
|
|
0:38:27
|
now its not working
|
|
0:38:29
|
So something specific to the ca configuration or the PKI configuration is wrong
|
|
0:38:34
|
So now lets look at the debug, the ASA is the initiator
|
|
0:38:41
|
we go towards the top, it says, we are trying to build the tunnel
|
|
0:38:44
|
that is going towards router3
|
|
0:38:49
|
we should be now exchanging the phase I parameters
|
|
0:38:53
|
where it says
|
|
0:38:56
|
received an unencrypted
|
|
0:38:58
|
no proposal chosen notifying message
|
|
0:39:02
|
the information exchange processing has failed
|
|
0:39:07
|
Now we could see from the ASA, the debug output is
|
|
0:39:09
|
is generally not good as the router's is
|
|
0:39:12
|
it doesn't tell us specifically what is wrong
|
|
0:39:15
|
it just says that there is something wrong in the exchange
|
|
0:39:19
|
and phase I failed
|
|
0:39:22
|
if we look at router3, we may be able to get a little bit more information
|
|
0:39:26
|
as to exactly why the
|
|
0:39:28
|
the proposal didn't work
|
|
0:39:30
|
so lets look at router3
|
|
0:39:33
|
and it says, now the ASA is doing its proposal
|
|
0:39:37
|
it is saying, it want to do
|
|
0:39:38
|
pre shared authentication
|
|
0:39:41
|
but the authentication method offered does not match the policy
|
|
0:39:44
|
the attributes are not acceptable
|
|
0:39:46
|
so phase I policy is not acceptable
|
|
0:39:49
|
and actually the reason why, is I could have changed the
|
|
0:39:52
|
the isakmp policy on ASA
|
|
0:39:54
|
so lets say show run
|
|
0:39:57
|
show run crypto isakmp
|
|
0:40:02
|
for this policy just like on the router
|
|
0:40:04
|
we are going to change this, so it says, authentication is RSA signatures
|
|
0:40:13
|
on router6 lets initiate the ping again
|
|
0:40:27
|
ASA says I am trying to start
|
|
0:40:28
|
the tunnel to
|
|
0:40:38
|
see, it doesn't say its starting it to router3
|
|
0:40:40
|
but it says there is no valid IKE proposal
|
|
0:40:43
|
check IPSEC SA configuration
|
|
0:40:48
|
so we have a different error message now
|
|
0:40:51
|
but again its not very informative, doesn't really tell us exactly what the problem is
|
|
0:40:55
|
so lets see on router3
|
|
0:40:59
|
did we get any new
|
|
0:41:04
|
output here, lets look at the show crypto
|
|
0:41:07
|
isakmp sa
|
|
0:41:09
|
So we do not add the tunnel to the ASA
|
|
0:41:12
|
on the ASA, lets look at this again, show crypto
|
|
0:41:15
|
isakmp sa, there is no phase I
|
|
0:41:18
|
lets try to initiate the tunnel again
|
|
0:41:32
|
So there is no valid IKE proposal available, check the ipsec sa configuration
|
|
0:41:37
|
Now notice what has changed here
|
|
0:41:39
|
with the resulting output
|
|
0:41:42
|
I am no longer receiving a debug
|
|
0:41:45
|
on router3
|
|
0:41:48
|
what this means is that the ASA is no longer attempting to initiate the tunnel
|
|
0:41:55
|
So simply by changing my isakmp policy
|
|
0:41:58
|
something has now changed where the ASA is no longer allowed to initiate
|
|
0:42:04
|
So lets try to change this in the reverse manner
|
|
0:42:07
|
lets go to router4 and see if router4
|
|
0:42:09
|
can initiate the tunnel
|
|
0:42:11
|
in this direction, lets see if the ASA can receive it
|
|
0:42:15
|
so on router4, lets ping
|
|
0:42:18
|
10.0.6.6
|
|
0:42:23
|
router3 is trying to start the tunnel
|
|
0:42:26
|
ASA2 is receiving this
|
|
0:42:31
|
it says there is an error
|
|
0:42:32
|
that there is no trust point to find
|
|
0:42:35
|
for the tunnel group
|
|
0:42:39
|
and again remember I mentioned this previously
|
|
0:42:42
|
that one of the minor differences between the IOS config
|
|
0:42:45
|
for the RSA signatures and the ASA config
|
|
0:42:49
|
is that we need to associate it on a
|
|
0:42:51
|
per tunnel group basis
|
|
0:42:55
|
on the ASA if we were to look at the show run tunnel group
|
|
0:43:00
|
right the lan to lan
|
|
0:43:03
|
tunnel that we have, is named 200.0.23.3
|
|
0:43:08
|
if we look at the show run all tunnel group
|
|
0:43:12
|
and look at all of these default
|
|
0:43:14
|
lets say no logging on first
|
|
0:43:18
|
So show run all tunnel group
|
|
0:43:22
|
if we look under that specific tunnel
|
|
0:43:26
|
it says there is no trust point config
|
|
0:43:32
|
So we need to define this on a per tunnel basis
|
|
0:43:37
|
So who is the particular CA server that we are trying to do the authentication
|
|
0:43:41
|
So now under the tunnel group
|
|
0:43:44
|
tunnel group, the ipsec attributes
|
|
0:43:47
|
I need to say what
|
|
0:43:48
|
or who is the trust point
|
|
0:43:50
|
which in this case is router2, which we define
|
|
0:43:55
|
Now lets turn logging back on
|
|
0:44:01
|
we now initiate from router4 again
|
|
0:44:16
|
the ASA says that I found this suitable trustpoint that is router2
|
|
0:44:20
|
to validate their certificate
|
|
0:44:21
|
Certificate was successfully validated which is rack9r3.ine.com
|
|
0:44:27
|
Certificate chain was successfully validated with the warning because the
|
|
0:44:31
|
revocation status was not checked
|
|
0:44:33
|
this means that we do not
|
|
0:44:34
|
configured the CRL or Certificate Revocation list
|
|
0:44:38
|
which is okay, because we didn't configured that on the
|
|
0:44:41
|
the PKI server itself
|
|
0:44:45
|
however
|
|
0:44:47
|
it says we are now unable to compare the
|
|
0:44:49
|
the IKE identifier
|
|
0:44:51
|
against the peers certificate
|
|
0:44:54
|
its subject alternate name
|
|
0:44:57
|
Now remember as I mentioned
|
|
0:45:00
|
there is three main fields that we care about
|
|
0:45:03
|
in the certificate
|
|
0:45:05
|
we have the
|
|
0:45:07
|
the subject that is going to include
|
|
0:45:10
|
the common name
|
|
0:45:11
|
the alternate name
|
|
0:45:13
|
we have the public key
|
|
0:45:15
|
and then we have the certificate
|
|
0:45:17
|
authority's signature
|
|
0:45:20
|
what this is saying here, we can see that this error message down to at the bottom again
|
|
0:45:24
|
unable to compare the IKE identifier against the
|
|
0:45:27
|
peer's certificate subject alternate name
|
|
0:45:30
|
is that the ASA, when we look at
|
|
0:45:33
|
the show run
|
|
0:45:35
|
all tunnel group
|
|
0:45:39
|
the ASA says that
|
|
0:45:41
|
if you are doing
|
|
0:45:43
|
pre shared, excuse me, not pre shared, if you are doing RSA signatures
|
|
0:45:47
|
then the peers
|
|
0:45:49
|
the peer identifier
|
|
0:45:52
|
must be doubted against the certificate
|
|
0:45:55
|
which normally in a supposed to be
|
|
0:45:57
|
the hostname
|
|
0:45:59
|
that is inside the certificate
|
|
0:46:02
|
but the way that the routers doing this by default
|
|
0:46:04
|
is that the IKE identifier
|
|
0:46:06
|
is the ip address of the tunnel
|
|
0:46:11
|
now whichever way we configured it
|
|
0:46:13
|
it doesn't really matters, its going to work both ways
|
|
0:46:16
|
but we just need to make sure that the IOS and the ASA agree and how the tunnel is going to be configured
|
|
0:46:20
|
that either
|
|
0:46:22
|
the IOS needs to tell
|
|
0:46:24
|
the ASA
|
|
0:46:25
|
what the identifier is
|
|
0:46:27
|
to inside of the certificate
|
|
0:46:29
|
or we can tell the ASA to simply ignore this
|
|
0:46:33
|
we could go under the tunnel group ipsec attributes and then say no
|
|
0:46:36
|
peer id validate
|
|
0:46:38
|
request or I think it might be
|
|
0:46:40
|
peer id validate is not
|
|
0:46:42
|
as long as they are compatible
|
|
0:46:46
|
So on router3 we could go to global config and say that
|
|
0:46:49
|
crypto isakmp
|
|
0:46:52
|
identity
|
|
0:46:53
|
normally this is the ip address for the interface
|
|
0:46:57
|
but if I were to say that it is the distinguished name
|
|
0:47:01
|
which is the name of the router certificate
|
|
0:47:05
|
this is then what we are going to offer for the
|
|
0:47:07
|
the phase I identity
|
|
0:47:10
|
if we now look again at the
|
|
0:47:13
|
the debug crypto isakmp
|
|
0:47:16
|
and the same thing on router3 if we show debug
|
|
0:47:21
|
and initiate the tunnel
|
|
0:47:26
|
we should now see that router3
|
|
0:47:27
|
offers
|
|
0:47:30
|
its
|
|
0:47:39
|
as you could see here under debug
|
|
0:48:42
|
and here we could see the output, it says
|
|
0:48:44
|
that the
|
|
0:48:45
|
the connection landed on the tunnel
|
|
0:48:46
|
group 200.0.23.3
|
|
0:48:49
|
we identified the client's certificate within the chain
|
|
0:48:53
|
based on
|
|
0:48:54
|
the subject name or the distinguished name which is now their hostname
|
|
0:48:58
|
found a suitable trust point router2 to validate the certificate
|
|
0:49:01
|
then we are actually checking against with
|
|
0:49:03
|
the CA's certificate as compared router3's certificate
|
|
0:49:10
|
So again this is one option here where I could say I am router3
|
|
0:49:13
|
if we show run include crypto
|
|
0:49:18
|
that the
|
|
0:49:21
|
the crypto isakmp identifier
|
|
0:49:22
|
identifier or the identity is the distinguished name
|
|
0:49:25
|
the other option would be
|
|
0:49:27
|
so if I remove this here
|
|
0:49:29
|
the other option would be on the ASA to go
|
|
0:49:32
|
go to the tunnel group show run
|
|
0:49:35
|
tunnel group
|
|
0:49:36
|
say for this particular tunnel group
|
|
0:49:41
|
that
|
|
0:49:43
|
the peer id
|
|
0:49:46
|
peer id validation
|
|
0:49:47
|
is no check, so don't check against the certificate
|
|
0:49:51
|
this is another option
|
|
0:49:52
|
if we now clear crypto
|
|
0:49:56
|
isakmp
|
|
0:49:57
|
clear crypto ipsec sa
|
|
0:50:00
|
then on router3, the same thing, clear
|
|
0:50:03
|
crypto
|
|
0:50:04
|
sa, clear crypto isakmp
|
|
0:50:09
|
if we were to then
|
|
0:50:10
|
again initiate the tunnel
|
|
0:50:13
|
from router4
|
|
0:50:16
|
we can see the tunnel is still working
|
|
0:50:22
|
So now
|
|
0:50:23
|
our very last step, lets make sure that it is working in opposite direction
|
|
0:50:27
|
because remember one of the issues before
|
|
0:50:29
|
was that when I started the tunnel from 6
|
|
0:50:32
|
the ASA was not initiating it to router3
|
|
0:50:35
|
but it was working in the reverse direction
|
|
0:50:38
|
So when the ASA was receiving
|
|
0:50:41
|
the connection
|
|
0:50:43
|
it knew what to do with it
|
|
0:50:45
|
but when it was trying to initiate it, it did not
|
|
0:50:48
|
So one more time lets clear up the tunnel
|
|
0:50:51
|
config or the tunnel state
|
|
0:50:53
|
the clear crypto
|
|
0:50:56
|
isakmp
|
|
0:51:02
|
clear crypto isakmp and clear crypto sa
|
|
0:51:05
|
on the router
|
|
0:51:07
|
which is the equivalent of the clear crypto
|
|
0:51:10
|
isakmp and clear crypto ipsec sa
|
|
0:51:13
|
on the ASA
|
|
0:51:18
|
So then again lets test this from
|
|
0:51:20
|
router6
|
|
0:51:21
|
ideally we should see that the ASA
|
|
0:51:24
|
does initiate the connection
|
|
0:51:34
|
to router3
|
|
0:51:39
|
but it doesn't look like it is, lets say show debug here
|
|
0:51:44
|
and logging on
|
|
0:51:47
|
logging console 7
|
|
0:51:58
|
and we are again getting that same error message, it says there is no valid IKE
|
|
0:52:01
|
proposal available, check the ipsec sa configuration
|
|
0:52:07
|
Now notice here
|
|
0:52:09
|
that in this output
|
|
0:52:11
|
that the ASA does not know what is the
|
|
0:52:14
|
end point of the tunnel
|
|
0:52:16
|
no where in this debug does it say
|
|
0:52:18
|
200.0.23.3
|
|
0:52:22
|
where with the current configuration, the ASA is allowed
|
|
0:52:25
|
to receive the tunnel
|
|
0:52:27
|
but not initiate the tunnel
|
|
0:52:30
|
So lets look at its config, lets say show run crypto
|
|
0:52:38
|
and lets look at this step by step
|
|
0:52:40
|
Now we know that the phase I policy is correct
|
|
0:52:43
|
because we are able to accept
|
|
0:52:45
|
up to the connection from the other side
|
|
0:52:47
|
we have the RSA signatures authentication
|
|
0:52:50
|
the rest of the options, we know these are matching because the tunnel was working before
|
|
0:52:56
|
then we have the rest of the phase II parameters
|
|
0:52:59
|
we have the transform set
|
|
0:53:02
|
we have the peer
|
|
0:53:05
|
and we have the access list
|
|
0:53:08
|
if we look at the show run all
|
|
0:53:12
|
crypto map
|
|
0:53:16
|
and actually it doesn't show it here
|
|
0:53:18
|
but
|
|
0:53:19
|
there is actually two places on the ASA
|
|
0:53:23
|
that we need to define
|
|
0:53:24
|
who is the particular trust point that we are going to use
|
|
0:53:28
|
if the ASA is trying to initiate the tunnel
|
|
0:53:32
|
the trust point needs to be applied to the crypto map
|
|
0:53:37
|
when the connection is being received
|
|
0:53:40
|
when we hear the responder for IKE
|
|
0:53:43
|
the trustpoint needs to be configured inside of the tunnel group
|
|
0:53:47
|
So its two different directions, the tunnel group is for receiving the connection
|
|
0:53:51
|
the crypto map is for initiating it
|
|
0:53:54
|
So I need to say that for crypto map
|
|
0:53:56
|
sequence number 10
|
|
0:53:58
|
I need to set
|
|
0:53:59
|
the trust point
|
|
0:54:02
|
which in this case, the trust point is router2
|
|
0:54:07
|
So now again lets say logging
|
|
0:54:09
|
console
|
|
0:54:10
|
logging console 7, logging is on
|
|
0:54:13
|
and we are debugging crypto isakmp
|
|
0:54:22
|
Now if we look at the difference
|
|
0:54:25
|
we should see that
|
|
0:54:27
|
when the ASA starts the tunnel
|
|
0:54:33
|
it says we are going towards 200.0.23.3
|
|
0:54:38
|
and we should see that it says I am using
|
|
0:54:47
|
router2 as the trust point
|
|
0:54:52
|
So overall we can see the configuration is not that much different
|
|
0:54:56
|
from the, using the pre shared keys
|
|
0:54:58
|
the problem is that, there is just these minor caveats
|
|
0:55:02
|
that you need to be aware of
|
|
0:55:03
|
and if you don't try this out in the command line
|
|
0:55:07
|
it can be confusing to try to piece this together from the documentation
|
|
0:55:11
|
or we don't really know how to read the debug output
|
|
0:55:13
|
it can be confusing to figure out exactly whats wrong with
|
|
0:55:16
|
the certificate process
|
|
0:55:18
|
So is there an issue with the actual enrollment
|
|
0:55:21
|
or I am trying to get the CA certificate
|
|
0:55:23
|
and then I am trying to
|
|
0:55:24
|
to enroll my, myself and get my own certificate back
|
|
0:55:28
|
so there could be something wrong with the clock
|
|
0:55:31
|
could be something wrong with the transport for SCEP
|
|
0:55:34
|
which again is that http connection
|
|
0:55:38
|
or it could be something thats going on in the actual phase I policy
|
|
0:55:42
|
or may be the
|
|
0:55:44
|
the encryption, algorithm is matched
|
|
0:55:46
|
mismatched or may there is something wrong in the page 2 policy
|
|
0:55:49
|
the key i s
|
|
0:55:51
|
that there are so many potential issues that you can have with the
|
|
0:55:55
|
ipsec tunnels
|
|
0:55:56
|
that you need to be able to divide it
|
|
0:55:58
|
into a very modular configuration
|
|
0:56:01
|
that once we know
|
|
0:56:03
|
one piece works and then we could move on to the next one, and so on and so on and so on
|
|
0:56:07
|
but if we look at all of the configuration overall
|
|
0:56:10
|
it can be very difficult
|
|
0:56:12
|
to debug it
|
|
0:56:14
|
specially just by looking at the configuration lines
|
|
0:56:18
|
this is why it is so very important to spend a lot of time
|
|
0:56:21
|
looking through the output of the debug crypto isakmp
|
|
0:56:24
|
the debug crypto ipsec
|
|
0:56:26
|
and make sure we know
|
|
0:56:28
|
exactly how it is phase I
|
|
0:56:31
|
progress, or how should phase I progress or how should phase II progress
|
|
0:56:35
|
so that if there is a problem, we know exactly within the
|
|
0:56:39
|
the configuration or exactly within the negotiation
|
|
0:56:42
|
where we need to focus our troubleshooting on
|
