|
0:00:13
|
In our next section here for the asa
|
|
0:00:16
|
we are going to talk about the transparent firewall that is running in multiple context mode
|
|
0:00:21
|
and we will take a look at doing the active active failover
|
|
0:00:24
|
in transparent mode which means that we have multiple physical devices again
|
|
0:00:28
|
that are forwarding traffic for the different contexts
|
|
0:00:32
|
now we will see there is a couple of you
|
|
0:00:34
|
minor caveats here when we are using the transparent firewall
|
|
0:00:38
|
that are liitle bit different than the routed firewall in multiple context mode
|
|
0:00:42
|
and the main one
|
|
0:00:44
|
is that we cannot share the interfaces between the contexts
|
|
0:00:49
|
now we could see from the diagram here
|
|
0:00:51
|
that we have asa 1 and asa 2 that are on 2 different segments
|
|
0:00:55
|
both of these are going to be running in transparent mode
|
|
0:00:59
|
and we are using ethernet sub interfaces for
|
|
0:01:02
|
the inside and outside interfaces respectively
|
|
0:01:08
|
now in this case we are technically sharing the
|
|
0:01:10
|
the physical interfaces between inside and outside
|
|
0:01:13
|
but the multiple context is going to treat them as different interfaces because they are encapsulated
|
|
0:01:18
|
with different 802.10q vlans
|
|
0:01:21
|
so what I mean that they cannot show interfaces
|
|
0:01:24
|
is that I could not have
|
|
0:01:26
|
the physical ethernet 0/0 share between the multiple contexts
|
|
0:01:30
|
because the transparent firewall is not used to seen classifier as the routed firewall does
|
|
0:01:37
|
So remember previously with the multiple context mode in the routed firewall
|
|
0:01:42
|
we were able to do the
|
|
0:01:45
|
multiple shared interfaces, like in this case, the outside interface of asa1
|
|
0:01:50
|
based on either having unique mac addresses
|
|
0:01:53
|
or unique Network Address Translations
|
|
0:01:56
|
So that we can use the translation table for the classifier
|
|
0:02:00
|
but in the case of a transparent firewall, since we are just doing to mac address bridging
|
|
0:02:05
|
we need to make sure that we have separate interfaces for the different contacts
|
|
0:02:12
|
Now the configurations for this is essentially just going to be the combination of the multiple context mode and the transparent firewall
|
|
0:02:20
|
where this, not a lot of additional caveats that we need to look at configuration wise
|
|
0:02:28
|
so lets take a look at the
|
|
0:02:30
|
the command line here
|
|
0:02:32
|
Now to start
|
|
0:02:33
|
on asa1 and 2
|
|
0:02:35
|
we could see from the output of the show mode and the show firewall that right now they are
|
|
0:02:40
|
running in multiple context mode
|
|
0:02:43
|
but currently they are in the routed firewall
|
|
0:02:47
|
So when we boot up the firewall, we go into global configuration we say mode multiple
|
|
0:02:51
|
its going to reload, and then its going to start in the multi context mode but its going to be in the routed firewall
|
|
0:02:56
|
So then the first step I will need to do here
|
|
0:02:59
|
is in global config, I need to say that the firewall
|
|
0:03:02
|
is going to run in transparent mode
|
|
0:03:06
|
now when I specify this, this is going to be in the system context
|
|
0:03:10
|
which means that it is going to effect the admin context in all of the user context
|
|
0:03:16
|
so we can not have a mix of transparent and routed firewalls
|
|
0:03:19
|
in the user context or the admin context
|
|
0:03:22
|
you see that all of them are going to be routed
|
|
0:03:25
|
or all of them are going to be transparent
|
|
0:03:29
|
So the next step, lets go through our basic configuration of setting up the interfaces
|
|
0:03:34
|
defining the admin context, defining the user context
|
|
0:03:38
|
and we will see if we could get the basic transport between
|
|
0:03:42
|
the transparent multiple firewall
|
|
0:03:44
|
multiple context firewalls
|
|
0:03:45
|
and then we will get into our
|
|
0:03:48
|
failover configuration
|
|
0:03:50
|
so if we take a look at the diagram here
|
|
0:03:53
|
we could see again, that we are using
|
|
0:03:55
|
two different physical interfaces
|
|
0:03:57
|
but we are using multiple sub interfaces on there, so we have ethernet 0/0
|
|
0:04:01
|
is going to be used for the
|
|
0:04:03
|
the context that are talking to router3 and 4
|
|
0:04:06
|
and
|
|
0:04:07
|
ethernet 0/1, its going to be used for context thats talking to router5 and router6
|
|
0:04:12
|
So this would then mean from our layer2 switching point of view
|
|
0:04:16
|
I need to make sure that whatever links are physically connected
|
|
0:04:20
|
to e0/0 and e0/2
|
|
0:04:25
|
or I should say e0/1 here
|
|
0:04:29
|
that these are configured as layer2
|
|
0:04:31
|
dot1q trunk links on switches
|
|
0:04:35
|
So before going any further with the firewall configuration, lets look at
|
|
0:04:39
|
switch1 and switch2, lets look at the show interface status
|
|
0:04:44
|
and I want to see just the links that are connected to
|
|
0:04:46
|
the ASAs
|
|
0:04:48
|
where in this case the ethernet 0/1, both of these are configured as
|
|
0:04:52
|
trunk links
|
|
0:04:54
|
this is true, both the links thats going to asa1 and 2, asa2
|
|
0:04:59
|
and then the same is going to be true of the
|
|
0:05:02
|
links that are going to
|
|
0:05:05
|
asa1's
|
|
0:05:07
|
e0/0 and asa2's e0/0
|
|
0:05:11
|
So again since we are going to be running in active active failover
|
|
0:05:15
|
we need to make sure that the layer2 configuration between both of the firewalls is identical
|
|
0:05:21
|
so from the point of view of the layer2 switches
|
|
0:05:24
|
if asa1 is using a trunk at its inside interface then asa2 would need to do the same
|
|
0:05:29
|
if there was access port, we need to make sure that there was sign in the same access vlan
|
|
0:05:35
|
So next lets configure our physical parameters inside of the systems context mode
|
|
0:05:40
|
we will give it a hostname here, we will say that this is
|
|
0:05:43
|
rack9asa
|
|
0:05:46
|
lets say asa1, for clarity
|
|
0:05:49
|
then for the physical interfaces right now lets look at the show run
|
|
0:05:54
|
we can see that by default again the links are in the shut down state
|
|
0:05:58
|
so I want to make sure that these are
|
|
0:06:01
|
not administratively down, so I will simply say no shut down on them
|
|
0:06:07
|
then I am going to configure the sub interfaces for the vlan encapsulation
|
|
0:06:11
|
So on ethernet0/0 I have
|
|
0:06:13
|
sub interface .113
|
|
0:06:17
|
where this is going to be used to encapsulate vlan
|
|
0:06:20
|
113
|
|
0:06:23
|
and e0/0
|
|
0:06:29
|
so gain technically the subnet interface number does not have to match the vlan association
|
|
0:06:34
|
but there is really no reason why you would not want to do that
|
|
0:06:37
|
just for clarity of the configuration
|
|
0:06:46
|
then the same is going to be true here ethernet 0/1
|
|
0:06:49
|
is in vlan 115
|
|
0:06:54
|
and 116
|
|
0:06:56
|
so these are going to be links that are connecting to routers 3 , 4 , 5 and 6 respectively
|
|
0:07:03
|
so now that we have our basic physical parameters configured
|
|
0:07:07
|
we need to assign which particular context these sub interfaces are going to be allocated to
|
|
0:07:15
|
so next we are going to find or going to define our context we will say our first context is going to be
|
|
0:07:21
|
the connection between router 3 and router 4
|
|
0:07:26
|
now notice in this case it says we need to identify the admin context first using the admin-context command
|
|
0:07:33
|
and depending on the order of configuration that you do this in
|
|
0:07:37
|
you can end up in certain circumstances that when you change from single context mode
|
|
0:07:42
|
to multiple context mode
|
|
0:07:44
|
it already creates the admin context for you
|
|
0:07:48
|
but in this case based on the order that i actually booted the devices
|
|
0:07:52
|
admin context was not configured
|
|
0:07:54
|
so i do need to define this first before i have my user context
|
|
0:07:59
|
so i'll say that i have the admin
|
|
0:08:02
|
that context and this is the name
|
|
0:08:05
|
where normally by default its named admin
|
|
0:08:08
|
but i technically could name whatever i want to
|
|
0:08:11
|
so then for context admin
|
|
0:08:14
|
i simply need to specify where is the configuration going to be saved whats the config url
|
|
0:08:21
|
so i'll say on disk 0 its going to be admin.cfg
|
|
0:08:27
|
so our next step we will configure the user context again
|
|
0:08:31
|
i'll call the first one again router 3 router 4
|
|
0:08:34
|
where i want to allocate
|
|
0:08:36
|
the interfaces that are the
|
|
0:08:39
|
the sub interface 113
|
|
0:08:42
|
which from their perspective is going to be there
|
|
0:08:44
|
outside interface
|
|
0:08:46
|
so give it the alias for outside
|
|
0:08:48
|
and ethernet 0/0.114 is going to be the inside interface
|
|
0:08:55
|
so again we will specify the name here
|
|
0:08:58
|
this is what they are going to see
|
|
0:09:01
|
the physically intefaces name this is not related to the nameif
|
|
0:09:06
|
so i could call this
|
|
0:09:07
|
whatever i want to i could say interface 1
|
|
0:09:10
|
i can call it actually ethernet 0/0.113
|
|
0:09:14
|
when we look at the
|
|
0:09:15
|
i'll show interface out from the context mode
|
|
0:09:19
|
again thats what they are going to see as the interfaces's name
|
|
0:09:24
|
we have the outside interface and we also have the inside interface
|
|
0:09:30
|
in our call that inside in
|
|
0:09:34
|
in lower case
|
|
0:09:36
|
the other option we need is the configuration url
|
|
0:09:40
|
so where we are going to save the actual configuration flash i call this
|
|
0:09:44
|
config url
|
|
0:09:47
|
on disk 0 call it just R3-R4.cfg
|
|
0:09:53
|
so you can see technically you can name it whatever you want to
|
|
0:09:56
|
but just for clarity i am going to name it the same thing as the actual context name itself
|
|
0:10:04
|
so lets look at our resulting configuration here lets say show run context
|
|
0:10:10
|
and essentially the same thing that we have here
|
|
0:10:12
|
for the R3 R4 context
|
|
0:10:15
|
is going to be for the other one i'll call the other one R5 R6
|
|
0:10:19
|
the main difference is that we are going to have different interface
|
|
0:10:22
|
on numbers
|
|
0:10:24
|
so this would be e0/1
|
|
0:10:28
|
.115 and 116
|
|
0:10:31
|
and i'll say this is say this R5
|
|
0:10:34
|
R6
|
|
0:10:37
|
so again this is doing the physical definition of what are the resources that the context is going to get
|
|
0:10:43
|
now at this point this is the vast maturity of what needs to be done in the system context
|
|
0:10:48
|
pretty much here and out everything else is going to be under the user context mode
|
|
0:10:53
|
where we are defining any of our logical options
|
|
0:10:57
|
now again for the tansparent firewall
|
|
0:11:00
|
mainly the only thing that we need to do here
|
|
0:11:02
|
is specify what are the names of the interfaces
|
|
0:11:06
|
what are their security levels
|
|
0:11:09
|
and then if we want any type of exception
|
|
0:11:12
|
for the filtering
|
|
0:11:14
|
for example if we want to allow routing protocols in an inside interface
|
|
0:11:19
|
remember there is a difference in the filtering between the
|
|
0:11:23
|
the transparent firewall mode versus the router firewall mode
|
|
0:11:31
|
now if we look at our routing diagram here
|
|
0:11:34
|
in this particular case we are running eigrp
|
|
0:11:38
|
separate processes run between router 3 and router 4
|
|
0:11:43
|
and then a separate one between router 5 and router 6
|
|
0:11:47
|
so i will need to account for this in the control plane
|
|
0:11:51
|
when i am allowing traffic in on the inside interface
|
|
0:11:56
|
so another link between router 5 and 6 is the traffic comes in on the inside interface of the transparent asa
|
|
0:12:03
|
it is going to be dropping eigrp packets by default
|
|
0:12:06
|
and we would be able to see this when we look at the log output
|
|
0:12:10
|
that of the
|
|
0:12:11
|
multicast for eigrp and the unicast are going to be denied
|
|
0:12:19
|
so next lets actually go to the
|
|
0:12:22
|
the individual contexts change to
|
|
0:12:25
|
context R3
|
|
0:12:28
|
R3 R4
|
|
0:12:31
|
and lets just look at the basic running configuration
|
|
0:12:35
|
so we see we have the two interfaces named
|
|
0:12:37
|
outside and inside
|
|
0:12:40
|
next step would be to assign their
|
|
0:12:43
|
nameif so i'll say this is nameif outside
|
|
0:12:49
|
nameif outside and then interface inside
|
|
0:12:53
|
is nameif inside
|
|
0:12:57
|
if we look at the default policy
|
|
0:13:00
|
for the modular policy framework
|
|
0:13:02
|
again this is going to be similar to the routed firewall mode
|
|
0:13:05
|
where we are inspecting tcp and udp
|
|
0:13:09
|
plus an application level inspections like ftp
|
|
0:13:13
|
send mail esmtp
|
|
0:13:15
|
tftp some of the voice over ip calls
|
|
0:13:18
|
but we are not
|
|
0:13:20
|
we are not inspecting icmp
|
|
0:13:23
|
so for next my basic testing i am just going to go to
|
|
0:13:26
|
the default inspection policy
|
|
0:13:29
|
and tell it to include the icmp inspection
|
|
0:13:32
|
because i want to see can i ping from the inside interface
|
|
0:13:36
|
to the outside interface
|
|
0:13:43
|
and i am going to do this both for the R3 R4 context and for
|
|
0:13:48
|
the R5 R6
|
|
0:13:50
|
lets change to context R5
|
|
0:13:54
|
and again notice i don't have to type in the whole
|
|
0:13:56
|
context name as long as it is that is something unique
|
|
0:14:00
|
and i am going to inspect icmp
|
|
0:14:04
|
so now if we actually go to the devices on the
|
|
0:14:08
|
the inside
|
|
0:14:09
|
which again in this case are going to be routers 4 and 6
|
|
0:14:13
|
if i am able to send traffic from the inside out and then get the return
|
|
0:14:18
|
then i know that just the basic
|
|
0:14:20
|
filtering for the transparent firewall is working
|
|
0:14:58
|
so we can see here from router 4's perspective
|
|
0:15:00
|
we are sending traffic out to router 3 but we are not getting a reponse back in
|
|
0:15:04
|
so before doing any troubleshooting on the security level topics
|
|
0:15:07
|
lets just make sure that there is nothing wrong on the basic layer 1 or layer 2 networking on either these devices
|
|
0:15:14
|
so on router 4 lets just look at the show ip interface brief
|
|
0:15:18
|
i want to make sure that
|
|
0:15:20
|
there is nothing as simple as like interface being shutdown
|
|
0:15:23
|
on either these devices
|
|
0:15:26
|
do show ip interface brief
|
|
0:15:29
|
where the interface status looks ok
|
|
0:15:32
|
so next lets look at from the device on the outside
|
|
0:15:35
|
is it actually receiving
|
|
0:15:37
|
the first portion of the flow from router 4 to 3
|
|
0:15:42
|
where we know this is going to be two different types of traffic this is going to be the icmp echo
|
|
0:15:48
|
and its going to be the icmp
|
|
0:15:51
|
echo reply
|
|
0:15:55
|
so i first want to see on router 3 is it actually receiving the echo in
|
|
0:15:59
|
from router 3
|
|
0:16:01
|
and from router 4
|
|
0:16:03
|
and we can tell this by looking at the
|
|
0:16:05
|
the debug ip icmp
|
|
0:16:16
|
now based on the fact that we are not getting output from this debug on router 3
|
|
0:16:21
|
its going to lead me to a couple
|
|
0:16:23
|
different steps in
|
|
0:16:25
|
trouble shooting here
|
|
0:16:27
|
i now want to make sure are there any additional problems in my layer 2 networking
|
|
0:16:32
|
so are the actual vlans that router 3 and router 4 using are they properly assigned
|
|
0:16:37
|
then if it is not a problem in the basic layer 2 switching network
|
|
0:16:41
|
then i need to look at whats going on with the
|
|
0:16:43
|
with the asa's configuration
|
|
0:16:46
|
so again we could verify the
|
|
0:16:49
|
the layer 2 switching if we look at the show interface status
|
|
0:16:53
|
and lets exclude the not
|
|
0:16:55
|
connected interfaces to show just the ones that are plugged in
|
|
0:17:00
|
where router 4 here
|
|
0:17:04
|
is using interface
|
|
0:17:06
|
fast ethernet 0/0
|
|
0:17:12
|
which here fa0/0 this is connected to vlan 114
|
|
0:17:17
|
so from here if i were to look at the show
|
|
0:17:19
|
spanning tree vlan 114
|
|
0:17:22
|
i want to make sure that it is forwarding on router 4's interface
|
|
0:17:26
|
and then also on the
|
|
0:17:28
|
eithernet 0/0 interfaces
|
|
0:17:32
|
that are going towards the asas
|
|
0:17:34
|
now in this particular case i do know that the layer 2 networking is working i have previously verified this
|
|
0:17:40
|
so as soon that we through all of these steps and we don't find anything wrong
|
|
0:17:43
|
next thing to do would be to look at the asa
|
|
0:17:47
|
and may be we want to see from its login
|
|
0:17:49
|
this would tell us exactly
|
|
0:17:51
|
why the traffic is being dropped or does it even see it in the classifier
|
|
0:17:57
|
so now lets go to change to context R3 R4
|
|
0:18:02
|
and lets look at our basic configuration first
|
|
0:18:10
|
we can see from the interface level we are doing the
|
|
0:18:14
|
we do have the names to find video of the security levels
|
|
0:18:18
|
so assuming that the links are actually enabled
|
|
0:18:20
|
in the system context mode thats pretty much all we need to do at the interface level
|
|
0:18:25
|
then under the modular quality
|
|
0:18:27
|
of service with the modular policy framework
|
|
0:18:30
|
we are inspecting the icmp traffic
|
|
0:18:35
|
so next lets look at the debug or straight away figure out
|
|
0:18:37
|
is the asa actually receiving the traffic as it comes in on the inside interface
|
|
0:18:42
|
and if its is receiving and it is going to tell us why specifically that it is dropping
|
|
0:19:06
|
an asa 1 here says dropping a protocol icmp packet from the inside to the outside
|
|
0:19:12
|
because there is no management ip address configured for the transparent firewall dropping the protocol
|
|
0:19:19
|
on eigrp is using inside to the outside
|
|
0:19:22
|
so another 100% percent sure if i mention this before when we were talking about the transparent firewall
|
|
0:19:27
|
its kind of an interesting caveat here that
|
|
0:19:29
|
even if you are not using the
|
|
0:19:33
|
managemnet through ip
|
|
0:19:35
|
for telnetting or asssessing in to the transparent firewall
|
|
0:19:39
|
if you don't actually assign an ip address
|
|
0:19:42
|
its not going to allow traffic to transit between its interfaces
|
|
0:19:46
|
and thats what this debug is telling us here
|
|
0:19:49
|
that we are denying the traffic as it comes in on the inside link
|
|
0:19:53
|
because there is no management address configured
|
|
0:19:56
|
so what i am missing here lets say no logging console
|
|
0:20:00
|
what i am missing is the global ip address
|
|
0:20:03
|
which in this case would put it in that same subnet 172.16.34.0
|
|
0:20:11
|
say 172.16.34.11/24
|
|
0:20:21
|
we can see now the traffic is allowed through
|
|
0:20:25
|
so even though its not going to the asa itself its just being bridged tranparently through it
|
|
0:20:31
|
we do need to configure the management interface otherwise its not going to forward the traffic
|
|
0:20:36
|
and then the same would be true of
|
|
0:20:38
|
our other context
|
|
0:20:40
|
if router 6 goes to ping router 5
|
|
0:20:44
|
this traffic is going to be dropped
|
|
0:20:46
|
until i actually have inside of
|
|
0:20:50
|
context R5 R6
|
|
0:20:55
|
an ip address for management which in this case is going to be 10.0.56.11
|
|
0:21:37
|
then lets see if now the asa has any locks for this
|
|
0:21:40
|
particular context lets say logging
|
|
0:21:44
|
logging on and logging console 7
|
|
0:22:06
|
now here actually this is a separate problem i didn't specify on the interfaces the
|
|
0:22:11
|
the names yet
|
|
0:22:13
|
so outside is going to be nameif outside
|
|
0:22:16
|
interface inside is going to be nameif inside
|
|
0:22:27
|
we can see now the classifier is having the traffic
|
|
0:22:30
|
so if we look at the
|
|
0:22:32
|
the show run lets look at the policy
|
|
0:22:36
|
the policy is inspecting icmp
|
|
0:22:39
|
so traffic should be coming in on the inside interface and then leaving the outside
|
|
0:22:50
|
and we can see now its successfull
|
|
0:22:54
|
so again its kind of a
|
|
0:22:56
|
an arp caveat here that even now
|
|
0:22:58
|
the asa is not routing ip
|
|
0:23:01
|
unless we have this ip address configured globally
|
|
0:23:05
|
for the management
|
|
0:23:07
|
but it is not going to forward the traffic between its interfaces
|
|
0:23:11
|
and again we saw that when we looked at the log on the other context
|
|
0:23:16
|
it said there was no management ip address configured
|
|
0:23:20
|
so it was dropping the packets
|
|
0:23:24
|
now for both these context it is still going to be dropping the eigrp routing protocol traffic
|
|
0:23:30
|
as it is coming in on the inside
|
|
0:23:33
|
as it is coming in on the outside
|
|
0:23:36
|
so now what i would need to do
|
|
0:23:38
|
is make my manual access list exceptions
|
|
0:23:41
|
for the router 3 to router 4 context
|
|
0:23:44
|
i need to say to allow eigrp
|
|
0:23:48
|
but then when i do this
|
|
0:23:50
|
its going to again drop the other traffic
|
|
0:23:54
|
that falls back to the implicit deny
|
|
0:23:57
|
on the access list
|
|
0:23:59
|
so really if i am going to manually allow the eigrp
|
|
0:24:02
|
i am going to say permit eigrp traffic
|
|
0:24:05
|
but then also permit the tcp upd and icmp
|
|
0:24:09
|
that i want to send to the inspection engine
|
|
0:24:14
|
so now on both of these contexts i am going to need two separate access lists
|
|
0:24:18
|
i'll have access list that is outside in
|
|
0:24:22
|
that is going to permit eigrp
|
|
0:24:27
|
eigrp tcp udp
|
|
0:24:32
|
and icmp
|
|
0:24:34
|
than access list
|
|
0:24:36
|
excuse me this will be inside in
|
|
0:24:39
|
inside in
|
|
0:24:47
|
then also the outside in access list this one is just going to permit the eigrp traffic
|
|
0:24:51
|
because remember we are doing two different orders of operations
|
|
0:24:55
|
when we come in on the inside interface
|
|
0:24:59
|
we are checking the access list first before the modular policy framework
|
|
0:25:03
|
when we are coming in on the outside interface
|
|
0:25:06
|
we are checking the
|
|
0:25:08
|
mpf inspections first we are checking the state table
|
|
0:25:11
|
if there is no match in the state table then we look at the access list
|
|
0:25:28
|
so this configuration is going to be identical on
|
|
0:25:31
|
both of the context
|
|
0:25:34
|
if the two access lists
|
|
0:25:37
|
that are applied on the inside and the outside
|
|
0:25:39
|
interfaces inbound respectively
|
|
0:25:42
|
and once i configure this we should not get the log message on the routers
|
|
0:25:45
|
that now the eigrp adjacency is up
|
|
0:25:50
|
we look at router 6 and say show ip route eigrp
|
|
0:25:54
|
we can see that we are receiving routes from
|
|
0:25:57
|
the router on the other end
|
|
0:26:00
|
then likewise on router 4 if we look at the show
|
|
0:26:03
|
ip eigrp neighbours
|
|
0:26:05
|
right now we do not have an adjacencey
|
|
0:26:08
|
then once we apply this new access list
|
|
0:26:16
|
we should get the log message that the
|
|
0:26:19
|
eigrp adjacency comes up
|
|
0:26:22
|
if we show ip route eigrp
|
|
0:26:25
|
we can see now we are learning routes from the outside in
|
|
0:26:31
|
so now lets look at our 4 configurations for this on
|
|
0:26:34
|
the asa lets say change to
|
|
0:26:38
|
change to system
|
|
0:26:40
|
and i am going to write m all
|
|
0:26:43
|
so again this is going to save my system context
|
|
0:26:45
|
plus all of the user contexts
|
|
0:26:49
|
if i do not do this then individually i would have to go to admin or R3 or R4 or R5 or R6
|
|
0:26:56
|
and then save the configuration
|
|
0:27:00
|
now if we look at the
|
|
0:27:03
|
the show run
|
|
0:27:04
|
the configuration here in the system mode
|
|
0:27:07
|
pretty straight forward we simply have our
|
|
0:27:10
|
physical interface parameters
|
|
0:27:14
|
we are running in transparent mode
|
|
0:27:21
|
then we have our
|
|
0:27:24
|
context definitions so the admin
|
|
0:27:26
|
the two user contexts
|
|
0:27:29
|
then if we look at the more
|
|
0:27:32
|
this particular file this is the same as say show run inside of that context
|
|
0:27:39
|
we have the
|
|
0:27:41
|
the names and the security levels on the interfaces
|
|
0:27:45
|
then we have the access list exceptions that are going to allow our control plane traffic
|
|
0:27:50
|
but then make sure not to drop the
|
|
0:27:52
|
other packets as they are coming in on the inside
|
|
0:27:56
|
so these 3 lines
|
|
0:27:59
|
this is the additional key point about the difference between
|
|
0:28:02
|
the inside in filtering and the outside in filtering
|
|
0:28:14
|
then the last two points here if we want to allow the icmp from the inside out into return
|
|
0:28:19
|
we are inspecting it under the modular policy framework
|
|
0:28:22
|
and there also we need it the management ip address
|
|
0:28:28
|
because the tansparent firewall is going to drop the traffic without this
|
|
0:28:31
|
and this is true whether we are running
|
|
0:28:33
|
in single context mode with transparent firewall
|
|
0:28:37
|
or in multiple context mode with transparent firewall
|
