As previously stated,
firewall issues are the most common issue you'll troubleshoot as an IT
professional, but just because it's common doesn't mean it's easy.
Let's examine the issues that firewalls present to TCP. Everybody already
knows that a firewall's main role is asset protection,
but an incorrectly configured firewall can also prevent legitimate traffic uses.
The most common issue you'll encounter within a
firewall are misconfigured addresses.
This includes both the source and destination addresses.
This also includes misconfigured source and destination ports.
Another common issue is incorrect firewall interface direction in zone
configuration, along with incorrect firewall rule orders.
As we can recall from our prior modules,
these source and destination addresses and ports can change rather
quickly depending on the directional flow of traffic.
Let's drop to a diagram to gain a better understanding of traffic flow.
In this diagram,
we have a PC assigned the address of 192.168.1.1, utilizing
the port of 55110, and a web server with the IP address of
10.10.10.10 and a port of 80.
These devices are separated by a firewall.
Let's say the PC with the address of 1.1 wanted to access the website at the
web server of 10.10.10.10. When the traffic is initiated,
the source address will be 192.168.1.1, and the source port will be 55110.
The destination address will be 10.10.10.10, and
the destination port will be 80.
But when the web server responds to the traffic, the source
address will be 10.10.10.10, and the source port will be 80,
while the destination address will be 192.168.1.1, and the
destination port will be 55110.
Let's drop to a quick video where we can actually troubleshoot an
IP address and port issue within a firewall.
In this video, Jason, the network administrator of Wired Brain Coffee,
would like to allow ICMP from the source network of
172.25.1.0/24 to the network of 192.168.1.0/24, but block
port 443 destination traffic. First,
let's check and see if ICMP is working. Great.
ICMP is working as planned.
Now, let's check to see if we can still access the web server.
Huh, well, that's odd.
We can still access the website.
Let's review our firewall rules to see why.
Okay, it appears that rule 100 is correct as it allows all ICMP.
Let's look at rule 200.
Oh, I'll bet that's our issue.
As we can see, our source address is correct,
but the destination address and port are both wrong.
I'll bet it was the junior network admins fault.
Those guys are always messing stuff up.
Let's see if we can correct this discrepancy and see if that makes a difference.
Okay,
our changes have been made. Let's see if ICMP is still
working. Great. ICMP is still working.
At least we have that going for us.
Now, let's see if the website is still available to us.
Awesome.
The site is now blocked and no longer available to us.
Mission accomplished. Firewalls operate in two modes, zone‑based firewalls,
which places the configured interface into a zone.
When an interface is placed into a zone, it blocks all
connection to other interfaces by default,
and the only way to permit traffic to that zone is to allow each zone to
communicate with each other through configured firewall rules.
The second mode is directional‑based rules.
Directional‑based rules operate on three directions.
The first direction is the in direction.
The second direction is the direction of out, and out is for
traffic that is leaving the interface.
The third direction is a roundabout.
I'm just kidding. I hate those things.
The third direction,
which not all vendors have, is the direction of local, and local traffic is
specifically traffic that is destined for the firewall itself.
A good example of this would be a site‑to‑site VPN as it enters the router
or the firewall itself where the traffic terminates.
Let's drop to a quick diagram to help cement these ideas.
In this diagram, we have two computers,
one with the IP address of 192.168.1.1/24.
We'll call this Zone A. And the other computer with the IP
address of 172.25.1.1/24, we'll call this Zone B.
Each of these machines are connected to the same
firewall and are in different zones, so thus, they cannot communicate.
To resolve this issue, each zone will need a firewall rule applied to its zone.
This rule must have cohesiveness between each other,
otherwise the traffic will only flow one way,
which is the same as it not working.
For example, in Zone A, we'll apply a firewall rule called Allow B.
If we examine this rule,
we can see the source IP is 172.25.1.1 and the destination address is
192.168.1.1. So the allow rule would only allow the PC of 172.25.1.1 to
communicate with the PC of 192.168.1.1.
Now within Zone B, we'll apply a new rule called Allow A.
we examine this rule, we can see the source PC is 192.168.1.1,
and the destination address is 172.25.1.1.
There is now parity between these two zones, so communication can now occur.
But let's drop to a quick video to see zone‑based firewalls in action and
explore this complex feature more in depth. In this video,
Jason, the network administrator,
would like to allow the Zone A network with the address scope
of 172.25.1.0/24 to communicate with the Zone B network with
the address of 192.168.1.0/24.
Let's see if Jason can ping from the 172.25.1.0/24 subnet to the destination
computer of 192.168.1.20. It appears as though ICMP is failing.
Let's take a quick look at the firewall rules associated with these two zones.
Okay, as we can see,
we have two firewall rules, ZONEA_To_ZONEB and ZONEB_To_ZONEA.
Remember, when working with firewall zone rules,
we require parity between each zone, otherwise the traffic will drop, by default.
Okay, so it looks as though our rules are correct.
Let's look at the zones to see if we can spot any glaring issues.
Ah, would you look at that? ZONEB is missing its reverse rule.
Let's apply it and see if that makes any difference.
Great. ICMP is now working.
So the root cause issue here was the zone‑based firewall
rule was missing its reverse firewall rule.
So, by default, it dropped all the traffic.
In this diagram,
we have a single firewall with three interfaces.
ETH1 is connected to the internet.
ETH2 is connected to a PC with the IP address of 192.168.1.1, and ETH3 is
connected to the PC with an IP address of 172.25.1.1.
If we wanted to block the PC of 172.25.1.1 from
communicating with the PC of 192.168.1.1, we'd have two
places where we could block the traffic.
The best place would be blocking the traffic from the in direction
of ETH3, as it could drop the packet earlier and save on system
processing. The second place would be the out direction of ETH2.
Now, this does sound strange,
but the easiest way to think of this is it is coming from the outside
in. Our final direction is the local direction.
The local direction is anything that is destined for the router.
Let's say we wanted to allow our firewall to be pinged from the internet,
which, as a side note, is a terrible idea.
So, if we wanted to allow ICMP to the router's ETH1 interface,
we'd allow ICMP to the direction of local.
Let's take a moment to drop to a quick video to see firewall directional issues
in action to help cement the ideas presented. In this video,
Jason would like to allow ICMP to his local gateway,
but block SSH. Jason would like to also block ICMP to the
192.168.1.0/24 network from the source network of 172.25.1.0/24.
Let's check if we can ping the gateway. As expected,
it's working. Now, let's see if we can SSH our gateway. We
can. Man, the individual that set this firewall up really
missed the quality control marks.
Before we dive into this issue, though,
let's see if we can ping a PC on the 192.168.1.0/24 network.
Again, as expected, we can.
Let's take a look at the interfaces to see how the firewall rules are applied.
Okay,
we have two rules applied to the interface of eth0. Right off the bat, I
don't see any rules applied to the local interface,
so it would be impossible to block SSH without that rule.
Let's change the BLOCK_SSH rule to the correct interface and
see if that changes our luck. With our rules changed, let's see
if we can still ping the gateway.
Awesome.
We still can.
Okay, now for the big test.
Let's see if we can SSH the gateway. Awesome! SSH has failed.
Our network is just a tiny bit more secure.
Now, let's investigate our ICMP issue to the
192.168.1.0/24 network by reviewing eth0 again.
Okay,
I see a rule called PLURALSIGHT applied to the out interface, and
I'll bet this rule was actually supposed to be applied to the
inbound direction of this interface.
Let's make the change and see what happens.
Okay, our rule is now applied.
Let's see if ICMP is still working.
Finally, ICMP is no longer operational.
Awesome.
All of our lingering network issues in this video are now solved.
Crack open the energy drink of your choice and congratulate yourself.
Firewall rules are processed in a sequential order, starting with rule 1,
and will continue processing rules until a match is found or
until the final default action is triggered,
which is generally a drop traffic rule.
Let's drop to another diagram where we can view a
couple of firewall rule structures.
In this diagram, we are presented with two firewall rules.
Actually, if you look closely, the rules are almost identical to each other,
except the actions are different.
And this is really important, though,
because rule 1 denies all traffic, and rule 2 permits all traffic.
So, depending on the situation,
you could have a real issue on your hands if you wanted
all traffic to flow between the 192.168.1.0/24 network and
the 172.25. 1.0/24 network.
It'll never arrive as rule 1 would process first,
and the traffic would match on it.
On the other hand, if you swap rules 1 and 2,
you'd have no network segmentation, which is fine if you don't
like security. Let's drop back to another video,
though, to see this exact scenario in action.
Jason,
the network administrator at Wired Brain Coffee, has identified
one of his switches have a Telnet enabled on it.
Jason knows that this is an insecure protocol and decides to implement a
firewall rule to drop Telnet sessions from the source network of
172.25.1.0/24 to the destination address of 192.168.1.0/24.
With Jason fairly confident that his rule's been implemented,
let's test it with PuTTY, though, to see if the connection is in fact blocked.
It appears as though Jason has not configured something correctly.
Let's dissect our firewall rules to see where it went wrong.
Okay, within this rule set,
there are three rules, rule 100, rule 200, and rule 300.
It appears that rule 100 and rule 200 are identical,
except they're deciding actions.
It appears that someone accidentally swapped their rule order.
Let's correct the rule order and see if that makes a difference.
Alright, our rules are now in place.
Let's see if Telnet is still operational.
Perfect. Telnet is now blocked.
Let's see if we can still access the web page of the destination switch.
Awesome.
It appears we can still pass web traffic.
I do want to point out, though,
that this exact syntax that you're seeing may vary from vendor to
vendor when working within their firewalls.
For these demos,
I'm using a Ubiquiti EdgeRouter, but this does provide you with a
good generalization of what is actually transpiring.
Also, if you're curious about the amazing Ubiquiti product line,
I highly encourage you to look at the video, Introduction to Ubiquiti Routing and Switching, here on Pluralsight.