|
0:00:13
|
In our next section here for the ASA we are going to look at the some configuration examples for the transparent firewall
|
|
0:00:19
|
where I have changed the topology around little bit
|
|
0:00:22
|
and the segment between router3 and router4
|
|
0:00:25
|
we are now going to be running ASA1 in transparent mode
|
|
0:00:30
|
Now notice here the key point that both router3
|
|
0:00:34
|
and router4 are on the same ip subnet
|
|
0:00:38
|
they are in the 172.16.34.0 network
|
|
0:00:42
|
but they are in separate VLANs
|
|
0:00:46
|
So thats that same layer3 network
|
|
0:00:48
|
but it is two separate layer 2 networks
|
|
0:00:52
|
So before we look at any other configuration of the ASA
|
|
0:00:56
|
we need to make sure that our underlying layer
|
|
0:00:58
|
2 network is working properly
|
|
0:01:00
|
So I need to know
|
|
0:01:02
|
from the physical layer 1 point of view
|
|
0:01:05
|
what is router3's
|
|
0:01:07
|
fast ethernet
|
|
0:01:08
|
0/1 connected to
|
|
0:01:10
|
some sort of layer 2 switch
|
|
0:01:13
|
then what is router4's
|
|
0:01:15
|
fast ethernet 0/1 connected to
|
|
0:01:19
|
then how are the e0/0
|
|
0:01:22
|
and the e0/1 interfaces of the ASA connected
|
|
0:01:27
|
Now again specifically within the scope of the
|
|
0:01:30
|
CCIE security exam
|
|
0:01:32
|
they will give you a list
|
|
0:01:34
|
of what the physical connectivity is
|
|
0:01:37
|
and since the ASAs do not support CDP
|
|
0:01:40
|
really there is not a very efficient way that you can figure out how
|
|
0:01:43
|
the physical connection is working
|
|
0:01:45
|
without really having any documentation of the network
|
|
0:01:49
|
now again in my case if we look at the show interface
|
|
0:01:53
|
show interfaces status
|
|
0:01:57
|
and I will exclude any of the links that are not connected
|
|
0:02:00
|
I do have descriptions
|
|
0:02:02
|
configured so we can clearly see exactly what is the
|
|
0:02:05
|
the physical connectivity
|
|
0:02:07
|
So essentially I need to make sure
|
|
0:02:10
|
that the link that is going
|
|
0:02:12
|
to router4's
|
|
0:02:14
|
fastethernet 0/0
|
|
0:02:16
|
which in this case I have configured VLAN 14
|
|
0:02:20
|
is the same as the ASAs
|
|
0:02:23
|
e0/1 interface
|
|
0:02:26
|
which again is being used on the inside
|
|
0:02:30
|
So this inside link here e0/1
|
|
0:02:33
|
I need to make sure its in the same segment as router4
|
|
0:02:37
|
Now assuming that this VLAN is actually created
|
|
0:02:41
|
and there is nothing wrong
|
|
0:02:43
|
at this point I simply need to look at the
|
|
0:02:46
|
the show spanning tree for VLAN 14
|
|
0:02:49
|
and make sure that VLAN is actually forwarding over the links
|
|
0:02:54
|
which in this case are port fast ethernet 4
|
|
0:02:58
|
and port fast ethernet 13
|
|
0:03:02
|
So the segment between router4 and the ASA are fine
|
|
0:03:06
|
for the segment between router3 and ASA
|
|
0:03:10
|
we will look at the show interface status
|
|
0:03:13
|
exclude the not connected ports and switch to
|
|
0:03:17
|
specifically these links
|
|
0:03:20
|
are fast ethernet 0/3
|
|
0:03:22
|
which is connecting to router3's fast ethernet 0/1
|
|
0:03:26
|
this is in VLAN 13
|
|
0:03:29
|
which is the same as
|
|
0:03:31
|
the ASAs
|
|
0:03:33
|
is e0/0 interface
|
|
0:03:36
|
So again the key point being here that even though the devices are in the same layer 3 network
|
|
0:03:42
|
they are in two separate layer 2 segments or two separate VLANs
|
|
0:03:47
|
So in order to get the traffic to move
|
|
0:03:50
|
from router4 on the inside
|
|
0:03:52
|
to router3 on the outside
|
|
0:03:54
|
we have to go through the
|
|
0:03:56
|
Modular Policy Framework inspection
|
|
0:03:58
|
or any of our access-list exceptions
|
|
0:04:01
|
that were doing on the ASA
|
|
0:04:05
|
Now again once we do the configuration of the transparent firewall
|
|
0:04:09
|
it is going to remove any of the
|
|
0:04:11
|
other routed firewall
|
|
0:04:13
|
configurations that we have
|
|
0:04:15
|
So essentially we would want to start from the blank configuration to begin with
|
|
0:04:19
|
which is
|
|
0:04:21
|
what we have here on asa1
|
|
0:04:26
|
if we look at the show mode
|
|
0:04:29
|
we see that we were in single context mode
|
|
0:04:32
|
if we look at the show firewall
|
|
0:04:35
|
tells that we were
|
|
0:04:39
|
So by default when you boot up the ASA with the blank configuration
|
|
0:04:43
|
its going to be running with the single context mode with routed firewall
|
|
0:04:47
|
Now at this point I still want single contacts mode, we will talk about multiple contacts mode later
|
|
0:04:52
|
But I want to change from the
|
|
0:04:54
|
routed firewall to the transparent firewall
|
|
0:04:57
|
So in global config
|
|
0:04:59
|
first thing I need to specify
|
|
0:05:01
|
is simply
|
|
0:05:02
|
firewall transparent
|
|
0:05:10
|
we now look at the show firewall
|
|
0:05:12
|
since now we are running in layer 2 mode which is transparent mode
|
|
0:05:16
|
if we look at the change in the
|
|
0:05:19
|
running configuration
|
|
0:05:20
|
is not really obvious that
|
|
0:05:22
|
we are running in
|
|
0:05:24
|
transparent mode as opposed to the routed mode
|
|
0:05:27
|
there will be a command in here
|
|
0:05:30
|
somewhere in the config that we are running in the transparent mode
|
|
0:05:34
|
but the rest of the defaults look fairly similar
|
|
0:05:37
|
now one we we can we that we are
|
|
0:05:40
|
or not running in routed mode
|
|
0:05:43
|
lets configure hostname here lets say asa1
|
|
0:05:47
|
you will see lot of the command feature sets are no longer available
|
|
0:05:51
|
so most of the crypto commands are not going to be there
|
|
0:05:54
|
I will see some of the minor ones will be available
|
|
0:05:57
|
but again this is only for terminating management
|
|
0:06:01
|
on the asa, so just for telnet or SSH or ASTN access
|
|
0:06:07
|
If I were to go the link levels
|
|
0:06:11
|
If I were to configure an IP address
|
|
0:06:17
|
we could see that this drops me
|
|
0:06:20
|
back down to global configuration mode
|
|
0:06:24
|
So I was at the interface level
|
|
0:06:27
|
I issued the IP address
|
|
0:06:31
|
but if we look at the contacts instead of help, it says
|
|
0:06:34
|
actually this command IP address
|
|
0:06:36
|
is not at the interface mode, its actually at
|
|
0:06:38
|
global configuration mode
|
|
0:06:41
|
So you do need to be careful when you are looking at the person mode
|
|
0:06:45
|
of either the asa or the IOS
|
|
0:06:48
|
when you enter a command
|
|
0:06:50
|
and it returns it back to
|
|
0:06:52
|
a different mode
|
|
0:06:55
|
it means that the commands was actually accepted in this mode
|
|
0:07:01
|
Now the asa this going to get a little bit confusing than the IOS
|
|
0:07:05
|
because the lot of the different modes of commands
|
|
0:07:08
|
are available on the asa
|
|
0:07:11
|
to be issued from a different mode than that you are in
|
|
0:07:14
|
So if I am in router ospf mode, I can still issue global configuration commands
|
|
0:07:20
|
where in the case of the router normally you will have to exit out of the router mode back to the global config
|
|
0:07:25
|
In order to make those changes
|
|
0:07:27
|
but now if we look at the results of
|
|
0:07:30
|
show run interface ethernet 0/0
|
|
0:07:33
|
notice that the IP address did actually apply there
|
|
0:07:37
|
So its actually applied in global config
|
|
0:07:44
|
So my next step is that we need to enable the physical links
|
|
0:07:48
|
So I will say an ethernet 0/0
|
|
0:07:51
|
this is not shut down
|
|
0:07:53
|
either its ethernet 0/0
|
|
0:07:56
|
I am going to assign them the names
|
|
0:07:59
|
which again e0/1, this is my inside
|
|
0:08:03
|
and e0/0 is going to be my outside
|
|
0:08:09
|
So e0/1 this is nameif inside
|
|
0:08:12
|
which is giving me security level 100
|
|
0:08:15
|
e0/0 is nameif outside
|
|
0:08:18
|
which is going to default to 0
|
|
0:08:22
|
So now the asa should allow traffic to move from the high security to low
|
|
0:08:28
|
or inside to outside and then return
|
|
0:08:32
|
but its not going to allow the solicited request
|
|
0:08:35
|
from the outside in
|
|
0:08:41
|
Now at this point, this is pretty much the only basic configuration that we need
|
|
0:08:46
|
as long as the firewall is running in transparent mode
|
|
0:08:49
|
the links are enabled
|
|
0:08:51
|
I have the names and the security levels
|
|
0:08:53
|
I should now be able to send the traffic through the asa
|
|
0:08:58
|
Now if I want to go to router4
|
|
0:09:01
|
since I know that with the Modular Policy Framework
|
|
0:09:04
|
I am already inspecting TCP by default
|
|
0:09:08
|
I should be able to telnet from router4 to 3
|
|
0:09:12
|
and if I get the login a prompt
|
|
0:09:15
|
I known that the bidirectional TCP flow
|
|
0:09:17
|
is actually being inspected by the firewall
|
|
0:09:21
|
So from router4
|
|
0:09:24
|
lets telnet to the 17216.34.3 address
|
|
0:09:34
|
We can see the connection does open
|
|
0:09:36
|
if we look at the asa and now look at the
|
|
0:09:40
|
show connections, or the show connection detail
|
|
0:09:45
|
we could see from the inside interface
|
|
0:09:50
|
we had a session that was originated from 172.16.34.4
|
|
0:09:55
|
it is a TCP packet
|
|
0:09:58
|
it was sourced from this random high port
|
|
0:10:01
|
it was destined to
|
|
0:10:03
|
172.16.34.3
|
|
0:10:06
|
on the outside interface going to port 23
|
|
0:10:12
|
So this then means when the asa needs to allow this traffic back in
|
|
0:10:16
|
at least to allow in on the outside interface from
|
|
0:10:21
|
172.16.34.3 with a source port of 23
|
|
0:10:26
|
going to the inside host 172.16.34.4 at this destination port
|
|
0:10:33
|
because remember what we talked about with the standard versus non standard TCP applications
|
|
0:10:38
|
since telnet is a standard app
|
|
0:10:40
|
means that the outbound flow
|
|
0:10:42
|
is an exact mere image of the inbound flow
|
|
0:10:48
|
now for any type of traffic that is not being inspected
|
|
0:10:51
|
for example our ping traffic by default
|
|
0:10:58
|
we see that router4 is not able to send ICMP from the inside out
|
|
0:11:05
|
now just like the routed mode in the firewall
|
|
0:11:07
|
there is a couple of different ways that we can fix this, assuming we do want
|
|
0:11:11
|
pings to go from the inside out and then return
|
|
0:11:13
|
we could either inspect them
|
|
0:11:16
|
with the Modular Policy Framework
|
|
0:11:18
|
So edit our global policy
|
|
0:11:20
|
and say for the
|
|
0:11:22
|
class inspection default, I want to inspect ICMP
|
|
0:11:26
|
I do create a second policy
|
|
0:11:29
|
thats apply to one of the specific interfaces
|
|
0:11:32
|
or I could use a access list as an exception
|
|
0:11:37
|
Now in the stateful or, excuse me, in the transparent firewall
|
|
0:11:41
|
there is really no need to apply
|
|
0:11:44
|
a policy to an individual interface
|
|
0:11:47
|
because there is only two links
|
|
0:11:50
|
now we are not going to use the QoS features, we are not going to use any of the VPN features
|
|
0:11:55
|
So one were doing the instructions
|
|
0:11:57
|
we are doing a MPF policy
|
|
0:11:59
|
or may be doing it just for the purpose of inspection
|
|
0:12:03
|
and remember that when we apply inspection to the interface, its bidirectional
|
|
0:12:08
|
So applied a policy to the inside interface
|
|
0:12:11
|
its inside in and inside out
|
|
0:12:14
|
which essentially is the same as saying, outside in
|
|
0:12:18
|
or inside in
|
|
0:12:20
|
So essentially you could use the same, you could use a single global policy and you don't need to add any additional ones on to it
|
|
0:12:27
|
So next lets see, can we actually get
|
|
0:12:30
|
the asa to actually allow this traffic through
|
|
0:12:33
|
Now before we do that
|
|
0:12:35
|
lets turn logging on
|
|
0:12:38
|
on and logging console 7
|
|
0:12:43
|
So I am going to see exactly what traffic is being dropped and what traffic is being permited
|
|
0:12:48
|
if I try to send the pings through
|
|
0:12:51
|
the asa should see this and says I am denying
|
|
0:12:54
|
inbound ICMP
|
|
0:12:57
|
on the outside interface
|
|
0:13:01
|
its coming from 172.16.34.3, its trying to go back to
|
|
0:13:06
|
the inside
|
|
0:13:07
|
so it is type 0 code 0
|
|
0:13:11
|
What this means is that the ICMP flow
|
|
0:13:15
|
actually did get
|
|
0:13:17
|
from 4 to 3
|
|
0:13:20
|
So this is the ICMP ping or the echo
|
|
0:13:25
|
when a router3 tries to reply though
|
|
0:13:27
|
this is where its being dropped
|
|
0:13:30
|
So it is the echo reply
|
|
0:13:33
|
that the asa is saying that did not inspect this
|
|
0:13:36
|
so I am not going to allow it back in on the outside interface
|
|
0:13:42
|
so technically the traffic is not being dropped from inside out
|
|
0:13:44
|
is just not being inspected from the inside out
|
|
0:13:48
|
so if I want to allow it from outside in
|
|
0:13:51
|
I could there configure the manual exception
|
|
0:13:54
|
or tell to actually do the inspection
|
|
0:13:57
|
as this traffic is leaving
|
|
0:14:01
|
now let me talk about before from a real world design
|
|
0:14:05
|
you generally would want to do the inspection
|
|
0:14:11
|
say no logging console
|
|
0:14:13
|
you would want to do the inspection as opposed to do the access-list exception
|
|
0:14:17
|
because the acl exception would allow you
|
|
0:14:21
|
are to be open to one of the reverse denial of service attacks
|
|
0:14:24
|
where some is doing the smurf attack to
|
|
0:14:29
|
do a flooding attack with ICMP echo replies
|
|
0:14:33
|
So would I would want to say here show run policy map
|
|
0:14:37
|
I would want to say for my global policy and class inspection default
|
|
0:14:42
|
I want to inspect ICMP
|
|
0:14:48
|
so now if we turn logging back on
|
|
0:14:52
|
we should see that now this flow is inspected
|
|
0:14:55
|
which allows the return packets
|
|
0:14:59
|
and we will say loging, logging console 7 again
|
|
0:15:04
|
So we should see that the asa is creating a flow for this
|
|
0:15:09
|
and then closing the connection
|
|
0:15:12
|
once the echo reply comes back in from 3 to 4
|
|
0:15:17
|
so its not allowing any unsolicited traffic
|
|
0:15:20
|
So I could not ping from
|
|
0:15:22
|
3 into 4
|
|
0:15:26
|
because this is moving from the low security interface to the high security interface
|
|
0:15:32
|
if I wanted to allow any flows
|
|
0:15:35
|
to go in this direction
|
|
0:15:39
|
so to be originated from router3
|
|
0:15:41
|
at least I would need a manual access list exception
|
|
0:15:46
|
otherwise the only step thats going to be allowed from 3 to router4
|
|
0:15:50
|
is traffic that doesn't responds
|
|
0:15:53
|
to something that was not initiated from the inside
|
|
0:15:56
|
So its the same normal logic as the
|
|
0:15:58
|
the normal routed firewall's inspection
|
|
0:16:04
|
Now the next potential issue that we run into
|
|
0:16:07
|
is that if we look at the logging on the asa
|
|
0:16:10
|
we can see that it is dropping additional packets
|
|
0:16:14
|
both on the inside interface and the outside interface
|
|
0:16:20
|
It says that we have inbound
|
|
0:16:23
|
traffic that is protocol number 88
|
|
0:16:26
|
this is being dropped both from
|
|
0:16:28
|
router3 and from router4
|
|
0:16:32
|
as it is coming in on the inside and in on the outside
|
|
0:16:35
|
and the destination address here
|
|
0:16:38
|
is 224.0.0.10
|
|
0:16:41
|
So this is our EIGRP multicast
|
|
0:16:46
|
if we look at router4
|
|
0:16:48
|
and look at the show ip eigrp interfaces
|
|
0:16:52
|
we had eigrp as number 34
|
|
0:16:55
|
configured on its link
|
|
0:16:57
|
fast ethernet 0/0
|
|
0:17:01
|
so this is where we are trying to eshtablish an agency with router3
|
|
0:17:05
|
but the asa now
|
|
0:17:08
|
is dropping the traffic as it is coming
|
|
0:17:10
|
in on the inside
|
|
0:17:13
|
and again this is our issue with the control plane
|
|
0:17:16
|
not being inspected
|
|
0:17:19
|
So if I wanted to form a routing agency
|
|
0:17:22
|
or may be run
|
|
0:17:24
|
multicast routing with protocol independent multicast
|
|
0:17:27
|
or run any type of non IP protocol
|
|
0:17:31
|
I am going to need to make a manual exception to this, with an access-list
|
|
0:17:37
|
So lets now say that over this link, over this VLAN
|
|
0:17:41
|
113 and the VLAN 114
|
|
0:17:43
|
I want to make sure that I can eshtablish
|
|
0:17:45
|
an eigrp agency
|
|
0:17:49
|
between
|
|
0:17:52
|
router3 and router4
|
|
0:17:54
|
now we can see the list under loggings, specifically what this traffic is, EIGRP is protocol number 88
|
|
0:18:12
|
its protocol number 88 and its using
|
|
0:18:15
|
traffic sourced from the addresses on router3 and router4
|
|
0:18:19
|
going to the multicast 224.0.0.10
|
|
0:18:25
|
So first lets try to permit these flows
|
|
0:18:29
|
So I am going to create an access list
|
|
0:18:32
|
will say access-list
|
|
0:18:34
|
inside in
|
|
0:18:36
|
permit eigrp any host
|
|
0:18:41
|
224.0.0.10, or actually we can be more specific
|
|
0:18:45
|
lets say fourth between the individual host, lets say, on the inside in
|
|
0:18:50
|
this is going to be coming from
|
|
0:18:52
|
router 4
|
|
0:18:54
|
on the outside in
|
|
0:18:59
|
so i need two different lists
|
|
0:19:01
|
inside in and outside in
|
|
0:19:04
|
outside in is coming from router 3
|
|
0:19:06
|
and i have access through
|
|
0:19:09
|
inside in and interface inside
|
|
0:19:12
|
and access through
|
|
0:19:18
|
outside in
|
|
0:19:20
|
in interface outside
|
|
0:19:22
|
so again this is one of the exceptions here with the transparent firewall
|
|
0:19:26
|
that normally all the traffic is allowed in or on inside interface
|
|
0:19:31
|
but in the case of transparent
|
|
0:19:33
|
the control plan is being dropped
|
|
0:19:38
|
so lets see once we apply these two lists
|
|
0:19:47
|
we now have a new traffic flow
|
|
0:19:50
|
that is being denied
|
|
0:19:54
|
lets say no logging
|
|
0:19:58
|
no logging console
|
|
0:20:00
|
hey notice that its now changed as to what was being dropped
|
|
0:20:04
|
previously it said that i was denying protocol 88 which is eigrp
|
|
0:20:10
|
coming from router 3 coming from router 4
|
|
0:20:13
|
coming in the inside and outside interfaces respectively
|
|
0:20:16
|
and it was going to the multicast 224.0.0.10
|
|
0:20:21
|
so these are eigrp hello packets
|
|
0:20:24
|
where router 3 and router 4
|
|
0:20:25
|
are trying to discover who are the other neighbours
|
|
0:20:29
|
that are running eigrp on that link
|
|
0:20:31
|
so first they are trying to find each other
|
|
0:20:34
|
now once the multicasts go through
|
|
0:20:38
|
router 3 and 4 are now actually trying to establish an adjacency
|
|
0:20:42
|
and in the case of eigrp
|
|
0:20:45
|
the actual adjacency establishment
|
|
0:20:47
|
and the syncronization of the topology
|
|
0:20:50
|
which is the actual exchange of the updates
|
|
0:20:52
|
is using unicasts
|
|
0:20:55
|
not multicasts
|
|
0:20:58
|
so notice now here
|
|
0:21:01
|
that the asa is now denying
|
|
0:21:03
|
in on the inside
|
|
0:21:07
|
and in on the outside
|
|
0:21:11
|
the unicast eigrps
|
|
0:21:15
|
now if we look at specifically the access lists that i use lets look at the show
|
|
0:21:19
|
show run access lists
|
|
0:21:22
|
i said to permit just the eigrp multicast
|
|
0:21:26
|
now had i said access list inside in permit eigrp any any
|
|
0:21:30
|
and access list outside in permit any any
|
|
0:21:33
|
this would acount for both the multicast and the unicast
|
|
0:21:39
|
but the key point i am trying to illustrate here
|
|
0:21:41
|
is that if you don't know exactly what the traffic flow is that you are trying to match
|
|
0:21:47
|
you can end up dropping different pieces that you really didn't make out for in the first place
|
|
0:21:52
|
so in the case of the eigrp its not only the multicasts
|
|
0:21:55
|
but its also the unicast
|
|
0:21:58
|
so i would need to edit this list a little bit i would need to say
|
|
0:22:01
|
i need to permit on the inside in
|
|
0:22:04
|
not only the
|
|
0:22:06
|
multicasting router 4
|
|
0:22:08
|
but the unicast from 4 to 3
|
|
0:22:12
|
then like wise on the way back
|
|
0:22:14
|
on the outside in
|
|
0:22:17
|
i need to unicast that are coming from 3 and then returning back to 4
|
|
0:22:24
|
and again i could be less specific here if i said eigrp any any
|
|
0:22:29
|
thats going to account for all of the flows
|
|
0:22:32
|
but typically in your firewall rules you would want to be as specific as possible
|
|
0:22:36
|
So you are not allowing traffic through
|
|
0:22:38
|
it doesn't actually need to
|
|
0:22:41
|
be allowed through the filter
|
|
0:22:43
|
So you are going to permit the minimum amount
|
|
0:22:45
|
of flows and then implicitly drop anything else
|
|
0:22:50
|
Now what we should see
|
|
0:22:52
|
is that now router3 and router4 actually form the agency
|
|
0:22:56
|
previously they were getting these error messages where the retry limit was exceeded
|
|
0:23:04
|
So retry limit was exceeded this means
|
|
0:23:07
|
that they had discovered each other
|
|
0:23:10
|
by using the multicasts
|
|
0:23:13
|
but they then could not actually form the agency because there was a unicast transport problem
|
|
0:23:19
|
but we now actually see that the agencies are eshtablished
|
|
0:23:22
|
if we look at now the routing table
|
|
0:23:25
|
of router4, we show ip route eigrp
|
|
0:23:28
|
router4 is learning a default route from router3
|
|
0:23:33
|
we were to look at router3
|
|
0:23:35
|
we show ip route eigrp
|
|
0:23:38
|
we see that it is learning a
|
|
0:23:41
|
route that is 172.16.4.0
|
|
0:23:45
|
from router 4
|
|
0:23:47
|
and then it has this somebody over default router that is advertising to router4
|
|
0:23:52
|
So we can tell now that the advertisements are working, so 4 is getting
|
|
0:23:55
|
the default 0.0.0.0/0
|
|
0:23:59
|
and then router4 is advertising this segment to router3
|
|
0:24:05
|
so I want to know
|
|
0:24:08
|
that, since the routing plane is now working
|
|
0:24:12
|
can I actually get traffic to transit from
|
|
0:24:15
|
the inside segment
|
|
0:24:17
|
of this VLAN4
|
|
0:24:19
|
to somewhere else on the outside
|
|
0:24:23
|
So lets say to start just this address on router3
|
|
0:24:27
|
So on the asa, lets continue to log, so lets say logging console 7 again
|
|
0:24:33
|
because I want to know if a flow is dropped
|
|
0:24:36
|
specifically what that flow was
|
|
0:24:41
|
So now on router4 lets say ping
|
|
0:24:43
|
172.16.34.3
|
|
0:24:48
|
but I am going to source this traffic now from
|
|
0:24:51
|
my inside lan interface 172.16.4.4
|
|
0:24:58
|
and notice now
|
|
0:25:00
|
the flow is being dropped
|
|
0:25:03
|
where previously the ICMP was allowed
|
|
0:25:09
|
So neither the ping from the normal outgoing interface
|
|
0:25:13
|
were the ping from the inside interface was working
|
|
0:25:22
|
So why with the ICMP ping have worked before
|
|
0:25:26
|
but now its being denied
|
|
0:25:29
|
now lets try the same thing with telnet, lets say telnet to 172.16.34.3
|
|
0:25:35
|
connection is refused
|
|
0:25:39
|
the reason why is now I have a acl that is
|
|
0:25:42
|
inside in
|
|
0:25:46
|
where under your normal cases of inspection
|
|
0:25:49
|
you do not have an access list that is applied in on an inside interface
|
|
0:25:53
|
you may applied in on the outside interface
|
|
0:25:57
|
but thats used to make an exception to traffic that was not already inspected
|
|
0:26:03
|
so essentially what the problem is, is that we have an order of operations issue
|
|
0:26:08
|
of the access lists
|
|
0:26:10
|
versus the Modular Policy Framework
|
|
0:26:13
|
Now if we look at the diagram and try to visualise the flow
|
|
0:26:17
|
the issue is that
|
|
0:26:20
|
on the inside interface in
|
|
0:26:23
|
the access-list
|
|
0:26:25
|
is being processed before
|
|
0:26:28
|
the Modular Policy Framework
|
|
0:26:32
|
where the access-list is ending in an implicit deny
|
|
0:26:37
|
So just like any other access-list in the asa or the IOS
|
|
0:26:41
|
or like a route map
|
|
0:26:43
|
where it was going to end in an implicit deny
|
|
0:26:47
|
However on the outside in
|
|
0:26:50
|
we normally process the
|
|
0:26:55
|
acl first
|
|
0:26:58
|
and then the
|
|
0:27:00
|
actually the other way around, its going to be the
|
|
0:27:03
|
the Modular Policy Framework
|
|
0:27:05
|
and then the acl
|
|
0:27:08
|
because even if would have an
|
|
0:27:10
|
access-list that says outside in
|
|
0:27:14
|
that is denying everything, if I said just deny ip any any
|
|
0:27:17
|
this would still allow
|
|
0:27:20
|
the traffic that was already inspected
|
|
0:27:24
|
So essentially this state table on the way from the outside back in
|
|
0:27:28
|
is an exception
|
|
0:27:30
|
to any of the access list filter that you have applied inbound there
|
|
0:27:34
|
but the order is different when we are going inside in
|
|
0:27:39
|
so what would I need to do in order to fix this
|
|
0:27:47
|
I am going to need to change my inside in access-list
|
|
0:27:52
|
to explicitly allow any flows that I want
|
|
0:27:57
|
so now inside in not only do I need to permit the eigrp control plane
|
|
0:28:01
|
I would need to say
|
|
0:28:03
|
most likely something like inside in
|
|
0:28:05
|
permit TCP any any
|
|
0:28:07
|
and permit UDP any any
|
|
0:28:11
|
and permit ICMP any any
|
|
0:28:14
|
Now assuming I want the inside host to actually use all of those applications
|
|
0:28:18
|
if I wanted them only to use web browsing
|
|
0:28:21
|
I could say may be permit tcp any any thats just equal to 80
|
|
0:28:25
|
or if I have some specific UDP applications like
|
|
0:28:29
|
may be I am only allowing them to get network time protocol from the outside
|
|
0:28:33
|
I will say permit udp equal to 123
|
|
0:28:36
|
or may be ICMP that is just an echo
|
|
0:28:42
|
So this is a different
|
|
0:28:44
|
filtering module
|
|
0:28:46
|
that we see with the transparent firewall versus the routed firewall
|
|
0:28:50
|
because routed firewall is going to allow all of the flows from inside out
|
|
0:28:56
|
where in the case of the transparent firewall since we are making a exception to inside in
|
|
0:29:02
|
we now need to account for this
|
|
0:29:05
|
access-list inside in deny
|
|
0:29:08
|
IP any any
|
|
0:29:10
|
that is really the implicit match
|
|
0:29:14
|
So even though the last line does not show up the configuration, its always there
|
|
0:29:18
|
there is always a deny ip any any at the end of the all access lists
|
|
0:29:26
|
hey, so now lets see on the asa, once I
|
|
0:29:29
|
add these new statements
|
|
0:29:30
|
I show run access-list
|
|
0:29:34
|
can see now inside in says the tcp traffic is okay, the udp traffic is okay, the icmp is okay
|
|
0:29:41
|
lets see now
|
|
0:29:42
|
now is the bidirectional flow is going to work
|
|
0:29:45
|
So from router4
|
|
0:29:47
|
can I telnet to 3
|
|
0:29:48
|
hey now I can
|
|
0:29:51
|
I should also be able to ping them
|
|
0:29:54
|
because I am inspecting that
|
|
0:29:56
|
and also ping them if I am sourcing it from my inside interface
|
|
0:30:00
|
because I am advertising this now to them through eigrp
|
|
0:30:05
|
but notice here on the access-list outside in
|
|
0:30:09
|
even though there is the implicit deny here as well
|
|
0:30:13
|
So access-list outside in deny ip any any
|
|
0:30:19
|
this entry does not actually take an effect
|
|
0:30:23
|
if there is already an inspection in the state table
|
|
0:30:28
|
So from inside out
|
|
0:30:31
|
the access-list is checked first
|
|
0:30:33
|
from outside in
|
|
0:30:35
|
the state table is checked first
|
|
0:30:39
|
and we will see this is similar to how the IOS deals with this
|
|
0:30:42
|
when we are doing either reflexive access-list
|
|
0:30:45
|
content based access control
|
|
0:30:47
|
or the zone based policy firewall
|
|
0:30:51
|
Now again as I mentioned
|
|
0:30:53
|
you don't neccessary need to memorise what are all the traffic flows that are permitted or denied
|
|
0:30:58
|
as long as you look at the logging from the command line
|
|
0:31:02
|
we can clearly see that there is a problem with the list
|
|
0:31:05
|
or previously that there was a problem with the
|
|
0:31:09
|
the eigrp control plane that was coming in
|
|
0:31:13
|
Now likewise if I were to
|
|
0:31:15
|
lets say try to run multicast routing
|
|
0:31:18
|
So ip multicast routing
|
|
0:31:20
|
on my lan interface I have ippm in sparse mode
|
|
0:31:27
|
and the same thing on router3
|
|
0:31:29
|
So on global config, ip multicast routing
|
|
0:31:33
|
the lan interface ippm sparse mode
|
|
0:31:37
|
If we look at the asa
|
|
0:31:40
|
We could see now that there are two different protocol that are being denied
|
|
0:31:45
|
protocol number 2
|
|
0:31:48
|
and protocol number 103
|
|
0:31:53
|
Now protocol number 2
|
|
0:31:55
|
it says that
|
|
0:31:58
|
protocol number 2 is coming from router3
|
|
0:32:02
|
the destination is 224.0.0.1
|
|
0:32:07
|
where protocol number 103
|
|
0:32:11
|
it also came from router3
|
|
0:32:14
|
but it has got a different destination, destination 224.0.0.13
|
|
0:32:22
|
Now does any one know the difference between which these two are
|
|
0:32:26
|
what is protocol 2, what is protocol 103
|
|
0:32:32
|
Number 103 going to 224.0.0.13, this is
|
|
0:32:36
|
the protocol independent multicast protocol
|
|
0:32:39
|
protocol number 2
|
|
0:32:42
|
going to the all router multicast or excuse me the all host multicast
|
|
0:32:46
|
224.0.0.1
|
|
0:32:49
|
this is igmp
|
|
0:32:50
|
the internet group management protocol
|
|
0:32:52
|
So protcol number 2 is normally what we would need from the multicast router down to the end client
|
|
0:32:58
|
where protocol 103 is what I need between the routers
|
|
0:33:02
|
So I technically don't need to allow protocol 2 through
|
|
0:33:06
|
because if this is just a transit link between them
|
|
0:33:09
|
So may be I have my IGMP client here
|
|
0:33:14
|
and then I have some multicast flow
|
|
0:33:16
|
thats coming from the outside in
|
|
0:33:19
|
I don't neccessarily need igmp, its run between router3 and router4
|
|
0:33:24
|
as long as I allow PIM, Protocol Independent Multicast
|
|
0:33:28
|
this is going to allow them to form the multicast routing agency
|
|
0:33:32
|
but we could see just like the other control plane protocols
|
|
0:33:36
|
this is being dropped by default
|
|
0:33:39
|
its being dropped as it comes in on the inside
|
|
0:33:44
|
and its being dropped as it comes in on the outside
|
|
0:33:48
|
So now I would need two additional exceptions
|
|
0:33:51
|
to these access-list
|
|
0:33:53
|
I will say access-list outside in
|
|
0:33:55
|
I want to permit PIM
|
|
0:33:59
|
Now just like the EIGRP I could be more specific if I wanted to hear
|
|
0:34:03
|
but I am just going to say for
|
|
0:34:06
|
for any of the PIM traffic
|
|
0:34:15
|
Now there is a question here - How does a asa know what is control plane, what is data plane?
|
|
0:34:20
|
- Its base on the specific MAC addresses
|
|
0:34:22
|
So if you look at the documentation
|
|
0:34:25
|
It tells you exactly what is allowed and what is not
|
|
0:34:28
|
If you go to the ASA configs
|
|
0:34:31
|
then under
|
|
0:34:47
|
under configuring the firewall
|
|
0:34:50
|
configuring arp inspections and bridging parameters in transparent mode
|
|
0:34:54
|
So in this document it should show us
|
|
0:34:58
|
actually not in this one, it is in, lets see ..
|
|
0:35:05
|
its under firewall mode overview
|
|
0:35:08
|
So under configuring the firewall, firewall mode overview
|
|
0:35:11
|
then transparent firewall
|
|
0:35:14
|
it says allowed layer 3 traffic and allowed MAC addresses
|
|
0:35:18
|
So allowed layer 3
|
|
0:35:21
|
says IPv4 traffic is allowed through transparent firewall
|
|
0:35:24
|
automatically from high to low without access-list
|
|
0:35:27
|
arps are allowed in both directions without an acl
|
|
0:35:31
|
arp could be controled by arp inspection, hey, we will look at that in a couple of minutes here
|
|
0:35:35
|
for other destinations
|
|
0:35:38
|
these specific multicast addresses
|
|
0:35:42
|
are allowed through
|
|
0:35:44
|
but any MAC address that is not on the list is dropped
|
|
0:35:49
|
So it has to do with the specific transport protocol thats being used
|
|
0:35:55
|
which the other control plane protocols like ospf, eigrp, pim
|
|
0:36:01
|
IOS to IOS, they are not using these formats in layer 2
|
|
0:36:07
|
Hey, also , the key here, it says
|
|
0:36:11
|
non IP traffic
|
|
0:36:14
|
such as MPLS would be one
|
|
0:36:17
|
bpt used for
|
|
0:36:18
|
layer 2 spanning tree, this stuff is going to be denied
|
|
0:36:21
|
Now you can allow it with an ether type access list
|
|
0:36:24
|
its just not going to be allowed
|
|
0:36:26
|
automatically by default
|
|
0:36:31
|
okay, so lets see now, if we go to router4
|
|
0:36:34
|
we see now the message we have the pm agency
|
|
0:36:37
|
if we show ippm neighbours
|
|
0:36:43
|
okay, now we have our multicast routing agencies there
|
|
0:36:46
|
and we also have our unicast eigrp agency
|
|
0:36:52
|
Now in this version
|
|
0:36:55
|
the inspection of IPv6 traffic
|
|
0:36:59
|
is not allowed
|
|
0:37:00
|
in some of the later versions that is routing support for
|
|
0:37:05
|
IPv6
|
|
0:37:07
|
So, if router3 and router4 were running this, if I say IPv6
|
|
0:37:11
|
unicast routing
|
|
0:37:14
|
then on the link level lets say IPv6 address
|
|
0:37:19
|
will this use a basic address, lets say 2001
|
|
0:37:22
|
::4/64
|
|
0:37:26
|
and if router3 were to do the same thing, lets say IPv6
|
|
0:37:30
|
unicast routing
|
|
0:37:32
|
then on fast ethernet 0/1
|
|
0:37:35
|
IPv6 address 2001::3
|
|
0:37:39
|
/64
|
|
0:37:42
|
ideally
|
|
0:37:44
|
from 4 to 3
|
|
0:37:47
|
I should be able to telnet to
|
|
0:37:50
|
router3's address
|
|
0:37:53
|
but this is getting dropped
|
|
0:37:56
|
if we look at the asa
|
|
0:37:58
|
it says it denied ICMP
|
|
0:38:04
|
and it denied
|
|
0:38:10
|
lets see, lets try this again
|
|
0:38:25
|
its denying ICMP from fe80
|
|
0:38:29
|
going to ffo2::1
|
|
0:38:31
|
this is the all router's multicast
|
|
0:38:35
|
or all host multicast, more specifically
|
|
0:38:37
|
what this is trying to do is, this is ICMPv6 nieghbour discovery duplicate address detection
|
|
0:38:43
|
or ICMP NDDAD
|
|
0:38:46
|
So, trying to figure out, is my address actually unique on the link
|
|
0:38:49
|
Now but we can see, for the actual transit traffic like in the telnet
|
|
0:38:53
|
its not telling why this is dropped
|
|
0:38:57
|
So I would need to know
|
|
0:38:59
|
specifically what is the ether type value
|
|
0:39:03
|
of IPv6
|
|
0:39:05
|
in order to allow this traffic through
|
|
0:39:09
|
So lets look for this, actually don't know what the value is off hand, lets say
|
|
0:39:13
|
Now IPv6 ether
|
|
0:39:15
|
type value
|
|
0:39:19
|
it says
|
|
0:39:22
|
0/8808
|
|
0:39:28
|
8808
|
|
0:39:30
|
no, 86dd
|
|
0:39:33
|
hey, this is the ether type value
|
|
0:39:35
|
Now you would be expected to memorise this stuff
|
|
0:39:38
|
because, like you can see here, anytime you really need to know it
|
|
0:39:42
|
all you need to do is just search whats the ether type value of this protocol, and you can find it
|
|
0:39:46
|
So, within the scope of the lab exam, if they were testing you on something like this
|
|
0:39:51
|
probably, something is going to be straight forward
|
|
0:39:54
|
may be they will give you, what the actual value is
|
|
0:39:57
|
So now in order to allow this, the IPv6, from the inside out
|
|
0:40:02
|
and then from the outside in
|
|
0:40:04
|
I am going to need to apply this with the
|
|
0:40:07
|
the ether type filter
|
|
0:40:14
|
So again I know what the value is now
|
|
0:40:17
|
/86dd
|
|
0:40:23
|
lets see, no logging console here
|
|
0:40:26
|
then I need an access list
|
|
0:40:33
|
that is an ether type list
|
|
0:40:36
|
So I need to permit
|
|
0:40:41
|
0/86dd
|
|
0:40:43
|
thats the specific value
|
|
0:40:46
|
and I will say
|
|
0:40:48
|
access-list or access-group
|
|
0:40:51
|
one in interface outside
|
|
0:40:55
|
and in interface inside
|
|
0:41:00
|
Now notice here since there are two different types of lists
|
|
0:41:03
|
one is for the ether types and one is for the IP
|
|
0:41:06
|
I can apply multiple list on the interface
|
|
0:41:10
|
So assuming this is the only one that we need
|
|
0:41:17
|
Lets try ping 2001
|
|
0:41:20
|
::3
|
|
0:41:34
|
lets see if the ASA says exactly what it is dropping
|
|
0:41:37
|
So lets say again logging console 7, then logging on
|
|
0:41:49
|
but its not going to log its specific flow because its non IP
|
|
0:41:56
|
So lets take a short break here
|
|
0:41:59
|
lets take about a 10 minute break, then when we come back, we are going to look at
|
|
0:42:03
|
the rest of the ether type filters, along with the
|
|
0:42:06
|
the arp spoofing filter
|
|
0:42:09
|
and then the MAC address learning filter
|
|
0:42:12
|
to prevent any type of layer 2 spoofing or any type of
|
|
0:42:15
|
layer 2 man in the middle attack
|
|
0:42:18
|
over the transparent firewall
|
