|
0:00:14
|
In our next section we are going to talk about the IOS based transparent firewall
|
|
0:00:19
|
and specifically how to configure it with both the content based access control
|
|
0:00:23
|
and the zone based policy firewall
|
|
0:00:27
|
Now as we saw this before with the ASA
|
|
0:00:30
|
IOS additionally does support the transparent firewall
|
|
0:00:34
|
which means that the interfaces
|
|
0:00:36
|
are going to be in the same subnet but they are going to be in different VLANs
|
|
0:00:41
|
So traffic is going to be layer2 bridged between interfaces based on the MAC address table or based on the CAM table
|
|
0:00:49
|
but whether traffic is actually permitted or denied
|
|
0:00:52
|
is still going to be controlled by the CBAC based session table
|
|
0:00:57
|
essentially this means that the inside and outside interface is would be on the same subnets
|
|
0:01:02
|
but its traffic is moving from the inside out and then returning
|
|
0:01:05
|
we are going to send it through some sort of inspection
|
|
0:01:09
|
Now we will see that the syntax is supported both
|
|
0:01:12
|
through the content based access control and the zone based policy firewall
|
|
0:01:16
|
and the configuration is going to be fairly similar
|
|
0:01:19
|
to what we saw before
|
|
0:01:21
|
running CBAC in its routed mode
|
|
0:01:23
|
and running the zone based policy firewall in its routed mode
|
|
0:01:27
|
we will see the main difference with this configuration
|
|
0:01:30
|
is that the router is going to be running layer2 transparent bridging
|
|
0:01:34
|
so we do need to understand how some of the basic bridging command work
|
|
0:01:37
|
and how the integrated routing and bridging or IRB feature
|
|
0:01:42
|
is used to allow us to both route and bridge
|
|
0:01:46
|
the same protocol on the same interfaces at the same time
|
|
0:01:51
|
now the particular topology that we are using for this example
|
|
0:01:55
|
is similar to what we saw before what we have router3 and router4
|
|
0:01:59
|
on the segment 172.16.34.0
|
|
0:02:04
|
but in this case we have router6
|
|
0:02:07
|
in the middle
|
|
0:02:08
|
that is going to running the transparent IOS firewall
|
|
0:02:12
|
this means that from both from router3 and router4's perspective
|
|
0:02:16
|
they have no visibility that there is a
|
|
0:02:18
|
firewall doing any filtering between them
|
|
0:02:21
|
this means that they are routing
|
|
0:02:23
|
control plane adjacency which in this case is EIGRP
|
|
0:02:27
|
which still need to occur transparently through the IOS firewall
|
|
0:02:31
|
and from a
|
|
0:02:33
|
on actual ip packet flow point of view if I were to go to router4
|
|
0:02:37
|
and to do a traceroute
|
|
0:02:40
|
out to other destination in the network
|
|
0:02:43
|
router4 is not going to see router6
|
|
0:02:45
|
is a layer3 hop
|
|
0:02:48
|
so its essentially performing the same type of operation as a layer2 transparent bridge
|
|
0:02:53
|
like a normal ethernet switch would
|
|
0:02:55
|
between router3 and router4
|
|
0:02:59
|
now the important
|
|
0:03:00
|
now the important point to note about this diagram
|
|
0:03:03
|
is that even though all three of the devices are in the same IP subnet
|
|
0:03:07
|
there is a separate VLAN that is between router3 and 6
|
|
0:03:11
|
and between router4 and 6
|
|
0:03:14
|
we need to make sure that this traffic is coming in on the inside interface
|
|
0:03:19
|
then as it is bridged out to the outside interface
|
|
0:03:23
|
that router6 is going to send this through the inspection engine
|
|
0:03:26
|
whether this is either with the content based access control
|
|
0:03:29
|
or with the zone based policy firewall
|
|
0:03:32
|
then as the traffic returns from the outside back inbound
|
|
0:03:36
|
we are going to check the session table to see whether this traffic would be allowed
|
|
0:03:42
|
Now just like our previous policies with
|
|
0:03:44
|
both going from the inside to the outside, and then from the outside to the inside
|
|
0:03:49
|
if we did have a more complex policy
|
|
0:03:53
|
where may be there are public web servers behind router6
|
|
0:03:57
|
we would also need to associate an
|
|
0:03:59
|
outside to inside policy
|
|
0:04:01
|
or some sort of
|
|
0:04:02
|
exceptions with the IP inspections
|
|
0:04:04
|
that we will allow these particular ports to
|
|
0:04:07
|
be moving from the public outside network to the trusted private inside network
|
|
0:04:15
|
So again the first thing that we need to worry about with this type of configuration
|
|
0:04:18
|
is how do we actually get router6 to bridge the traffic between its two interfaces
|
|
0:04:24
|
so we will look at our basic transparent bridging configuration
|
|
0:04:27
|
then we will look at the firewall filtering with both the content based access control
|
|
0:04:31
|
and the zone based policy firewall
|
|
0:04:36
|
so next lets go to the command line
|
|
0:04:39
|
of router6
|
|
0:04:41
|
and if we look at our configuration
|
|
0:04:43
|
up to this point
|
|
0:04:45
|
there are no ip addresses assigned
|
|
0:04:48
|
to any of the interfaces
|
|
0:04:50
|
the are no routing protocols configured
|
|
0:04:53
|
we look at the show ip interface brief
|
|
0:04:56
|
its basically just a blank configuration with
|
|
0:04:59
|
the minor options like the hostname the username and password
|
|
0:05:03
|
but right now we are not routing between the interfaces and likewise we are not bridging between the interfaces
|
|
0:05:09
|
so the first step
|
|
0:05:11
|
in the bridging configuration would be to turn the bridging on
|
|
0:05:15
|
which is accomplished with the bridge command
|
|
0:05:17
|
followed by a bridge group number
|
|
0:05:19
|
this case I will say just bridge group 1
|
|
0:05:22
|
and then to define what is the particular spanning tree protocol that we are using
|
|
0:05:27
|
where if we were to say
|
|
0:05:29
|
bridge1 protocol IEEE
|
|
0:05:31
|
it means we are running the standardised based common spanning tree
|
|
0:05:36
|
so if there were other switches on the segment that were running normal spanning tree
|
|
0:05:40
|
Now router6 is going to participate in the same common spanning tree as that
|
|
0:05:45
|
essentially what we are doing here is to finding a VLAN number
|
|
0:05:48
|
So the bridge group number is equivalent of a VLAN number on the switches
|
|
0:05:53
|
So now the bridging process is on
|
|
0:05:55
|
next thing at the
|
|
0:05:56
|
the interface level
|
|
0:05:58
|
is to actually put them into the bridge group
|
|
0:06:00
|
this would be the equivalent
|
|
0:06:03
|
of the switch port access vlan command on the switches
|
|
0:06:06
|
where the VLAN was created globally
|
|
0:06:09
|
now we are applying to the interfaces
|
|
0:06:12
|
if we now look at the show
|
|
0:06:16
|
the show spanning tree
|
|
0:06:18
|
for bridge group number 1
|
|
0:06:21
|
this is going to be the same time of output as if we would see from the show spanning tree vlan1
|
|
0:06:26
|
on the layer2 switches
|
|
0:06:28
|
where eventually what we should see here
|
|
0:06:31
|
is that these ports are going to transition
|
|
0:06:33
|
from the listening to the learning phases
|
|
0:06:36
|
and then ultimately to forwarding
|
|
0:06:41
|
Now the transparent firewall for IOS
|
|
0:06:44
|
its only going to be supported for basic
|
|
0:06:46
|
routed traffic of IPv4
|
|
0:06:49
|
for TCP, UDP and ICMP flows
|
|
0:06:53
|
of any type of non IP protocol
|
|
0:06:55
|
may be if you have some sort of legacy, netbios applications or sna application
|
|
0:07:00
|
those are not going to going through the firewall filtering
|
|
0:07:03
|
that router with just three ?? is normal bridged packets between the interfaces
|
|
0:07:09
|
so the next thing I want to know
|
|
0:07:11
|
is can router6 can actually bridge the packets from 4
|
|
0:07:15
|
to 3
|
|
0:07:16
|
and then likewise from 3 back to 4
|
|
0:07:21
|
so next lets go to router4
|
|
0:07:23
|
and check can I do a basic ping
|
|
0:07:25
|
to the address
|
|
0:07:27
|
that router3 has attached
|
|
0:07:30
|
So from router4 we could see that we do not have reachability to router3
|
|
0:07:35
|
likewise if we were try the reverse, if we go to three
|
|
0:07:38
|
and try to send traffic to router4
|
|
0:07:40
|
right now we don't have basic reachability
|
|
0:07:43
|
and the reason why is that on router6
|
|
0:07:47
|
if we look at the show
|
|
0:07:48
|
IP protocols
|
|
0:07:51
|
IP is not actually enabled on any of the interfaces
|
|
0:07:55
|
but the IP routing process globally is enabled
|
|
0:07:59
|
which is controlled with the command ip routing
|
|
0:08:03
|
in global configuration
|
|
0:08:05
|
where the this is the default condition that typically you would be running ip routing on the router
|
|
0:08:11
|
but if you want to bridge the ip stack
|
|
0:08:13
|
we would need to disable routing for ip
|
|
0:08:16
|
So if we turn ip routing off
|
|
0:08:18
|
we should see now that router3 and router4 have connectivity
|
|
0:08:22
|
and additionally notice that
|
|
0:08:24
|
the basically as soon as I disabled routing on router6
|
|
0:08:27
|
the EIGRP adjacency between router3 and router4 comes back
|
|
0:08:33
|
Now this is one potential option that we could configure the router to do bridging only
|
|
0:08:39
|
and to not support routing ip on
|
|
0:08:41
|
any of its interfaces
|
|
0:08:43
|
but the potential issue is now
|
|
0:08:46
|
that if we want some sort of
|
|
0:08:47
|
inbound management of router6
|
|
0:08:50
|
where may be I want to be able to telnet to router6 for management or I want to SSH in
|
|
0:08:57
|
to router6 for management
|
|
0:08:59
|
with the ip routing process off
|
|
0:09:00
|
I am not going to able to do this
|
|
0:09:04
|
So typically in most cases that the router is bridging between its interfaces
|
|
0:09:08
|
but you also wanted to run ip
|
|
0:09:11
|
we would run the feature set that is known as
|
|
0:09:14
|
integrated routing and bridging or IRB
|
|
0:09:18
|
Now IRB on the routers
|
|
0:09:20
|
is basically a legacy version
|
|
0:09:22
|
of what is now supported on the switches
|
|
0:09:25
|
where we see the Switch Virtual Interface or the SVI
|
|
0:09:30
|
on the layer3 switches this is simply what we define as the interface VLAN
|
|
0:09:35
|
where we would say interface VLAN 1
|
|
0:09:38
|
and then give it an ip address on that particularly
|
|
0:09:42
|
what this is doing on the switches is allow them to bridge the packet between the access switch ports
|
|
0:09:47
|
but then also route the packets based on the switch port interface
|
|
0:09:52
|
and this SVI logic
|
|
0:09:54
|
came from the routers with the integrated routing and bridging features
|
|
0:09:57
|
that uses what is known as a bridge
|
|
0:10:00
|
virtual interface or a BVI
|
|
0:10:03
|
as opposed to the Switch Virtual Interface or the SVI
|
|
0:10:07
|
so its the same type of logic as any type of layer3 switch
|
|
0:10:11
|
its upto doing the configuration on the router
|
|
0:10:15
|
Now in order to do this
|
|
0:10:17
|
on router6, we need to turn the IRB feature set on
|
|
0:10:20
|
so we will say bridge IRB globally
|
|
0:10:24
|
and I want to re enable ip routing
|
|
0:10:29
|
now since routing is on and we are running Integrated Routing and Bridging
|
|
0:10:33
|
I also need to specify for which particular VLANs
|
|
0:10:37
|
or more specifically what particular bridge groups
|
|
0:10:40
|
I want to bridge the protocols and route the protocols
|
|
0:10:44
|
with the default would be for bridge group 1
|
|
0:10:47
|
that I previously created
|
|
0:10:49
|
it is going to be bridging IP
|
|
0:10:51
|
but in addition to bridging IP I also want to route ip
|
|
0:10:56
|
Now if we look at the end result of this in the configuration
|
|
0:11:00
|
we say show run include bridge or interface
|
|
0:11:06
|
we see the configuration is pretty straight forward, where we have the
|
|
0:11:09
|
the bridge group created
|
|
0:11:11
|
so bridge 1 protocol IEEE
|
|
0:11:15
|
the bridge group is applied to the interfaces
|
|
0:11:17
|
the IRB feature set is on
|
|
0:11:20
|
then we are telling it for this particular bridge group
|
|
0:11:22
|
we want to both bridge and route ip at the same time
|
|
0:11:26
|
so the default command bridge 1 bridge ip doesn't show up there
|
|
0:11:30
|
because its the default option for all of the bridge groups
|
|
0:11:34
|
Our next step would be to configure whatever the layer3 interface we want is
|
|
0:11:39
|
so instead of saying interface VLAN 1
|
|
0:11:42
|
which we would on the switches, we are going to say interface
|
|
0:11:45
|
BVI1
|
|
0:11:47
|
where number 1 is corresponding to the bridge group number
|
|
0:11:52
|
from here this is where we would put any of our layer3 configuration
|
|
0:11:57
|
or in this case I want router6
|
|
0:11:59
|
to have the address 172.16.34.6
|
|
0:12:08
|
so we will see that the ip address is 172.16.34.6/24
|
|
0:12:16
|
and additionally I am going to run routing on this segment
|
|
0:12:19
|
where router3 and router4, they are running EIGRP
|
|
0:12:22
|
AS34
|
|
0:12:25
|
so I will put a very basic configuration on router6 which will say router EIGRP 34
|
|
0:12:31
|
no auto summary
|
|
0:12:33
|
network 172.16.34.6
|
|
0:12:38
|
so I am enabling EIGRP process on the Bridge Virtual Interface or the BVI
|
|
0:12:44
|
if we look at the result of this, we can see that
|
|
0:12:47
|
we have two EIGRP neighbours
|
|
0:12:50
|
but the adjacency is now occurring on the bridge version interface
|
|
0:12:55
|
if we look at the routing table
|
|
0:12:57
|
and show ip route
|
|
0:13:01
|
we see that we are learning EIGRP routes in from router4 and from router3
|
|
0:13:07
|
and it says these are reachable via the BVI interface
|
|
0:13:12
|
Now what this essentially means is that for any traffic that is within
|
|
0:13:17
|
the same subnet
|
|
0:13:18
|
that traffic is going to be bridged
|
|
0:13:21
|
but any traffic that is moving between the subnets, that is going to be routed
|
|
0:13:26
|
So if we were to look at router4
|
|
0:13:28
|
and look at the routing table here
|
|
0:13:33
|
Notice that there is nothing that is learned
|
|
0:13:35
|
from 34.6
|
|
0:13:38
|
because router6 is not advertising any of its
|
|
0:13:41
|
other layer
|
|
0:13:43
|
3 interfaces into the EIGRP process
|
|
0:13:46
|
so this means if I were to do a traceroute
|
|
0:13:49
|
lets say from router4 we are going to trace out to
|
|
0:13:52
|
router1
|
|
0:13:53
|
we will say 200.0.0.1
|
|
0:13:57
|
notice that router6 does not show up
|
|
0:13:59
|
as a layer3 hop
|
|
0:14:02
|
in the traceroute
|
|
0:14:04
|
So essentially now the traffic between
|
|
0:14:07
|
router3 and router4 is being bridged
|
|
0:14:11
|
between router6's interfaces
|
|
0:14:15
|
we also have access to router6
|
|
0:14:19
|
through its BVI interface
|
|
0:14:21
|
which is the .6 address, this is would allow us again to telnet or
|
|
0:14:24
|
to SSH into 6
|
|
0:14:27
|
but now we are going to apply the firewall feature set
|
|
0:14:30
|
onto the actual physical links
|
|
0:14:34
|
so even though the traffic is being layer2 bridged
|
|
0:14:38
|
between the interfaces
|
|
0:14:39
|
both CBAC and the zone based policy firewall still
|
|
0:14:42
|
can't categorize the traffic flows
|
|
0:14:47
|
Now for the CBAC configuration
|
|
0:14:49
|
its going to be similar to any of the other previous configurations we did with the ip inspect command
|
|
0:14:54
|
the idea is that I have the inside network
|
|
0:14:57
|
that is attached to router4
|
|
0:14:59
|
I have the outside network that is attached to router3
|
|
0:15:03
|
I want to inspect the traffic as the flows are going in direction
|
|
0:15:07
|
then as they are received back in
|
|
0:15:09
|
I wanted to either selectively
|
|
0:15:10
|
permit or deny them
|
|
0:15:12
|
depending on whats going on in the underlying state table
|
|
0:15:17
|
Now the CBAC feature set we know that there are two options that we can apply here
|
|
0:15:22
|
for the actual configuration
|
|
0:15:24
|
on the inside interface, which is fastethernet0/0
|
|
0:15:29
|
we could imply the inspection in
|
|
0:15:32
|
or on the outside interface, fastethernet 0/1, we could imply the inspection outbound
|
|
0:15:39
|
Now since there is only two interfaces here
|
|
0:15:42
|
its not really going to make a difference
|
|
0:15:44
|
would only be an issue if there was a
|
|
0:15:45
|
third interface here
|
|
0:15:48
|
fastethernet0/2 lets say, that may be goes to
|
|
0:15:52
|
the DMZ
|
|
0:15:54
|
that even though its in the same subnet
|
|
0:15:57
|
as router3 and router4
|
|
0:15:59
|
its in a different layer2 network because this would be in a different VLAN
|
|
0:16:04
|
Now again any time that we are
|
|
0:16:06
|
configuring three or more interfaces
|
|
0:16:08
|
generally that configuration would be easier to
|
|
0:16:12
|
manage using the zone based policy firewall
|
|
0:16:15
|
because we run it to the problem with the
|
|
0:16:17
|
the IP inspect, do we apply it in on the inside
|
|
0:16:21
|
out on the outside, out on DMZ
|
|
0:16:23
|
in on the DMZ etc
|
|
0:16:26
|
but with the zone based policy firewall its very
|
|
0:16:30
|
logical the way that the association are built
|
|
0:16:32
|
because we manually define the zone pairings
|
|
0:16:35
|
and then define what are the particular policies
|
|
0:16:38
|
that are going to apply to those parents
|
|
0:16:42
|
but again in this case since we only have two interfaces, one inside and one outside
|
|
0:16:46
|
the configuration either way is going to be fairly straight forward
|
|
0:16:50
|
or for CBAC, I can inspect inside in or outside out
|
|
0:16:54
|
for zone based policy firewall, I am going to
|
|
0:16:56
|
apply the policy to a pairing
|
|
0:16:58
|
that is applied9applied from the inside to the outside
|
|
0:17:07
|
So next lets look at hour
|
|
0:17:09
|
IPA inspect configuration with the CBAC
|
|
0:17:12
|
where as we know from our previous configurations, its going to be two portions
|
|
0:17:16
|
the actual inspection configuration
|
|
0:17:19
|
then an access list
|
|
0:17:21
|
that is going to deny the flows that are not already in the session table
|
|
0:17:27
|
So we need two nights here we need an access list
|
|
0:17:30
|
that is outside in
|
|
0:17:34
|
that says deny IPA any any
|
|
0:17:39
|
and additionally I would had a log statement onto that
|
|
0:17:43
|
then I have my actual inspection rule
|
|
0:17:46
|
we will say IPA inspect
|
|
0:17:48
|
the name is lets say
|
|
0:17:51
|
transparent
|
|
0:17:54
|
then what are the particular protocols that we cant to match
|
|
0:17:57
|
So we could, just like in zone based policy firewall we could do the application level inspections
|
|
0:18:02
|
if want basic
|
|
0:18:04
|
layer 3 layer 4 inspections, I could just say match TCP
|
|
0:18:08
|
match
|
|
0:18:09
|
USP
|
|
0:18:10
|
and then match IMP
|
|
0:18:14
|
hey next for the actual configuration
|
|
0:18:17
|
or the actual applications of the firewall
|
|
0:18:20
|
again fastened 0/1, this is our outside
|
|
0:18:24
|
interface
|
|
0:18:27
|
So on Ethernet fast Ethernet 0/1
|
|
0:18:30
|
we will say IPA inspect
|
|
0:18:33
|
and the name is transparent
|
|
0:18:37
|
this is going out
|
|
0:18:40
|
and I ip address group
|
|
0:18:42
|
outside in is applied inbound on that interface
|
|
0:18:49
|
Now if we look at the change what we should see
|
|
0:18:52
|
is that router4
|
|
0:18:54
|
is still able to send packets outbound
|
|
0:18:57
|
So if I were to ping the address of router3
|
|
0:19:00
|
this should be allowed
|
|
0:19:03
|
but if router3 is try to send packets back in to router4
|
|
0:19:08
|
these are going to denied
|
|
0:19:10
|
and additionally router6
|
|
0:19:12
|
we can see is logging
|
|
0:19:15
|
the packets are they are coming back inbound
|
|
0:19:20
|
So next lets look at the devices that are on the inside
|
|
0:19:23
|
if we were to go to router4
|
|
0:19:25
|
likewise we could see again that we can ping out to router3
|
|
0:19:29
|
if we try to go anywhere further than that
|
|
0:19:32
|
lets say we ping to
|
|
0:19:34
|
router1
|
|
0:19:35
|
we could see those flows are allowed to flow from the inside out and then return
|
|
0:19:40
|
likewise if we were to telnet to router1
|
|
0:19:43
|
since the
|
|
0:19:45
|
TCP traffic is being inspected
|
|
0:19:48
|
on router6 if we look at the show ip inspect sessions
|
|
0:19:53
|
we can see that it is monitoring
|
|
0:19:55
|
the telnet traffic that was originated from router4, going to router1
|
|
0:20:00
|
and these flows are being allowed back inbound
|
|
0:20:04
|
Now again if we were to try to go the reverse direction
|
|
0:20:07
|
If we were to go from the outside to in
|
|
0:20:10
|
if I try to telnet
|
|
0:20:12
|
to router4's address
|
|
0:20:14
|
we could see this is going to be denied and router6 does generate a log message for this
|
|
0:20:20
|
If I were to try to telnet to router6 itself
|
|
0:20:25
|
from the outside
|
|
0:20:28
|
we could see that this traffic is allowed
|
|
0:20:32
|
because there are no access list, so any inspections
|
|
0:20:35
|
being applied on the layer3 interface
|
|
0:20:40
|
So now on router6 if we wanted to
|
|
0:20:42
|
protect the local control plane
|
|
0:20:45
|
and limit who can actually send traffic
|
|
0:20:48
|
to the BVI interface itself
|
|
0:20:51
|
we would need to configure
|
|
0:20:52
|
a separate access list on that particular link
|
|
0:20:59
|
So if we look at our full configuration here, lets say show run include
|
|
0:21:04
|
or show run section inspect
|
|
0:21:06
|
or access list or interface
|
|
0:21:10
|
we could see that the overall configuration is
|
|
0:21:12
|
now fairly straight forward for the firewall policy
|
|
0:21:16
|
where the inspection rule says that TCP, UDP and ICMP traffic is going to be matched
|
|
0:21:22
|
then on the outside interface
|
|
0:21:25
|
we are inspecting the traffic as it goes out
|
|
0:21:27
|
as it returns back in, it is going to be denied by this access list
|
|
0:21:33
|
deny ip any any log
|
|
0:21:35
|
unless there is already an entry in state table
|
|
0:21:39
|
then again for the bridging configuration
|
|
0:21:42
|
if we show run
|
|
0:21:44
|
include
|
|
0:21:46
|
bridge or interface
|
|
0:21:50
|
we have the
|
|
0:21:52
|
the VLAN
|
|
0:21:53
|
defined or the bridge group defined
|
|
0:21:57
|
we have IRB enabled
|
|
0:21:59
|
for that bridge group or routing IP
|
|
0:22:01
|
and then we have the bridge applied on the interfaces
|
|
0:22:07
|
Now if we were to change these configuration to the zone based policy firewall
|
|
0:22:13
|
its going to be the same as any other
|
|
0:22:15
|
zone firewall configuration that we have done before
|
|
0:22:17
|
where we would have the two interfaces in separate zones
|
|
0:22:21
|
in this case I will have them on the inside and the outside zone
|
|
0:22:27
|
then we will have a pairing that
|
|
0:22:29
|
matches traffic as it goes from inside to outside
|
|
0:22:32
|
and I will tell it to inspect the TCP,UDP and ICMP flows
|
|
0:22:38
|
So first on this outside interface, I am going to remove the previous
|
|
0:22:42
|
CBAC configuration
|
|
0:22:44
|
so no ip inspect
|
|
0:22:46
|
no ip access group
|
|
0:22:50
|
the next step
|
|
0:22:52
|
would be to configure the actual zone, so we will say zone
|
|
0:22:56
|
security inside
|
|
0:22:58
|
we have another zone that is outside
|
|
0:23:03
|
next I want to know what is the traffic that I am going to inspect
|
|
0:23:08
|
we will say class map type inspect
|
|
0:23:11
|
match any
|
|
0:23:14
|
inside to outside class
|
|
0:23:18
|
says to match protocol TCP
|
|
0:23:21
|
UDP
|
|
0:23:23
|
and ICMP
|
|
0:23:26
|
where again I could get more granular here, I could do application level matches
|
|
0:23:30
|
I could do the layer 7 matches by calling the
|
|
0:23:34
|
class map type inspects of http, or smtp, pop3 etc
|
|
0:23:40
|
this case I am doing just a basic layer3, layer4
|
|
0:23:45
|
okay so I have the class that is defining the traffic
|
|
0:23:48
|
next I need to define what am I actually going to do with that traffic
|
|
0:23:51
|
so have the policy map type inspect
|
|
0:23:55
|
we will call this the inside to outside policy
|
|
0:24:00
|
that says for class
|
|
0:24:02
|
inside to outside class
|
|
0:24:06
|
I want to inspect the traffic
|
|
0:24:14
|
say now I know, what is the traffic, what am I going to do with it
|
|
0:24:18
|
I know what are the zones
|
|
0:24:21
|
Now I need to configure the association between the zones which is the zone pairing
|
|
0:24:25
|
and then actually apply the inside to outside policy
|
|
0:24:29
|
So when I have a zone pairing
|
|
0:24:31
|
we will say that this is the inside to
|
|
0:24:34
|
outside pairing
|
|
0:24:36
|
the source is the inside
|
|
0:24:39
|
the destination is the outside
|
|
0:24:42
|
the service policy applied is the inside to outside policy
|
|
0:24:49
|
then our very last step, we are applying this to the interfaces
|
|
0:24:52
|
zone member security on this link is outside
|
|
0:24:56
|
on fastethernet0/0, that is the inside
|
|
0:25:01
|
Now the end result should be the same as compared to the CBAC
|
|
0:25:05
|
where I should be able to ping from the inside out
|
|
0:25:09
|
I should be able to telnet from the inside out
|
|
0:25:12
|
if we now look at the
|
|
0:25:15
|
show policy map type inspect
|
|
0:25:19
|
inspect zone pair sessions
|
|
0:25:23
|
we see that there is the
|
|
0:25:28
|
the tcp connection from
|
|
0:25:31
|
router1 returning back to router4
|
|
0:25:37
|
and additionally notice that there is an access list log on the interface
|
|
0:25:42
|
this must not have been removed then
|
|
0:25:48
|
So it says access list outside in denied TCP
|
|
0:25:54
|
from 1 to 4
|
|
0:25:57
|
actually this is a delayed log from before
|
|
0:26:01
|
what this is showing is that
|
|
0:26:03
|
from the outside
|
|
0:26:06
|
which was router1
|
|
0:26:10
|
if I now telnet to router4
|
|
0:26:13
|
this is going to be dropped
|
|
0:26:15
|
because again I do not have now an inside to outside pairing
|
|
0:26:18
|
I have only inside to out
|
|
0:26:23
|
if we look at router3 and look at the show ip EIGRP neighbours
|
|
0:26:28
|
notice that this has not affected the control plane
|
|
0:26:33
|
which is the EIGRP adjacency between the router3 and the router4
|
|
0:26:36
|
we look at the show ip route eigrp
|
|
0:26:39
|
we could see that those routes are still installed
|
|
0:26:44
|
so essentially the only difference here in this configuration
|
|
0:26:48
|
what they are looking at it from the ip inspect
|
|
0:26:50
|
with the content based access control
|
|
0:26:53
|
or the zone based policy firewall
|
|
0:26:56
|
is that when we are applying it to the interfaces
|
|
0:26:59
|
the interfaces don't have IP addresses assigned
|
|
0:27:02
|
they are assigned to the bridge group
|
|
0:27:05
|
then the layer3 configuration
|
|
0:27:07
|
is going on the BVI
|
|
0:27:10
|
which is the integrated routing and bridging configuration
|
|
0:27:14
|
but if we look at our full zone configuration now we say show run show section or
|
|
0:27:20
|
class map or policy map
|
|
0:27:22
|
or ethernet
|
|
0:27:26
|
and if we look at the
|
|
0:27:28
|
the step by step association here, we have the
|
|
0:27:31
|
the zones are inside and outside
|
|
0:27:35
|
the traffic that is being matched is we go from inside to outside
|
|
0:27:39
|
is TCP
|
|
0:27:41
|
UDP and ICMP
|
|
0:27:44
|
the class is then called from the inside to outside policy
|
|
0:27:48
|
says for that traffic we are going to inspect it
|
|
0:27:50
|
for anything else thats going to be dropped
|
|
0:27:53
|
we then have the pairing
|
|
0:27:55
|
that is from the inside to outside
|
|
0:27:58
|
which has that policy applied
|
|
0:28:01
|
the zones are then applied to the interfaces
|
|
0:28:06
|
and again everything outside of this scope is going to be related to the underlying bridging
|
