Using Firewalls in Linux (iptables and firewalld)

When changing a remote Linux firewall, preserve management access before adding restrictions. Keep the current SSH session open and verify an independent recovery path, such as the provider console, before changing a default policy.

Identify the rule manager

Finding iptables, nftables, firewalld, and UFW names on a machine does not mean you should configure all of them independently. Determine which tool owns the existing setup. These commands inspect state; an unavailable command or inactive service alone does not prove that no filtering exists.

systemctl is-active firewalld
sudo firewall-cmd --state
sudo firewall-cmd --get-active-zones
sudo iptables --version
sudo nft list ruleset

An nf_tables marker in the iptables version can indicate the nftables-backed interface. Do not assume that firewalld always operates through legacy iptables. Editing rules behind an active manager can create conflicts or changes that disappear during its next reload.

Try one HTTPS allowance with firewalld

This example assumes firewalld already manages the host. Do not start a second manager on a UFW-managed machine just to follow it. Replace the example public zone with the zone actually handling the relevant interface or source. Also confirm that the web service listens on port 443.

sudo firewall-cmd --zone=public --list-all
sudo firewall-cmd --permanent --zone=public --list-all
sudo firewall-cmd --info-service=https
sudo firewall-cmd --zone=public --query-service=https
sudo ss -lntp

Record the starting state. If HTTPS is already allowed, do not later remove that pre-existing allowance as part of this exercise. For a service that is not already allowed, use a temporary runtime addition:

sudo firewall-cmd --zone=public --add-service=https --timeout=10m
sudo firewall-cmd --zone=public --query-service=https

The allowance expires after ten minutes and is not a permanent configuration change. Open a new HTTPS connection from another machine; a request made locally on the server does not exercise the external path. Check IPv4 and IPv6 separately where both are in use.

Inspect runtime and permanent state separately

If the test works and the service should remain available, add it to permanent configuration:

sudo firewall-cmd --permanent --zone=public --add-service=https
sudo firewall-cmd --permanent --zone=public --query-service=https

This does not extend the timed runtime allowance. Before using --reload to load permanent configuration, compare both complete configurations: other runtime-only changes can disappear. Ensure that the permanent configuration preserves management access. Treat the reload as a controlled maintenance action, then test new SSH and HTTPS connections again.

To abandon the change, remove only the allowance introduced by this exercise. If you added it permanently as well, remove that addition too. Do not remove an allowance that existed before the test.

sudo firewall-cmd --zone=public --remove-service=https
sudo firewall-cmd --permanent --zone=public --remove-service=https

Inspecting iptables is not flushing it

sudo iptables -S
sudo ip6tables -S
sudo iptables -L INPUT -n -v --line-numbers
sudo iptables-save

These commands help inspect existing state. Flushing all rules with iptables -F or setting a blanket INPUT DROP policy is not a safe generic setup procedure. Changes that ignore established connections, loopback, the actual SSH port, or IPv6 may lock out the administrator. Persistence also depends on the distribution and rule manager; there is no universal rules-file path.

If HTTPS still fails, inspect the cloud security group, routing, application bind address, and container network. Adding one service does not prove that all other traffic is blocked. Consult the firewall-cmd reference for command details.