|
0:00:13
|
In our next section we are going to look at some trouble shooting of ipsec
|
|
0:00:17
|
lan to lan vpns on ios
|
|
0:00:20
|
or if two vpns that are configured
|
|
0:00:22
|
one that is between router 1
|
|
0:00:24
|
and router 3
|
|
0:00:26
|
and a another one that is between router
|
|
0:00:28
|
3 and router 5
|
|
0:00:30
|
but there are some minor problems
|
|
0:00:32
|
in the operation between them where the best majority that is configured
|
|
0:00:36
|
but they are not functioned
|
|
0:00:38
|
so as supposed to troubleshoot this by looking at just the configuration
|
|
0:00:42
|
we are to look at some of the show outputs and the debug outputs that we talked about previously
|
|
0:00:46
|
to see we could narrow down what are the problems
|
|
0:00:49
|
that are related to these two individual tunnels
|
|
0:00:54
|
so to review we talked about the basic verifications and troubleshooting
|
|
0:00:58
|
we would first want to start
|
|
0:01:00
|
to look at the
|
|
0:01:01
|
face one negotiation of the isakmp
|
|
0:01:03
|
to make sure that this was successful
|
|
0:01:05
|
and the first thing that we want to look at show cypto isakmp sa
|
|
0:01:10
|
and we want to know
|
|
0:01:10
|
does the security association say
|
|
0:01:13
|
qm_idle
|
|
0:01:14
|
for quick mode idle
|
|
0:01:16
|
meaning that phase one negotiation was correct
|
|
0:01:18
|
and that we are preceding onto phase 2
|
|
0:01:22
|
now if we do not see this sqm idle we can look at the debug proto isakmp
|
|
0:01:26
|
this is going to show us the individual steps that is going on in the negotiation process
|
|
0:01:31
|
so we will want to know is the authentication working
|
|
0:01:34
|
and if not we would check the key is or the certificate authority
|
|
0:01:38
|
and are the other attributes for isakmp i will say matching
|
|
0:01:43
|
so the debug is going to show us is there problem with the has
|
|
0:01:47
|
algorithm with the encryption
|
|
0:01:52
|
now if we look show cypto isakmp and it does show that the
|
|
0:01:56
|
the sa is the qm-idle
|
|
0:01:58
|
that means that you then need to look at the phase 2 negotiation
|
|
0:02:02
|
so we could look at the show crypto ipsec sa
|
|
0:02:05
|
and see are the packets actually getting
|
|
0:02:07
|
encrypted or decrypted
|
|
0:02:10
|
are beginning in capsulated and decapsulated
|
|
0:02:12
|
we would want to check this on both sides
|
|
0:02:15
|
this would tell us that if phase 2 negotiation is correct
|
|
0:02:20
|
but for some reason the packets aren't getting through
|
|
0:02:22
|
it could be some sort of filtering that is going on in data plan
|
|
0:02:26
|
now not of these corners are going up
|
|
0:02:28
|
we may look at the accesslist to make sure the proxy acl are correct
|
|
0:02:32
|
we could look at the debug ipsec
|
|
0:02:35
|
this is going to show us the individual negotiation steps
|
|
0:02:38
|
of the ipsec sa
|
|
0:02:42
|
so first lets look at the vpns that going on between router 1 and router 3
|
|
0:02:47
|
which likely had configured us before
|
|
0:02:52
|
it is used to encrypt traffic that is coming from the 192.168 segments
|
|
0:02:55
|
going to 172.16 network
|
|
0:02:59
|
so this were functional we should be able to switch to
|
|
0:03:02
|
and ping this lan interface of router 4
|
|
0:03:07
|
so lets start there to see
|
|
0:03:08
|
can the traffic actually get through on switch 2
|
|
0:03:12
|
we are going to ping 172.16.4.4
|
|
0:03:18
|
and we could see right now
|
|
0:03:20
|
this is not successful
|
|
0:03:23
|
now the next thing we may want to do
|
|
0:03:24
|
is to go to the n points
|
|
0:03:28
|
of the tunnels which in case are router 1 router 3
|
|
0:03:32
|
and look at show crypto
|
|
0:03:35
|
isakmp sa
|
|
0:03:38
|
notice that router 1 here says that
|
|
0:03:42
|
there is no state
|
|
0:03:44
|
for the tunnel
|
|
0:03:46
|
or essentially if says any thing other than qm-idle
|
|
0:03:50
|
it tells that there is a problem
|
|
0:03:52
|
we look at the same thing on router 3 that says show crypto
|
|
0:03:56
|
isakmp sa
|
|
0:03:59
|
it says that there is
|
|
0:04:01
|
a tunnel that is going to router 5
|
|
0:04:04
|
that is qm-idle
|
|
0:04:06
|
but there is not one that is going to router 1
|
|
0:04:09
|
the one from router 1 is the leader for some reason
|
|
0:04:14
|
now to refresh this information we could say
|
|
0:04:17
|
clear crypto
|
|
0:04:19
|
isakmp
|
|
0:04:21
|
on both router 1 and router 3
|
|
0:04:24
|
clear crypto isakmp
|
|
0:04:26
|
if we look at the show crypto isakmp sa
|
|
0:04:28
|
we could see now its the leader likewise on router 1
|
|
0:04:32
|
should be likewise to be leaded on
|
|
0:04:34
|
router 3 as well
|
|
0:04:36
|
this would be able one to start the
|
|
0:04:38
|
negotiation again from scratch
|
|
0:04:41
|
so we could see all of the output in the debug
|
|
0:04:43
|
likewise we could say clear crypto sa
|
|
0:04:47
|
this is would delete the phase 2 ipsec sa
|
|
0:04:51
|
we could also say for a particular spi
|
|
0:04:55
|
and match on the particular tunnel that we were trying to clear
|
|
0:04:59
|
and this case this is only two tunnels i can clear
|
|
0:05:04
|
so next on router 1 through look at the debug crypto
|
|
0:05:08
|
debug crypto isakmp
|
|
0:05:11
|
now its
|
|
0:05:12
|
its fairly likely here that the problem is related to phase one in this tunnel
|
|
0:05:19
|
because when i was sending the traffic i did not see the state being qmi
|
|
0:05:26
|
so debug crypto
|
|
0:05:29
|
crypto isakmp its likely that this is going to give me some more information about exactly whats going on
|
|
0:05:35
|
and Am going send these
|
|
0:05:37
|
these log messages directly to the consoles we will say login console
|
|
0:05:42
|
end with 7
|
|
0:05:46
|
login console 7
|
|
0:05:49
|
then again i will try to initiate the traffic from switch 2
|
|
0:05:53
|
going to router 4
|
|
0:05:56
|
now we could see that it did generate the debug output
|
|
0:06:01
|
both on router 1 and router 3
|
|
0:06:06
|
this tells me a little bit more about the situation of the network configuration
|
|
0:06:11
|
and in minimum
|
|
0:06:13
|
i now know the crypto map is properly applied
|
|
0:06:17
|
on both router 1 and router 3
|
|
0:06:20
|
the crypto map in on the wrong interface
|
|
0:06:23
|
then it would not initiate isakmp
|
|
0:06:27
|
additionally its telling me that the accesslist
|
|
0:06:30
|
that is used for the phase 2
|
|
0:06:33
|
is correct atleast on router 1
|
|
0:06:37
|
because remember that proxy acl of it proxy identity
|
|
0:06:41
|
is what controls the initiation of the crypto map
|
|
0:06:44
|
based on the fact that i originated traffic from the
|
|
0:06:50
|
182.168 address on switch 2
|
|
0:06:54
|
and this was triggering the debug up on router 1
|
|
0:06:56
|
that's going to tell me that the accesslist should be correctly matching
|
|
0:07:00
|
that source
|
|
0:07:05
|
so lets now look at router 1 & router 3 and see if can figure out some more information about this
|
|
0:07:10
|
i want to see what happened to router 1 when we try to intitiate the tunnel
|
|
0:07:15
|
it says that we are
|
|
0:07:19
|
staring a peer
|
|
0:07:21
|
negotiation with router 3
|
|
0:07:23
|
so least i know that the peers address is correct
|
|
0:07:28
|
say we are starting main mode
|
|
0:07:31
|
i send my first initial request
|
|
0:07:36
|
and iam now looking for the response
|
|
0:07:40
|
coming back in
|
|
0:07:44
|
say i receive the packet from router 3
|
|
0:07:48
|
notify as no hash it is rejected
|
|
0:07:52
|
i node input from message from peer
|
|
0:07:56
|
basically what this means
|
|
0:07:59
|
it doesn't have exactly what the problem is
|
|
0:08:01
|
but it tells us what ever information was in are initial request here
|
|
0:08:07
|
was rejected by router 3
|
|
0:08:10
|
does not why it was rejected just that
|
|
0:08:13
|
what ever option i am trying to using the tunnel
|
|
0:08:15
|
or
|
|
0:08:16
|
more than likely in the proposal
|
|
0:08:19
|
is something that router 3 does not have configured
|
|
0:08:23
|
so now i need to look at the debug on the responder
|
|
0:08:27
|
which is router 3 and see if its going to give us some more information about exactly whats going out in the tunnel
|
|
0:08:34
|
so lets look at the start of the negotiation here
|
|
0:08:38
|
says i receive the packet from router 1
|
|
0:08:45
|
iam now going to respond
|
|
0:08:48
|
to the first main mode message
|
|
0:08:54
|
so atleast we know that we have a peer configure to router 1
|
|
0:08:58
|
and then encrypt on the interface
|
|
0:09:01
|
its also telling it is nothing being filtered out at udp port 500
|
|
0:09:06
|
because router 1 is sending then us to 3 and getting them
|
|
0:09:10
|
3 is responding going back to 1
|
|
0:09:13
|
so there no transport problem in isakmp
|
|
0:09:17
|
say whats going on with the actual policies
|
|
0:09:22
|
say i am now checking
|
|
0:09:24
|
my isakmp policy
|
|
0:09:26
|
i have policy no. 10 and i have policy no. 20
|
|
0:09:31
|
for policy no. 10 i checked with router 1 send
|
|
0:09:35
|
but the encryption algorithm didn't match
|
|
0:09:38
|
so those attributes are not acceptable
|
|
0:09:41
|
this means that policy no. 10 i can not use it, i am now going to get on to the next one
|
|
0:09:48
|
for policy no. 20 its says likewise the encryption no. does not match
|
|
0:09:54
|
the attributes are not acceptable
|
|
0:09:57
|
no offers are accepted so the phase 1 security policy association is not acceptable
|
|
0:10:06
|
what this is telling us here
|
|
0:10:08
|
is that the attributes that router 1 has configured
|
|
0:10:12
|
does not match what router 3
|
|
0:10:15
|
is also using for that tunnel
|
|
0:10:18
|
now this necessarily tell us exactly what the difference is
|
|
0:10:22
|
it says the encryption does not match
|
|
0:10:24
|
there should potentially be other issues with the tunnel
|
|
0:10:27
|
but we atleast now know that this is the problem so phase 1 security association policy
|
|
0:10:34
|
so we are deleting the peer and then this is going to happen over and over and over
|
|
0:10:38
|
the router 1 tries to initiate the tunnel
|
|
0:10:42
|
router 3 does not find any matching isakmp Policies so it is rejected
|
|
0:10:48
|
now at this point what we may need to do is actually look at the configuration
|
|
0:10:52
|
i now want to know what is the isakmp policy
|
|
0:10:57
|
that router 3 has configured
|
|
0:10:59
|
and what are the policies that one
|
|
0:11:02
|
have configured, i will say show run
|
|
0:11:04
|
section isakmp policy
|
|
0:11:11
|
router 1 for policy no. 10
|
|
0:11:14
|
iam using mb 5 pre-share authentication and route no.5
|
|
0:11:19
|
now this no. here on router 1 does not have to match with router 3 has this a locally syn value
|
|
0:11:24
|
as long as the attributes themselves agree
|
|
0:11:28
|
so on router 3
|
|
0:11:31
|
i have a policy that is running
|
|
0:11:35
|
md 5 pre-share authentication on group 5
|
|
0:11:40
|
which is this one
|
|
0:11:43
|
we will notice that the encryption algorithm appears here
|
|
0:11:47
|
but not here on router 1
|
|
0:11:51
|
now if we look at the show crypto
|
|
0:11:54
|
isakmp policy
|
|
0:11:56
|
this is going to show us the details all
|
|
0:11:59
|
if we compare these between
|
|
0:12:02
|
router 1 and router 3
|
|
0:12:06
|
the difference is that router 1 is trying to use single
|
|
0:12:11
|
and router 3 is trying to use triple s
|
|
0:12:17
|
so this is one of the issues to start the attributes do not match
|
|
0:12:20
|
so i can change this now
|
|
0:12:22
|
lets see
|
|
0:12:24
|
if i were to say encryption
|
|
0:12:27
|
triple s lets see if this is going to fix it
|
|
0:12:31
|
and switch to lets send
|
|
0:12:34
|
send the packets again
|
|
0:12:43
|
3 now got a log message
|
|
0:12:46
|
its says crypto isakmp bad message
|
|
0:12:50
|
the IKE message from router 1 failed insanity check
|
|
0:12:56
|
or is now formed
|
|
0:13:01
|
now this is kind of a odd log message
|
|
0:13:05
|
and if we didn't earn exactly what this means its kind of hard to track this down
|
|
0:13:09
|
but essentially what it is saying
|
|
0:13:12
|
is that during the authentication process
|
|
0:13:15
|
i am essentially running
|
|
0:13:17
|
a hashed check agings the packet
|
|
0:13:21
|
that if my authentication is as same as yours
|
|
0:13:26
|
that the hashes should match up
|
|
0:13:32
|
so what router 1 is computing is its hash does it match what router 3 is using as its hash
|
|
0:13:36
|
so with the authentication they don't need exactly exchange the password for save
|
|
0:13:40
|
its more kind like of PP chat authentication works
|
|
0:13:44
|
or they are exchanging a hash value
|
|
0:13:46
|
you could compute your version of it in compared with mine
|
|
0:13:49
|
if they match then we can imply the authentication was successful
|
|
0:13:54
|
so its doesn't actually mean that there is something wrong with the packet
|
|
0:13:57
|
either there is wrong with the authentication
|
|
0:14:00
|
and if we look at the debug crypto isakmp again
|
|
0:14:09
|
lets also look at the show crypto isakmp sa
|
|
0:14:16
|
1 and 3
|
|
0:14:21
|
and lets to send packets again
|
|
0:14:23
|
what we may see that the
|
|
0:14:31
|
the show crypto isakmp sa
|
|
0:14:34
|
says that we are stuck in key change
|
|
0:14:39
|
this is one of the possible indication of an authentications of an authentication problem
|
|
0:14:45
|
but we look at the detail of debug here lets look on router 3
|
|
0:14:50
|
and lets look at the proposal process where
|
|
0:14:54
|
before we got to
|
|
0:14:56
|
the first portion of a main mode
|
|
0:14:59
|
we now go to the actual policy exchange the proposal process
|
|
0:15:03
|
router 3 now says the attributes are acceptable
|
|
0:15:07
|
so we are going to use policy,so we are using policy no.10
|
|
0:15:14
|
once the policy now agreed upon
|
|
0:15:17
|
now we actually go to the authentication process
|
|
0:15:20
|
we should see that
|
|
0:15:24
|
we found a preshare key for a neighbour
|
|
0:15:33
|
and the authentication is success for right now its saying, that
|
|
0:15:42
|
the message is now formed
|
|
0:15:48
|
so its a kind of obsure here because it doesn't comes straight out and tell us the authentication has failed
|
|
0:15:54
|
it just says that
|
|
0:15:56
|
we got to
|
|
0:16:00
|
the portion where
|
|
0:16:01
|
the basic security association is about to establish
|
|
0:16:04
|
because the proposal process was correct
|
|
0:16:07
|
but then we were trying to authenticate it and its not working
|
|
0:16:10
|
the end is this output here which is this send which i have failed
|
|
0:16:18
|
now if we look at the show run include crypto here
|
|
0:16:23
|
and compare this between router 3 and router 1
|
|
0:16:28
|
for pre-share key it should be pretty self explain to see if there is a problem here
|
|
0:16:33
|
or on router 1 its says it says this is the key we are using on router 3
|
|
0:16:38
|
router 3 is using
|
|
0:16:41
|
a different password with router 1
|
|
0:16:45
|
but again the problem is specially when the network starts to scale
|
|
0:16:49
|
we have multiple tunnels if we are trying to deal with
|
|
0:16:53
|
it can be hard to look at the output of the running config
|
|
0:16:55
|
and do it debug of it line by line
|
|
0:16:59
|
and again if this message either means that there is something wrong in the transit packet, like someone is trying to do
|
|
0:17:05
|
some sort of man and middle attack
|
|
0:17:07
|
but its more likely that this means
|
|
0:17:09
|
that there is a problem in the authentication
|
|
0:17:12
|
now for certificate authority that going to be a separate issue we will look at those debugs later
|
|
0:17:17
|
configure out what are the potential problems that we run into
|
|
0:17:20
|
but in general if
|
|
0:17:22
|
i have my certificate and you have your certificate
|
|
0:17:25
|
we both trust the ca
|
|
0:17:27
|
there is a much
|
|
0:17:29
|
more limited sets of problems we can run into with our same signatures
|
|
0:17:34
|
then we can with the
|
|
0:17:36
|
the pre-share key
|
|
0:17:41
|
so lets this now, lets change this to
|
|
0:17:44
|
the correct password
|
|
0:17:47
|
where router 1 is using the password cisco
|
|
0:17:52
|
router 3 was configured as the password cisco 1
|
|
0:17:57
|
so now if we try this again
|
|
0:18:01
|
then we could see its working so those two problems are ton between router 1 and router 3
|
|
0:18:06
|
one of the issues is that the isakmp attributes didn't match
|
|
0:18:10
|
the other issue was that the password did not match between for the authentication
|
|
0:18:19
|
now we have a 2nd tunnel
|
|
0:18:21
|
that is between router 3 and router 5
|
|
0:18:25
|
this one used to protect traffic between
|
|
0:18:28
|
this vlan 56 segment
|
|
0:18:31
|
and the vlan 4
|
|
0:18:34
|
the end points of the tunnel are router 3
|
|
0:18:37
|
and router 5
|
|
0:18:40
|
so i test this ideally i should be able to go to router 6
|
|
0:18:43
|
and send a ping
|
|
0:18:46
|
thats going to go
|
|
0:18:48
|
this way to router 4
|
|
0:18:50
|
and then ultimately get the responses back in
|
|
0:18:58
|
so to start lets actually try this out on the data plane
|
|
0:19:01
|
we ping the same address 172.16.4.4
|
|
0:19:08
|
and on router 5 lets look at the show
|
|
0:19:11
|
crypto isakmp i will say
|
|
0:19:18
|
remember again we are looking for this output
|
|
0:19:21
|
its should see the state is quick mode idle or qm-idle
|
|
0:19:27
|
this means that our phase 1 negotiation was correct
|
|
0:19:32
|
if we look at router 3 and do the same thing
|
|
0:19:35
|
say show crypto
|
|
0:19:38
|
isakmp sa
|
|
0:19:43
|
router 3 does not have a sa to router 5
|
|
0:19:49
|
what this most likely needs that i cleared the security association on 3 but not on 5
|
|
0:19:55
|
so basically i need to reset the tunnel
|
|
0:19:58
|
on router 5 i am going to say
|
|
0:20:00
|
clear crypto isakmp
|
|
0:20:05
|
also this message here
|
|
0:20:07
|
was an indication of the problem on router 3
|
|
0:20:10
|
says it received an ipsec
|
|
0:20:12
|
packet from an invalid i
|
|
0:20:15
|
so this was from tunnel router 5 previously had to router 3 had timed out
|
|
0:20:24
|
lets try this again, lets ping from 6
|
|
0:20:30
|
on 5 if we show crypto isakmp sa
|
|
0:20:36
|
so there is no state
|
|
0:20:39
|
so lets clear, lets say clear crypto sa
|
|
0:20:43
|
and the leave both the
|
|
0:20:45
|
both the phase 1 and the
|
|
0:20:48
|
the phase 2 sa
|
|
0:20:51
|
do this on 3 and 5
|
|
0:20:55
|
because remember the lifetimes on the re-key they are indefinite for phase 1 and phase 2
|
|
0:21:01
|
you could have phase 2 working and phase 1 cleared
|
|
0:21:05
|
but the packets will actually still go through because phase 2 is what actually control the
|
|
0:21:09
|
the final tunnel itself
|
|
0:21:17
|
now lets show crypto isakmp sa again
|
|
0:21:20
|
on router 5, 5 says to tunnel 3 is up
|
|
0:21:26
|
3 says to tunnel 5 is up
|
|
0:21:29
|
both of them are showing this in qm-idle this is what we want to see for phase 1
|
|
0:21:37
|
so looks like the BASIC negotiations of the tunnel was working
|
|
0:21:40
|
but the actual traffic is not getting through
|
|
0:21:44
|
so the next thing i want to look at is whats going on in phase 2
|
|
0:21:48
|
on router 3 lets look at the show crypto ipsec
|
|
0:21:54
|
sa
|
|
0:21:57
|
router 3 says i have a security association with router 5
|
|
0:22:03
|
i am receiving packets and im sending packets
|
|
0:22:08
|
so packets came in they were decapsulated
|
|
0:22:12
|
and packets were sent back out they were encapsulated
|
|
0:22:19
|
i have an inbound security association so this was received in from router 5
|
|
0:22:25
|
i also have a outbound security association this is what sent to 5
|
|
0:22:32
|
check the same thing on router 5 say show crypto
|
|
0:22:38
|
show crypto ipsec
|
|
0:22:41
|
sa
|
|
0:22:44
|
router 5 says i have a security association to router 3
|
|
0:22:50
|
i am encapsulating packets
|
|
0:22:54
|
but i am not de-capsulating packets
|
|
0:23:06
|
its says i have both on inbound and outbound security association
|
|
0:23:13
|
but for reason iam not receiving packets back in
|
|
0:23:21
|
this type of output is then typically an indication of what type of problem
|
|
0:23:33
|
this would be something in the data plan
|
|
0:23:37
|
now we look at the topology here
|
|
0:23:40
|
again we are trying to get packets to go from 6 to 5
|
|
0:23:44
|
5 is sending them in the tunnel to 3
|
|
0:23:50
|
5 is saying that the packets got encapsulated
|
|
0:23:55
|
they got to 3
|
|
0:23:57
|
3 said they got decapsulated
|
|
0:24:02
|
|
|
0:24:09
|
now if we would go to router 4
|
|
0:24:11
|
and look at the
|
|
0:24:14
|
debug ip icmp
|
|
0:24:17
|
we should see that these packets are actually getting from 6 to 4
|
|
0:24:24
|
4 is getting them and 4 is responding
|
|
0:24:27
|
but 6 is never receiving the response back and you can see this because the thing is zero percent success
|
|
0:24:38
|
so something here is going under the topology where the packets are going
|
|
0:24:41
|
in this direction
|
|
0:24:45
|
and then back
|
|
0:24:47
|
where they are getting lost somewhere beyond that
|
|
0:24:55
|
so now we need to think about
|
|
0:24:57
|
what are the different portions that make up the tunnel here
|
|
0:25:01
|
now we know that there is the phase one
|
|
0:25:05
|
the phase 1 negotiation which is using udp port 500
|
|
0:25:11
|
then for phase 2 we establish the actual tunnel that is for the data plan
|
|
0:25:16
|
this is either going to be esp
|
|
0:25:20
|
or its going to be ah
|
|
0:25:25
|
esp used ip protocol
|
|
0:25:28
|
no. 50
|
|
0:25:30
|
where authentication header this uses ip protocol no. 51
|
|
0:25:36
|
so this means that for the tunnel to work we need to make sure that those two different flows that are allowed in the network
|
|
0:25:43
|
udp 500 and ip no. 50
|
|
0:25:47
|
or udp 500 and ip no. 51
|
|
0:25:52
|
depending on what the transform says if it says esp it needs to be protocol 50 if its aa it needs to be protocol 51
|
|
0:26:01
|
now notice here in the topology that we have
|
|
0:26:05
|
an asa
|
|
0:26:07
|
this is the inside network this is the outside network
|
|
0:26:11
|
where we know the way the asa works the traffic is allowed to go from the high security to low
|
|
0:26:18
|
in the out but it can only return
|
|
0:26:23
|
if either the traffic was inspected
|
|
0:26:27
|
or there is an exception with the accesslist filter
|
|
0:26:33
|
so lets go to router 6 and
|
|
0:26:36
|
lets continue to send this packets lets do
|
|
0:26:40
|
lets do an extended thing lets ping 172.60.4.4
|
|
0:26:45
|
with a high peek out we keep this going
|
|
0:26:49
|
we will then go to asa 2 here
|
|
0:26:53
|
and lets say
|
|
0:26:59
|
we then go to asa 2 here
|
|
0:27:04
|
and lets turn the login on
|
|
0:27:07
|
so login console level 7 and login is on
|
|
0:27:17
|
the asa is saying im denying inbound
|
|
0:27:19
|
on the outside interface
|
|
0:27:22
|
protocol no. 50
|
|
0:27:25
|
that came from
|
|
0:27:27
|
200.0.23.3
|
|
0:27:30
|
going to 10.0.125.5
|
|
0:27:35
|
so its dropping the tunnel returning from router 3 going back to 5
|
|
0:27:43
|
and the reason this is happening
|
|
0:27:45
|
as i mentioned before the phase 2 security association
|
|
0:27:49
|
is 2 unidirectional sa's
|
|
0:27:54
|
where the phase 1 sa
|
|
0:27:57
|
is a bidirectional udp port 500
|
|
0:28:00
|
so what happening here is, that if you establish a tunnel
|
|
0:28:04
|
from behind some sort of filtering device
|
|
0:28:07
|
router 6 sends the ping to 5
|
|
0:28:12
|
5 sends the ike message which is udp 500
|
|
0:28:20
|
this moves from the inside to the outside asa
|
|
0:28:24
|
and an entry is made in the state table
|
|
0:28:28
|
so the asa knows when 3 returns this ike packet
|
|
0:28:34
|
its still udp 500, it should be allowed from outside to in
|
|
0:28:39
|
once phase 1 is complete we don't need the udp 500 any more
|
|
0:28:43
|
then 5 sends the ipsec message
|
|
0:28:49
|
this is using esp
|
|
0:28:51
|
which is ip protocol no. 50
|
|
0:28:54
|
router 3 likewise tries to return this esp packet
|
|
0:28:58
|
this is the one that is getting dropped
|
|
0:29:05
|
now there is a couple of ways that we can solve this depending on what type of device is dropping the packet
|
|
0:29:11
|
in the case of the routers ios
|
|
0:29:14
|
we will have to simply do a manual accesslist exception
|
|
0:29:18
|
to say allow protocol no. 50
|
|
0:29:22
|
to come from the outside and move back in
|
|
0:29:26
|
we could likewise do this in the case of asa
|
|
0:29:29
|
or we have a another option
|
|
0:29:32
|
and we are going to look at this again additionally when we go through the remote access vpn
|
|
0:29:36
|
and go through passing the easy vpn point
|
|
0:29:39
|
through the asa modular policy framework
|
|
0:29:43
|
and what we can do as well when we turn off login
|
|
0:29:47
|
lets say show run all policy map
|
|
0:29:52
|
where right now we have the default inspection policy
|
|
0:29:58
|
that is applied globally
|
|
0:30:02
|
if we look at the show connections all
|
|
0:30:06
|
we have the esp
|
|
0:30:10
|
that is
|
|
0:30:13
|
coming from the inside going to the outside
|
|
0:30:20
|
and right now we don't have the udp port 500 lets clear the security associations again
|
|
0:30:25
|
lets say
|
|
0:30:27
|
clear crypto sa and clear crypto isakmp
|
|
0:30:35
|
will see this on both 5 and 3
|
|
0:30:41
|
now 6 is still running its ping so its should re-initiate the session
|
|
0:30:45
|
we will look at the connections on the asa
|
|
0:30:48
|
we should now see
|
|
0:30:50
|
the upd port 500 match
|
|
0:30:54
|
so it came from 5
|
|
0:30:56
|
originally it when to 3, now the session is returning from outside to back in
|
|
0:31:03
|
the esp packets are also in the inspection table
|
|
0:31:08
|
where the problem is the asa is not going to allow them by default
|
|
0:31:14
|
so the way we could fix this is go to the default inspection policy
|
|
0:31:22
|
we have policy map global policy class inspection_default
|
|
0:31:25
|
and we want to inspect ipsec pass-thru
|
|
0:31:31
|
this is for when we have clients on the inside
|
|
0:31:36
|
then trying to establish either esp or aah based tunnels
|
|
0:31:42
|
to devices on the outside
|
|
0:31:46
|
now we will see its not going to be the same of someone who is trying to run transparent tunnel
|
|
0:31:51
|
with either not transparency
|
|
0:31:54
|
or ipsec or udp or ipsec over tcp
|
|
0:32:00
|
this is on only when we are natively trying to run the tunnel directly over the esp or ah
|
|
0:32:05
|
and we want to allow the protol 50 to out and come back in
|
|
0:32:09
|
or 51 to go out and come back in
|
|
0:32:12
|
so if we look at 6 we should now see
|
|
0:32:16
|
once the tunnel is reestablished i need to regenerate the security association again
|
|
0:32:40
|
and may need to remove the policy on asa and reapply it
|
|
0:32:49
|
lets look at 5 and say show crypto isakmp sa
|
|
0:32:53
|
we have the phase tunnel of
|
|
0:32:58
|
router 3 likewise as phase 1 tunnel
|
|
0:33:03
|
we will show crypto isakmp sa
|
|
0:33:09
|
we are receiving and sending packets
|
|
0:33:13
|
if i say show crypto ipsec sa
|
|
0:33:21
|
we are sending but not receiving packets
|
|
0:33:24
|
this means that the asa is still dropping this gets turn logging back on lets say login
|
|
0:33:30
|
console 7 login on
|
|
0:33:35
|
deny inbound 50
|
|
0:33:38
|
what you did you in here is most likely then is to remove the policy and then reapply it
|
|
0:33:44
|
we will see is start again into to these more complicated scenarios
|
|
0:33:48
|
where we have the ipsec and filtering going on at the same time
|
|
0:33:53
|
some times we will see cases where you need to remove your firewall policy when you apply it
|
|
0:33:59
|
or to remove your vpn policy
|
|
0:34:02
|
which would be like to remove the crypto map when we apply it
|
|
0:34:06
|
or as a worst case scenario
|
|
0:34:08
|
you can reload the router, reload the asa and see if that fixes it
|
|
0:34:13
|
but sometimes it just needs to restart the process
|
|
0:34:16
|
and taking the crypto map off is doing to do that
|
|
0:34:19
|
so lets say here show run policy map
|
|
0:34:23
|
i am inspecting ipsec
|
|
0:34:27
|
but its not actually applied so lets say
|
|
0:34:30
|
show run service-policy
|
|
0:34:37
|
and try removing
|
|
0:34:42
|
the global inspection policy
|
|
0:34:47
|
then re-applying it
|
|
0:34:55
|
and then lets see restarting the tunnel
|
|
0:34:58
|
we will clear crypto isakmp and clear crypto sa
|
|
0:35:03
|
on both 3 & 5
|
|
0:35:10
|
and on asa we look at the show connections
|
|
0:35:15
|
and still we some of those left in those, lets say clear
|
|
0:35:19
|
are connections all
|
|
0:35:27
|
so right now there is no transit packets so lets
|
|
0:35:29
|
i cannot router 6 to send these packets
|
|
0:35:34
|
and now they start to go through, so
|
|
0:35:36
|
for the last portion here there is nothing i changed to the configuration other than just removing the policy and then re-applying it
|
|
0:35:42
|
and clearing the tunnels
|
|
0:35:43
|
this is to make sure that the asa saw all the of the negotiation
|
|
0:35:47
|
for both phase 1 and phase 2
|
|
0:35:50
|
so it knows what to allow back in from the outside interface
|
|
0:35:56
|
now the other alternative to this
|
|
0:35:58
|
as opposed to saying inspect ipsec pass through
|
|
0:36:02
|
because this is only now going to work inside out and then returning
|
|
0:36:07
|
so for example if i were to go to 3 & 5 lets clear the tunnel again
|
|
0:36:17
|
clear the tunnel on both of them
|
|
0:36:19
|
if i go to router 4
|
|
0:36:23
|
if i go to router 4 and we ping 10.0.56.6
|
|
0:36:29
|
sourcing traffic from 172.16.4.4
|
|
0:36:42
|
what we should see
|
|
0:36:45
|
is that this is going to be
|
|
0:36:48
|
denied, lets look at 5 and say show
|
|
0:36:53
|
crypto isakmp sa
|
|
0:36:57
|
we have the tunnel from 3 lets try to clear these again
|
|
0:37:08
|
and lets take a look at the asa lets say show run accesslist
|
|
0:37:13
|
so the asa is not statickly permitting anything in
|
|
0:37:16
|
lets also say clear connections all
|
|
0:37:26
|
what we should see is that when 4 tries to intitiate the tunnel
|
|
0:37:30
|
and if we look at the diagram the difference here
|
|
0:37:33
|
is that previously
|
|
0:37:35
|
the tunnel started at
|
|
0:37:38
|
6, went to 5, 5 send the tunnel to 3
|
|
0:37:43
|
from the asa this was coming from in to out
|
|
0:37:46
|
so this is allowed
|
|
0:37:47
|
then the return traffic
|
|
0:37:49
|
is allowed as well, because it is a response
|
|
0:37:52
|
to something that is already inspected
|
|
0:37:55
|
but now in this case iam coming from the outside and going unsolicited to the inside
|
|
0:38:02
|
so its a ping here from 4 to 3
|
|
0:38:07
|
but then from 3 to the asa this is udp 500
|
|
0:38:13
|
we should see this is going to be dropped outside in
|
|
0:38:19
|
if we look at the asa
|
|
0:38:21
|
and turn login back on, logging console 7 login on
|
|
0:38:28
|
and send these pings
|
|
0:38:32
|
the asa is going to say that udp 500 was dropped
|
|
0:38:39
|
so this means with the that the configuration that is for inspecting the ipsec pass through
|
|
0:38:44
|
this is only going to help you if the tunnel is initiated from the inside going to the outside
|
|
0:38:50
|
if we are going the other way around
|
|
0:38:52
|
or we don't want to say inspect ipsec pass through
|
|
0:38:54
|
what we need to do is say
|
|
0:38:57
|
accesslist outside in
|
|
0:39:00
|
permit udp
|
|
0:39:02
|
we will say no log in on
|
|
0:39:06
|
accesslist outside in permit udp any any equal to 500
|
|
0:39:12
|
and, of course we could be more specific we would say end point to the tunnel
|
|
0:39:17
|
but as a general case permit udp 500
|
|
0:39:21
|
and permit esp
|
|
0:39:23
|
and permit ah if you are using ah in the transform set
|
|
0:39:28
|
then ip access group
|
|
0:39:31
|
outside in in interface outside
|
|
0:39:36
|
it was access group
|
|
0:39:38
|
then we look at the show accesslist
|
|
0:39:44
|
when we try initiate the tunnel from the outside in
|
|
0:39:51
|
now its going to be allowed
|
|
0:39:53
|
if we look on the asa
|
|
0:39:56
|
with the traffic is allowed
|
|
0:39:59
|
here with udp
|
|
0:40:01
|
then eventually were are going to get the hits on
|
|
0:40:06
|
the esp flows as well
|
|
0:40:14
|
so from show accesslist, eventually once the hit count updates
|
|
0:40:19
|
for the acl we would see matches here for line no.2
|
|
0:40:26
|
so you could see even for the most basic tunnel configuration
|
|
0:40:31
|
there are a lot of different variables that we need into account
|
|
0:40:35
|
so first step did the phase negotiation work
|
|
0:40:39
|
so for phase 1 again this is going to be the isakmp sa
|
|
0:40:45
|
which is going to using udp 500
|
|
0:40:48
|
so first step is the transport work
|
|
0:40:50
|
if udp 500 is filtered out doesn't matter what the attributes say
|
|
0:40:55
|
if the transport is working then we need to look at the policy
|
|
0:40:58
|
does the authentication, the encryption, the hash algorithm, and the dp 100 group match
|
|
0:41:06
|
if the policy is acceptable did the authentication actually work
|
|
0:41:10
|
if so then we go on to phase 2 which is the ip sa
|
|
0:41:16
|
the end result of this is either going to be esp which is using ip protocol no. 50
|
|
0:41:22
|
or it is going to use ah which is using ip protocol no. 51
|
|
0:41:28
|
we need to make sure not only the transform set agrees
|
|
0:41:32
|
like i were using esp or ah or using aes
|
|
0:41:36
|
mp 5 sha etc.
|
|
0:41:40
|
do the proxy acls match
|
|
0:41:42
|
so are they mere images of each other
|
|
0:41:45
|
are the peer addresses correct
|
|
0:41:47
|
and finally is this traffic flow actually allowed
|
|
0:41:50
|
|
