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
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