Concepts·LPIC-2

Firewalls, SELinux, and service reachability

Most of the time lost configuring a service on the RPM family is not spent on the service. It is spent on a firewall that never opened the port, and a security label that blocked the daemon after the firewall let the packet through. This guide establishes the starting state of both, on both families, so every later page can say which barrier it is dealing with.

Start Here Guide 2 of 29 Intermediate

PlatformsUbuntu 26.04 LTS + AlmaLinux 10.2
Block devicesone 50 GB disk
TimeAbout 15 min

Two service hosts and a client. Every service here is proven from a machine that is not running it.
Server Name	IP Address	OS	Roles	CPU	RAM	HDD
LPIC2-A01	192.168.0.78	Ubuntu 26.04 LTS	Primary service host - BIND, Apache, Samba, Postfix. Topic 204 RAID runs on loop devices; this machine has no spare disk	2 Core	4 GB	50 GB
LPIC2-B01	192.168.0.79	AlmaLinux 10.2	Second service host - nginx, NFS, DNS secondary, and the other family's spelling of each service	2 Core	4 GB	50 GB
LPIC2-C01	192.168.0.80	Ubuntu 26.04 LTS	Client - resolves, mounts and connects, so every service is proven from a machine that is not running it	2 Core	4 GB	50 GB

This guide includes

Use this before configuring any service on the RPM family. This matters because the time lost is rarely spent on the service - it goes on the firewall, and on SELinux, which does not announce itself.

finding two firewalls in opposite states, because the families do not start from the same place
meeting the second barrier, which the firewall never mentions
separating reachability from trust, from the client's side

Before you start

what-lpic-2-asks

Two firewalls, in opposite states
The families do not start from the same place.
bash Example session
```
$sudo -n ufw status 2>/dev/null | head -3; echo "--- Debian-family firewall"Status: inactive--- Debian-family firewall$sudo -n firewall-cmd --state 2>/dev/null; sudo -n firewall-cmd --get-default-zone 2>/dev/null; sudo -n firewall-cmd --list-services 2>/dev/nullrunningpubliccockpit dhcpv6-client ssh
```
Note
This asymmetry is the single biggest cause of "it works on Ubuntu and not on Rocky". The Debian host has ufw installed and inactive, so nothing is filtered. The RPM host has firewalld running with a default policy permitting three services and rejecting everything else. Install a web server on both and only one of them answers.

--list-services names SERVICES, not ports. firewalld ships definitions - http means 80/tcp, dns means 53 on both protocols - so firewall-cmd --add-service=dns is more readable and less error-prone than naming ports. --add-port=8080/tcp exists for anything without a definition.

Every change needs --permanent AND a reload, or neither. firewall-cmd --add-service=http changes the running configuration and is lost at reboot. --permanent writes the file and does NOT affect the running firewall until --reload. Doing one and not the other is how a rule works today and vanishes next week, or exists in a file and never applies.

cockpit being open by default is worth noticing - it is the web management console on 9090, permitted before anyone asked for it. Knowing what your default zone allows is where Topic 212 starts.

Expected resultStatus: inactive on the Debian host; on the RPM host running, default zone public, and services cockpit dhcpv6-client ssh.

Success conditionYou know which host will silently drop your traffic.
The second barrier, which the firewall does not tell you about
SELinux is enforcing, and it blocks things the firewall permitted.
bash Example session
```
$getenforce; echo "--- and SELinux, which blocks services the firewall let through"Enforcing--- and SELinux, which blocks services the firewall let through
```
Note
A packet that gets through the firewall can still be refused by SELinux, and the two failures look nothing alike. A blocked port times out; an SELinux denial usually produces an immediate, specific error - permission denied on a file the daemon plainly owns, or a service that starts and immediately fails.

Three rules catch every service on this path. A daemon may only listen on ports labelled for it, may only read files labelled for it, and some behaviours are gated behind booleans. Moving Apache's document root to /srv/www without relabelling produces a working web server serving 403s to everything.

ausearch -m avc -ts recent is the command that ends the argument. Denials are logged, and the log names the process, the file and the permission. restorecon -Rv fixes a wrong label, semanage port -a allows a non-standard port, and setsebool -P flips a boolean permanently.

setenforce 0 is a diagnostic, not a fix. If the problem disappears in permissive mode you have proved it is SELinux and learned nothing about which rule. Turn it back on and read the denial. A machine left permissive because someone was in a hurry is how SELinux ends up switched off everywhere.

Expected resultEnforcing.

Success conditionYou know to check labels as well as ports.
The client can reach both servers, and cannot log into them
Reachability and trust are separate questions.
bash Example session
```
$getent hosts lpic2-a01 2>&1 | tail -1; echo "exit $? - resolved by the search domain, not /etc/hosts"192.168.0.78    lpic2-a01.practicelabpro.localexit 0 - resolved by the search domain, not /etc/hosts$for h in 192.168.0.78 192.168.0.79; do ping -c1 -W2 $h >/dev/null 2>&1 && echo "$h reachable" || echo "$h UNREACHABLE"; done192.168.0.78 reachable192.168.0.79 reachable$ssh -o BatchMode=yes -o ConnectTimeout=5 192.168.0.78 'echo reached; hostname' 2>&1 | tail -2; echo "--- key auth between lab hosts is NOT configured, and that is deliberate"Host key verification failed.--- key auth between lab hosts is NOT configured, and that is deliberate
```
Note
Resolution and reachability both work, and that is the foundation. Every service guide on this path assumes the client can find and reach the server; establishing it once here means a later failure is the service, not the network.

The name resolves through the DNS search domain, not /etc/hosts - lpic2-a01 becomes lpic2-a01.practicelabpro.local before the query is sent. Worth knowing, because the DNS guide later replaces that resolution path with one of its own.

SSH between the lab hosts fails, deliberately. Host key verification failed means the client has never seen that server's key and BatchMode=yes forbids the interactive prompt. Nothing is broken - there is simply no trust configured between lab machines, which is the correct default. A guide needing key trust sets it up and says so.

And it is a useful failure to recognise. Host key verification failed on a machine you connect to daily means the key CHANGED - a rebuilt server, or something worth investigating. ssh-keygen -R removes the old entry, and doing that reflexively without asking why is how a real man-in-the-middle goes unnoticed.

Expected resultThe name resolving through the search domain, both servers reachable, and Host key verification failed when the client tries to SSH.

Success conditionYou know what the client can and cannot do before any service exists.

Troubleshooting

A service is configured correctly and a client still cannot reach it.

Why: There are three barriers, not one: the service's bind address, the firewall, and on the RPM family SELinux - which announces nothing.

Fix:Check in that order. ss -ltnp for the bind address, ufw status or firewall-cmd --list-all for the firewall, then getenforce and a permissive-mode test.
The same service works on the Debian host and is refused on the RPM one.

Why: The families do not start from the same place - ufw is inactive by default while firewalld is running, and SELinux is enforcing.

Fix:Never assume the two hosts are equivalent. ufw status reporting inactive and firewall-cmd --list-all reporting a zone with few services is the normal starting difference.
A host answers ping and refuses ssh, and the network is blamed.

Why: Reachability and trust are separate questions - ICMP proves the route, not that you may log in.

Fix:Separate them: ping for the path, nc -vz <host> 22 for the port, then the authentication error itself. Each answers a different layer.

Official sources

← All LPIC-2 guides

Firewalls, SELinux, and service reachability

This guide includes

Before you start

Two firewalls, in opposite states

The second barrier, which the firewall does not tell you about

The client can reach both servers, and cannot log into them

Troubleshooting

Official sources