In this video, we're going to discuss
firewall issues and how to troubleshoot network issues
involving incorrect firewall setting
and block services, ports or addresses.
First, let's talk about the purpose of a firewall.
Remember, firewalls are network security devices
that monitor and filter incoming
and outgoing network traffic
based upon established rule sets.
Essentially, firewalls act as an inspection point
and barrier between a private internal network
and the public internet
or other private internal networks
if you're using screen subnets.
Now, firewalls can exist
as either host-based firewalls
or network-based firewalls.
A host-based firewall is a piece of software
that runs on an individual computer
or device that's connected to your network
and performs the functions of a firewall
to protect that one single device.
For example, if you're running a Windows client
or server, you can utilize
the built-in Windows Defender Firewall
to (indistinct) host-based
two-way network traffic filtering and inspection,
as well as blocking unauthorized network traffic
from flowing into or out of your device.
A network-based firewall is a network security device
that's deployed in line with the network traffic flow,
just before the border or gateway router,
in order to monitor and filter incoming
and outgoing network traffic based upon
your established rule sets.
In general, regardless of whether the issue resides
on a host-based firewall
or a network-based firewall,
the network connectivity issues experience
will be caused by one of three different situations.
First, access to protected resources
from unprotected networks isn't working.
Second, access to unprotected resources
from protected networks isn't working.
Or third, access to the firewall
and its configurations isn't working.
Basically, the problems can be broken down
into either traffic is not going through the firewall
or traffic is not going to the firewall.
And in either case, it's not working properly.
So to troubleshoot these issues,
you should use your seven-step troubleshooting method
and understand the OSI model
to troubleshoot each layer, from layer one physical,
all the way up until you identify the issues.
Now, for example,
is the firewall properly cabled into the network
at the right position?
If so, does the link lights on the network interface card
show up that the link is established
between the router and the firewall?
If it does, layer one is probably not your issue.
Next, we go to layer two
and we determine if the router and firewall
are communicating using ARP and their MAC addresses.
If they are, we're going to move up to layer three
and determine if the firewall has a valid IP address,
subnet mask and default gateway, and that way,
it can communicate properly on the network.
Once we've done all that,
we can now inspect the firewall itself for issues.
Usually, when traffic isn't flowing to or through
the firewall, the issue is going to be related
to a misconfigured rule set
as part of your access control list, or ACL.
Now, the access control list is simply a collection
of permit and deny conditions, which we call rules,
and they're going to provide security
by blocking unauthorized users
and allowing authorized users
to access specific resources.
To inspect the firewall rules
on a network-based firewall, you're going to use
the command show access-lists
to display the contents
of the current access control list
on a Cisco device, as an example.
Each device is going to have a different command,
but for Cisco, it's show access-lists.
Now, let's say, for example, you're trying
to figure out why the network clients
in the internet filter group are not able
to access Google, Facebook or Dion Training's websites.
You might log into your firewall or router
and check the current ACL restrictions.
In this example, you can see there's a deny statement
in line 20 for the internet filter group,
and it states that all TCP network traffic,
any IP over any port, should be blocked by this rule.
Basically, any clients that have been added
to the internet filter group will be unable to connect
to any website because they're using TCP
to connect over port 80 or port 443
when they're trying to go to a website.
Similarly, if we have a client in the 101 group
and it's having timing issues, we could look at our ACL
and see what the root cause is.
Looking at line 10 within the 101 access control list,
states to deny any UDP traffic from any IP
to any IP that uses NTP, which is port 123,
and used for the network time protocol.
Problem here is that NTP operates using UDP traffic.
So this single line in the ACL will break
all NTP functionality for any devices
assigned to group 101.
So when you're writing or editing an ACL rule,
always be careful to think through
what you're intending to do with that rule.
First, you need to ensure there's no typos in your rules
because this will cause a lot of issues
that will result in traffic being blocked
when it really shouldn't be.
Second, verify the protocol
and port numbers that you're referencing
in your rule and ensure they're correct.
Do you really want to block TCP or UDP?
Make that decision.
Do you want to block a specific port or all ports?
All of this is important to consider.
Third, verify the source and destination addresses
are referenced by the rule.
Did you include the correct IP address or network IP
and the correct subnet mask?
A simple typo like 0.0.255.255,
instead of 0.0.0.255, is going to cost
65,636 IPs to be blocked,
instead of the 256 IPs you were intending to block.
Fourth, verify the order of the rules
is being applied correctly.
Remember, ACLs are always processed in order,
from the top of the list to the bottom of the list.
Your most specific rules need to be first,
and your most generic rules need to be at the end.
Let's consider this example
and see if we can determine why a network client
can't connect to Google servers
at 8.8.8.8 from within
the DionTraining group of clients.
Now, first, we're going to pull up the access control list
and look for the DionTraining group rules.
Under these rules, we look under
the rules pertaining to this issue.
In this case, we can't reach the server
located at 8.8.8.8.
So if we look at rule 20,
we're going to see there's a permit rule
for all TCP traffic going from any IP
going to the server at 8.8.8.8
if it's over port 80, which is used for web traffic.
So based on this rule alone,
the traffic should be able to reach the server.
Now, let's see what other rules we have
for servers at 8.8.8.8.
Now, we have one rule at line 40, and it again says
to permit traffic over TCP from any IP
to the server at 8.8.8.8 using port 25.
So we're going to allow email traffic over SMTP
to be sent from any of our clients
to the server at 8.8.8.8.
Again, this seems fine and we shouldn't have an issue.
Now, remember, ACL rules are implied in order,
and once it finds a matching rule,
it's going to stop as it goes down the access list.
So look at it from the beginning.
The first rule is line 10.
It says to deny any TCP traffic
from any IP address to any IP address,
and this applies to all ports
because none were specified.
So if I'm trying to visit the server
at 8.8.8.8, will rule 10 match this packet?
Is it going to go from any IP to any IP using TCP?
Yes. Yes, it is.
Therefore, the traffic is going to be blocked,
and it will never get to rule 20
or rule 40 that specifically allow traffic
to this server at 8.8.8.8
over port 80 or port 25.
So instead, we can change the order of this ACL,
and we're going to put the more specific lines,
like 20 and 40, at the top.
So we're going to make them 10 and 20, respectfully.
Then we're going to take the current line 10
and move it to the bottom of our list.
So to make this easier to see,
I'm creating a new group here
called DionTrainingNew
at the bottom of this ACL.
Here you can see the difference in the order
from DionTraining group to the DionTrainingNew group.
So notice I now have our most specific ACLs
listed at 10 and 20, and a more generic one
at line 30, which is for the any IP to any IP,
but for a specific port.
Then I have my most generic rules at the bottom,
lines 40 and 50.
This is going to block all traffic for UDP
and all traffic for TCP.
Remember, when you're troubleshooting issues
with firewalls, always check your ACLs
to ensure they're in the right sequence
and that you haven't mistyped anything in them,
because this can lead to a lot of connectivity issues
and the wrong traffic being blocked
or being allowed through your firewall.
Similarly, when you're dealing with software firewalls,
like the Windows Defender Firewall,
it's important to look not just at the IP addresses
and ports that are being blocked,
but also, you need to look at the applications
and services themself.
Under your Windows Defender Firewall,
you're going to see inbound rules
and outbound rules listed.
Under each type, you're going to see the name
of the application or service
and whether it's allowed or denied.
Then you're going to see if any specific IP addresses
or ports are being allowed or blocked
with those applications and services.
Just like in the earlier examples
with network firewalls, a simple typo here
can cause a lot of connectivity problems
for your clients and your servers.
So always double-check your ACLs
to ensure they're blocking and allowing
exactly what you want them to do,
and in the right order.