Firewall Troubleshooting
Summary
This note is a simple workflow for checking whether a firewall or filtering rule is the reason a service is unreachable. The goal is to separate firewall problems from routing, DNS, and application problems before changing rules blindly.
Why this matters
- many service issues are really filtering issues rather than general network failure
- changing firewall rules too early can hide the real cause instead of solving it
- this workflow is useful in Linux, Windows, cloud, and homelab environments
Environment / Scope
| Item | Value |
|---|---|
| Topic | firewall troubleshooting |
| Best use for this note | when a service is reachable locally but not from the expected network |
| Main focus | path, port, policy, listener |
| Safe to practise? | yes, carefully in a lab |
Key concepts
- verify the service exists before blaming the firewall
- confirm routing and basic connectivity before testing policy
- test from the right source network, because firewall rules are often source-aware
Steps / Workflow
flowchart TD A["is the service listening<br>on the expected port and interface?"] -->|no| A1["service problem, not the firewall"] A -->|yes| B["does the basic network path work?<br>address, route, gateway"] B -->|no| B1["routing problem, not filtering"] B -->|yes| C["does it work from the host itself?"] C -->|no| C1["service or bind address problem"] C -->|yes| D["filtering is the likely cause"]
1. Confirm the service is actually running
Check that the application is listening on the expected port and interface.
2. Confirm basic network path first
Before thinking about firewall rules, check:
- host has the expected IP address
- route to the host makes sense
- gateway and basic reachability work
3. Verify whether the service works locally
If the service works from the host itself but not from another system, filtering or bind-address issues become more likely.
4. Check which port and protocol the app uses
Make sure you are testing the right thing:
- TCP vs UDP
- expected port number
- expected source network
5. Check firewall policy
Ask:
- is the port allowed?
- from the correct source?
- on the correct interface or zone?
- for ingress, egress, or both?
6. Re-test after each controlled change
Do not make multiple changes at once. Test after each one so the result stays meaningful.
Commands / Examples
| Command | Purpose |
|---|---|
ip addr | confirm host addressing |
ip route | confirm route and default path |
ping <host> | test basic reachability |
curl http://localhost:<port> | test service locally over HTTP if relevant |
| app-specific service check | confirm the application is listening where expected |
Small test sequence
ip addr
ip route
ping HOST
ss -tulpn
curl http://localhost:PORTVerification
| Check | Expected result |
|---|---|
| Service exists | app is running and listening |
| Path works | host is reachable at network level |
| Policy is correct | expected traffic is allowed |
| Remote test works | service is reachable from intended source |
Pitfalls / Troubleshooting
| Problem | Likely cause | What to check |
|---|---|---|
| Service works locally but not remotely | firewall or bind-address problem | listener address, port, source policy |
| Ping works but app fails | port filtering or app issue | allowed port, service logs |
| Rule change had no effect | wrong zone, interface, or source scope | where the rule actually applies |
| Temporary test works but later disappears | non-persistent firewall change | active vs persistent rule set |
Key takeaways
- confirm the service and network path before changing firewall policy
- test the correct port, protocol, and source path
- firewall troubleshooting is much safer when changes are small and verified one by one