|
0:00:13
|
In our next section we are going to take a look at some configuration examples on the ASA
|
|
0:00:18
|
for the IPSec LAN-to-LAN VPNs
|
|
0:00:21
|
specifically in this case, we are going to be configuring a LAN-to-LAN VPN from ASA2
|
|
0:00:27
|
to router3, that is going to protect traffic coming from the 10 network
|
|
0:00:32
|
going to the 172.16
|
|
0:00:35
|
network behind router3
|
|
0:00:38
|
now as I mentioned previously
|
|
0:00:40
|
a lot of the configuration for the ASA tunnel is similar to the IOS
|
|
0:00:45
|
with the exception of the tunnel group and the group policy
|
|
0:00:50
|
so we still need to find our basic phase I parameters with the ISAKMP policy
|
|
0:00:56
|
we need to define our phase II parameters
|
|
0:00:59
|
which are the transform set
|
|
0:01:01
|
the proxy acl and the pure address inside of the crypto map
|
|
0:01:06
|
but then any of the specific
|
|
0:01:08
|
ISAKMP parameters like the pre shared key, the certificate authority
|
|
0:01:12
|
those need to be defined in the tunnel group
|
|
0:01:17
|
So next lets take a look at router3
|
|
0:01:20
|
and I have the basic tunnel template configured
|
|
0:01:24
|
that router3 is going to be accepting the traffic inbound
|
|
0:01:28
|
so if we look at the show run section crypto or
|
|
0:01:32
|
access list
|
|
0:01:35
|
or interface
|
|
0:01:39
|
we have an ISAKMP policy
|
|
0:01:42
|
that says the encryption is AES
|
|
0:01:44
|
the authentication is pre shared
|
|
0:01:47
|
and the group number is 5
|
|
0:01:51
|
Now notice that it is not list with the hash algorithms
|
|
0:01:55
|
so we would want to look at the output of the
|
|
0:01:58
|
the show crypto ISAKMP policy
|
|
0:02:04
|
to figure out what the particular hashing is, which in this case is SHA
|
|
0:02:09
|
Now the reason that it is so important
|
|
0:02:11
|
as that we were to take this exact policy from the router and paste it onto the ASA
|
|
0:02:16
|
we will see that in certain versions, there are differences in the default
|
|
0:02:21
|
authentication, encryption
|
|
0:02:23
|
hashing and diffy halman group
|
|
0:02:25
|
So if the ASA was using a default hash with md5
|
|
0:02:30
|
but the router was using a default hash with SHA
|
|
0:02:33
|
then the policies are not going to match up
|
|
0:02:36
|
so when we actually configure this, we are going to list all four of the attributes
|
|
0:02:42
|
Now just like we did previously with the router's configurations
|
|
0:02:46
|
we are going to look at these two configs step by step
|
|
0:02:49
|
and , or side by side, I should say
|
|
0:02:51
|
to make sure that we are not leaving one attribute out
|
|
0:02:54
|
of the router's side versus the ASA side
|
|
0:02:59
|
So again we know the first step is going to be our phase I policy
|
|
0:03:03
|
and this is router3's config
|
|
0:03:06
|
so we have the ISAKMP policy, its number 10
|
|
0:03:08
|
encryption is AES
|
|
0:03:10
|
authentication is pre shared, group number 5
|
|
0:03:13
|
and the hash is SHA
|
|
0:03:17
|
Now also notice that the AES encryption
|
|
0:03:21
|
it doesn't tell us what the key length is
|
|
0:03:24
|
so if I am using 128 bit
|
|
0:03:27
|
but you are using 256 bit
|
|
0:03:29
|
then the encryption algorithms are not going to match
|
|
0:03:32
|
so we can see this again when we look at the show
|
|
0:03:35
|
crypto ip policy
|
|
0:03:37
|
says we are using AES but we are using AES 128
|
|
0:03:41
|
so we may want to add that on that, where its says encryption aes is 128
|
|
0:03:48
|
next thing we have is the authentication for phase I
|
|
0:03:52
|
in this case we are doing it as pre shared
|
|
0:03:54
|
which means that the neighbours are going to have to agree on what actually is the key
|
|
0:04:00
|
router3 says that for this particular neighbour
|
|
0:04:05
|
which is the , this is the ASA's address
|
|
0:04:07
|
we are going to use the key of cisco
|
|
0:04:12
|
we then need our phase II parameters
|
|
0:04:15
|
which again are going to be, who is the tunnel going to
|
|
0:04:19
|
what is going in the tunnel and how is it going to be treated
|
|
0:04:23
|
where who is defined by the crypto map
|
|
0:04:27
|
which is the set peer
|
|
0:04:29
|
the how is defined by the transform set
|
|
0:04:32
|
and the what is defined by the
|
|
0:04:35
|
the access list, here we are using access list 100
|
|
0:04:40
|
if we show run section access list
|
|
0:04:47
|
access list 100 says its traffic coming from the 172.16 network
|
|
0:04:52
|
going to the 10 network
|
|
0:04:55
|
Now your call when we change this configuration on to the ASA
|
|
0:04:59
|
we need to make sure that the access list are a mere image
|
|
0:05:03
|
where the asa is going say that the source
|
|
0:05:06
|
is the 10 network
|
|
0:05:09
|
and the destination is 172.16.0.0/16
|
|
0:05:15
|
where router3 needs to say the opposite of this, its going to say the source
|
|
0:05:19
|
is the 172 network
|
|
0:05:21
|
and the destination is the 10 network
|
|
0:05:25
|
so the proxy acls, they always need to be mere images of each other
|
|
0:05:35
|
okay, so again next we have our transform set
|
|
0:05:38
|
we have the
|
|
0:05:40
|
the peer address thats defined by the crypto map
|
|
0:05:43
|
and then we have the
|
|
0:05:46
|
the actual access list
|
|
0:05:57
|
then unless this router3 has this bound to
|
|
0:06:01
|
the interface, with the crypto map command
|
|
0:06:09
|
Now we will see, syntax wise, on the ASA, a lot of these is going to be very similar
|
|
0:06:16
|
but again we do need to be aware of what are the differences in the defaults
|
|
0:06:20
|
so when we define the
|
|
0:06:22
|
the ISAKMP policy
|
|
0:06:24
|
I want to make sure that I am listing all four of these options
|
|
0:06:28
|
now for the security association lifetime
|
|
0:06:31
|
we may have a difference between them based on the defaults
|
|
0:06:34
|
but it shouldn't make an operational difference
|
|
0:06:37
|
because we call the SA lifetimes
|
|
0:06:39
|
both for phase I and phase II
|
|
0:06:42
|
are going to be negotiated down to the lower of the value
|
|
0:06:46
|
so if the ASA is using a shorter life time than the router is
|
|
0:06:49
|
we are going to use the ASA's value
|
|
0:06:50
|
and vice versa, router3 is using lower than the ASA then we are going to use that one
|
|
0:06:56
|
so most of these is going to be the same
|
|
0:06:58
|
with the exception of the ISAKMP key
|
|
0:07:02
|
this is going to change to a tunnel group
|
|
0:07:08
|
now you will also see that under ASA
|
|
0:07:11
|
that if we were to enter the syntax this way, if I were to say
|
|
0:07:14
|
that the ISAKMP key is cisco
|
|
0:07:16
|
and the address is 200.0.23.3
|
|
0:07:21
|
which is router3's address
|
|
0:07:24
|
and I am going to change this into the crypto map as well
|
|
0:07:27
|
that are automatically convert this syntax into a tunnel group
|
|
0:07:33
|
so if you accidentally copy and paste the router's config to the ASA
|
|
0:07:37
|
the ASA is automatically going to change it around
|
|
0:07:40
|
to use the tunnel groups syntax
|
|
0:07:44
|
the other change we need to make here is to change the access list
|
|
0:07:48
|
So that the source is the 10 network
|
|
0:07:51
|
and the destination is the 172.16
|
|
0:07:56
|
we will also see that the crypto map syntax is a little bit different
|
|
0:08:00
|
where we specify these options on individual lines
|
|
0:08:05
|
so instead of saying cryto map
|
|
0:08:07
|
cyrpto, give it a sequence number
|
|
0:08:10
|
then we go to the sub configuration mode
|
|
0:08:12
|
in the a ASA we need to set this individually
|
|
0:08:15
|
so we will have
|
|
0:08:16
|
a line that says set the peer
|
|
0:08:18
|
or a line that says set the transform set
|
|
0:08:20
|
and the line that says match the address
|
|
0:08:25
|
then as opposed to applying this on the interface directly
|
|
0:08:29
|
we are going to say for this crypto map
|
|
0:08:32
|
what interface is it applied to, in this case, this is going to go to the outside
|
|
0:08:39
|
then lastly we need to make sure that ISAKMP is actually on
|
|
0:08:42
|
where in the IOS this automatically is on
|
|
0:08:45
|
as soon as you apply the crypto map
|
|
0:08:47
|
but in the case of the ASA
|
|
0:08:49
|
this is not
|
|
0:08:50
|
so we need to say crypto
|
|
0:08:52
|
ISAKMP enable
|
|
0:08:54
|
and I want it on
|
|
0:08:56
|
the outside interface
|
|
0:09:04
|
so lets see if this syntax is correct now
|
|
0:09:16
|
so couple of different error messages
|
|
0:09:18
|
first one it says for AES
|
|
0:09:21
|
it doesn't like the argument of 128
|
|
0:09:25
|
for the access list, it says that 100.0.0,
|
|
0:09:29
|
0.255.255.255 doesn't pair
|
|
0:09:34
|
what this is means is that
|
|
0:09:36
|
we are referencing a wild card mask here
|
|
0:09:39
|
when we should be referencing a subnet mask
|
|
0:09:43
|
so remember there is a syntax difference between ASA, ACLs
|
|
0:09:47
|
versus the router ACLs
|
|
0:09:49
|
So I should say 10 and then 255.0.0.0
|
|
0:09:54
|
172.16.0.0
|
|
0:09:57
|
255.255.0.0
|
|
0:09:59
|
so we want a subnet mask, not a wild card mask
|
|
0:10:11
|
so the rest of it looks good with the exception of the ISAKMP policy
|
|
0:10:14
|
so lets say show run
|
|
0:10:17
|
crypto ISAKMP policy 10
|
|
0:10:25
|
and we could see it says, the default encryption is 3DES
|
|
0:10:29
|
so we need to change this, so that we are using
|
|
0:10:32
|
AES
|
|
0:10:34
|
and if we do say AES, its going to use 128
|
|
0:10:37
|
So in the case of ASA, we do not need to add that additional
|
|
0:10:40
|
the additional argument
|
|
0:10:44
|
Now if we look at the final result of this, if we say show run
|
|
0:10:47
|
all crypto
|
|
0:10:51
|
we could see some of the other options that we didn't change
|
|
0:10:54
|
but are automatically there
|
|
0:10:56
|
like it says the connection type for the crypto map is bidirectional
|
|
0:11:00
|
this means that I can initiate the session
|
|
0:11:03
|
and then I will listen for the session
|
|
0:11:06
|
so router3 could initiate it, or ASA2 could initiate it
|
|
0:11:10
|
we also have the security association life time
|
|
0:11:13
|
both in kilo bytes and in seconds
|
|
0:11:16
|
it says for phase I we are going to try to run main mode
|
|
0:11:23
|
ISAKMP is on outside interface, we have the policy
|
|
0:11:27
|
which also has our life time configured
|
|
0:11:32
|
and then we have NAT reversal enabled, which in this case
|
|
0:11:35
|
we are not going to need this, because we are nor running Network Address Translation yet
|
|
0:11:43
|
Now at this point, the rest of the verification from the show commands and the debug commands
|
|
0:11:48
|
is going to be fairly similar to what we saw before an IOS
|
|
0:11:51
|
where for phase I, we would want to look at the show crypto ISAKMP
|
|
0:11:55
|
SA
|
|
0:11:57
|
and we would want to see that this is in QM_IDLE
|
|
0:12:00
|
for Quick Mode idle, which means that we have
|
|
0:12:02
|
completed phase I negotiation and we moved into phase II
|
|
0:12:06
|
then the show crypto IPSec SA
|
|
0:12:09
|
is going to show us the actual details of the tunnel between the neighbours
|
|
0:12:18
|
so next lets go to some of the end points, lets say, that we go to router4
|
|
0:12:22
|
and I am going to send a ping that is going to go to router6's address
|
|
0:12:27
|
so assuming our tunnel is configured correctly
|
|
0:12:30
|
we should see that phase I negotiation starts
|
|
0:12:37
|
which should result in, when we look at the show crypto ISAKMP SA
|
|
0:12:43
|
says that we have the peer
|
|
0:12:47
|
which is router3, this is a LAN-to-LAN tunnel
|
|
0:12:50
|
we were the responder for this
|
|
0:12:53
|
we look at the router3 and say show crypto ISAKMP SA
|
|
0:12:56
|
says QM_idle which is what we want
|
|
0:13:00
|
okay, in the case of ASA, it says main mode is active
|
|
0:13:05
|
we look at the show crypto ipsec sa
|
|
0:13:10
|
it says that our peer is
|
|
0:13:14
|
router3
|
|
0:13:17
|
we are sourcing the tunnel from the 122.12 address
|
|
0:13:21
|
we have our proxy acl
|
|
0:13:24
|
we have the actual security association
|
|
0:13:27
|
which is showing what is the
|
|
0:13:29
|
the transform set thats ESP AES
|
|
0:13:32
|
ESP SHA
|
|
0:13:34
|
which is running in tunnel mode
|
|
0:13:37
|
then we have the actual packet counter
|
|
0:13:39
|
so again we would want to see here
|
|
0:13:41
|
our packets getting encapsulated on this side
|
|
0:13:44
|
and are they getting decapsulated on the other side
|
|
0:13:47
|
are they getting encrypted here, are they getting decrypted on the other side
|
|
0:13:51
|
are they getting authenticated here
|
|
0:13:53
|
and are they getting
|
|
0:13:55
|
verified on the other side
|
|
0:14:02
|
Now we could also see that even though
|
|
0:14:04
|
the tunnel is coming in on the
|
|
0:14:06
|
outside interface of the ASA
|
|
0:14:10
|
we are allowed to initiate the traffic from router4
|
|
0:14:14
|
even though we are going from the lower security level interface
|
|
0:14:18
|
to the higher security interface
|
|
0:14:21
|
if we look at the
|
|
0:14:37
|
if we look at the show run interface output, we can see that the
|
|
0:14:40
|
the inside interface has a security level of 100
|
|
0:14:43
|
where the outside interface has a security level of 0
|
|
0:14:46
|
typically we would
|
|
0:14:48
|
assume the traffic coming from the outside to the inside
|
|
0:14:51
|
is not going to be allowed
|
|
0:14:53
|
unless we have a manual access list exception
|
|
0:14:56
|
and if we look at the show run access list
|
|
0:15:00
|
we see that we do not have any exceptions that are coming from the outside interface in
|
|
0:15:07
|
so the behaviour here in the ASA is a little bit different than the normal
|
|
0:15:11
|
unencrypted traffic or non tunnel traffic
|
|
0:15:14
|
what is going to allow the ISAKMP
|
|
0:15:18
|
at UDP port 500
|
|
0:15:20
|
and its going to allow the ESP or the AH traffic
|
|
0:15:24
|
to come from the outside in
|
|
0:15:27
|
so we do not need to
|
|
0:15:29
|
configure a specific access list in order to allow this in
|
|
0:16:00
|
and the reason why is that there is a default option here
|
|
0:16:03
|
that is the sysopt connection permit vpn
|
|
0:16:09
|
So as long as this feature is enabled which it is by default
|
|
0:16:13
|
then we do not need any exceptions for the traffic coming from the outside to the inside
|
|
0:16:18
|
now if we were to remove this
|
|
0:16:21
|
we would then need to manually allow the ISAKMP traffic in
|
|
0:16:24
|
and we would manually allow the ESP traffic in
|
|
0:16:29
|
so we would have to match protocol number 50 for ESP
|
|
0:16:33
|
and we would have to match UDP port 500 for ISAKMP
|
|
0:16:39
|
Now if we look at the final result of this
|
|
0:16:43
|
remember that we configured
|
|
0:16:45
|
the crypto ISAKMP key
|
|
0:16:47
|
as opposed to manually defining the tunnel group
|
|
0:16:50
|
but we could see that the ASA does automatically change this for us
|
|
0:16:55
|
where it knows that since we are configuring
|
|
0:16:57
|
an address here, IP address with the ISAKMP key
|
|
0:17:01
|
that this is a LAN to LAN tunnel
|
|
0:17:04
|
and the individual ipsec attributes
|
|
0:17:06
|
the one thats mainly important here is, what the pre shared key is going to be
|
|
0:17:12
|
if we were to look at the show run all tunnel group
|
|
0:17:29
|
we would see that for this particular entry
|
|
0:17:32
|
it says the default group policy is default group policy
|
|
0:17:36
|
there is no trust point
|
|
0:17:38
|
defined
|
|
0:17:40
|
we have the ISAKMP
|
|
0:17:42
|
keep alive value automatically there
|
|
0:17:45
|
then the pre shared key we can actually see the
|
|
0:17:50
|
But if you were to save the config
|
|
0:17:53
|
and then look at the more
|
|
0:17:56
|
disk0/
|
|
0:18:11
|
or more system running config
|
|
0:18:25
|
we would be able to what the actual key is
|
|
0:18:28
|
So normally when you look at the show run output on the ASA
|
|
0:18:31
|
its not going to show you any of your enable passwords or your username passwords
|
|
0:18:35
|
same thing is true of the tunnels for the ISAKMP keys
|
|
0:18:39
|
but if, you need to know there is somebody again you can see this with the more
|
|
0:18:42
|
system:running-config
|
|
0:18:46
|
So overall when you compare the two configurations together
|
|
0:18:50
|
the IOS versus the ASA
|
|
0:18:52
|
they are fairly similar
|
|
0:18:53
|
with the again the exceptions of the tunnel group
|
|
0:18:57
|
where really what this should look like is
|
|
0:18:59
|
these three commands
|
|
0:19:02
|
so, I am saying that the crypto key
|
|
0:19:04
|
we have the same syntax for the phase I policy
|
|
0:19:09
|
we have the tunnel group thats not defining the pre shared key
|
|
0:19:12
|
same syntax with the transform set
|
|
0:19:15
|
the access list is pretty close
|
|
0:19:17
|
with the again the exception of using the subnet masks, not the wild card mask
|
|
0:19:22
|
then the crypto map options we are applying it
|
|
0:19:26
|
over and over with the crypto map command as opposed to going to the sub configuration mode
|
|
0:19:31
|
then the other key point is that the ISAKMP is disabled by default
|
