Ansible Firewall Rules and Safe Ordering
Configuring a firewall remotely has one hazard that nothing else in this path shares: get the order wrong and you disconnect yourself from the machine you are configuring, mid-play, with no way back in. The rules go in first and the default policy goes in last. This does it in that order and proves the connection survived.
Automating Administration Guide 33 of 45 Intermediate
- OSUbuntu 26.04 LTS
- ansible-core2.20.1
- Python3.14.4
- TimeAbout 15 min
This lab is Ubuntu 26.04 and EX294 is a RHEL exam. Ubuntu uses ufw and EX294 expects firewalld. The concepts map directly: community.general.ufw here is ansible.posix.firewalld there; ufw's rule: allow is firewalld's service:/port: with state: enabled; ufw applies immediately where firewalld distinguishes runtime from permanent with immediate: true. The ordering hazard is identical on both.
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| ANS-CTL01 | 192.168.0.36 | Ubuntu 26.04 LTS | Ansible Control Node | 2 Core | 3 GB | 50 GB |
| ANS-B01 | 192.168.0.38 | Ubuntu 26.04 LTS | Managed Node (group: db) | 2 Core | 3 GB | 50 GB |
This guide includes
Use this before configuring a firewall on a host you are connected to. This matters because task order is the entire safety story - allow SSH before enabling anything, or the play ends with you on the outside.
- finding which firewall tool this distribution actually uses
- allowing SSH first, which is the whole point of the ordering
- reading the rules back once it is active
- confirming the connection still works, which is the only real test
Before you start
- A control node configured as shown in the first step.
- The session enables ufw on
ans-b01and resets it at the end. If the SSH rule were omitted, the host would become unreachable.
-
The configuration this guide assumes
-
The tool this distribution uses
-
Allow SSH first
-
What the rules look like
-
The connection still works