Firewall Troubleshooting

Hands-On Lab

 

Photo of Michael Christian

Michael Christian

Course Development Director in Content

Length

00:30:00

Difficulty

Intermediate

In this learning activity, there is a fairly simple, but broken, firewall configuration. The firewall on Server1 (10.0.1.10) should be configured to permit web requests from Client1 (10.0.1.11). You will need to determine why the firewall isn't working as intended, and resolve the issue.

What are Hands-On Labs?

Hands-On Labs are scenario-based learning environments where learners can practice without consequences. Don't compromise a system or waste money on expensive downloads. Practice real-world skills without the real-world risk, no assembly required.

Firewall Troubleshooting

The Scenario

A business unit is complaining that their host (10.0.1.11) is unable to access the web API on 10.0.1.10. They are asserting that a system administrator has already added the firewall rule necessary for these hosts to be able to communicate.

We'll need to assess the current firewall configuration, and make the changes necessary that will permit port 80 requests from 10.0.1.11 to 10.0.1.10, while still preserving the generic rule that blocks 10.0.1.0/24 traffic.

Getting Logged In

Use the credentials provided in the hands-on lab overview page, and pay attention to the shell prompts in this guide. They'll indicate which machine is running which command.

Verify That the Issue Exists

Prior to beginning the troubleshooting, we should verify that the issue actually exists.

We'll attempt a curl command to 10.0.1.10:

cloud_user@Client1]$ curl -I 10.0.1.10

The Connection refused message we get tells us that there is in fact a problem.

Resolve the Problem by Creating a New Zone

Let's log into the server now, and become root (with su -) so we can start on fixing the problem. First, is anything even listening on port 80? Let's check:

[root@host]# ss -lntp | grep :80

The output of this command tells us that httpd is in fact listening on 80. To be sure, we can get the headers:

[root@host]# curl -I localhost

We'll get a response, so we can move on and start looking at the firewall. Run this command:

[root@host]# systemctl status firewalld

The output tells us that we're using firewalld, and that we can use the firewall-cmd --list-all command to see where everything is set as far as firewalling goes. It will show traffic being blocked from the 10.0.1.0/24 subnet, regardless of the line after that says to allow traffic from 10.0.1.11. That second rule isn't doing anything.

We can resolve this whole issue by creating a new zone (and reloading firewalld so that the new zone is recognized):

[root@$host]# firewall-cmd --permanent --new-zone=api
[root@$host]# firewall-cmd --reload

Then we can add the http service to it:

[root@$host]# firewall-cmd --permanent --zone=api --add-service=http

Now we can designate 10.0.1.11 as a source for the zone, and reload firewalld again to implement all of our changes:

[root@$host]# firewall-cmd --permanent --zone=api --add-source=10.0.1.11
[root@$host]# firewall-cmd --reload

Verify That the Problem Is Resolved

Back on Client1, run:

cloud_user@Client1]$ curl -I 10.0.1.10

Conclusion

That last curl command showed us that we've fixed the firewall problem. We created a zone, added a service to it and designated a place where that traffic should be coming from. It all works. Congratulations!