Firewalls and Allowed Ports
Summary
This note explains what a firewall is actually doing in day-to-day networking work and how allowed ports fit into that picture. The goal is to understand why reachability can fail even when routing and DNS are correct.
Why this matters
- many services fail because traffic is being filtered rather than because the network path is broken
- Linux, Windows, cloud, and homelab work all depend on understanding what is allowed and what is blocked
- security and networking meet very directly at the firewall layer
Environment / Scope
| Item | Value |
|---|---|
| Topic | firewalls and port filtering |
| Best use for this note | understanding why traffic is allowed or denied |
| Main focus | ingress, egress, service exposure |
| Safe to practise? | yes, in a lab or test VM |
Key concepts
- Firewall - a control point that allows, denies, or limits traffic based on rules
- Allowed port - a port that the firewall policy permits traffic to reach
- Ingress - traffic coming into a host or network
- Egress - traffic leaving a host or network
- Service exposure - whether a service is reachable from the networks you intend
Mental model
A firewall does not make a service exist.
It only affects whether traffic is allowed to reach that service.
Think of the path like this:
name resolution -> routing -> port reachability -> application responseEven if:
- DNS works
- routing works
- the host is online
the application can still be unreachable if the firewall denies that traffic.
Everyday examples
| Scenario | What the firewall question is |
|---|---|
| SSH to a Linux server fails | is TCP 22 allowed from your source network? |
| Website is reachable internally but not externally | is TCP 80 or 443 exposed and allowed on the right interface? |
| DNS queries fail to an external resolver | is DNS traffic allowed out, usually on port 53? |
| App works on localhost but not from another host | is the app bound correctly and is the firewall allowing that port? |
Common misunderstandings
| Misunderstanding | Better explanation |
|---|---|
| ”The service is installed, so it should be reachable” | the service can still be blocked by filtering or wrong exposure |
| ”Open port means secure enough” | reachable does not mean safely configured |
| ”Firewall problem means the network is broken” | the network path may be fine while policy blocks traffic intentionally |
| ”If ping works, the port must also work” | ICMP reachability does not guarantee TCP or UDP service reachability |
Verification
| Check | Expected result |
|---|---|
ip addr and ip route | host is on the expected network and can route correctly |
| service check | service is actually running and bound to the right address |
| firewall policy check | expected port is allowed from the expected source |
| application test | client can reach the service on the intended port |
Pitfalls / Troubleshooting
| Problem | Likely cause | What to check |
|---|---|---|
| Service works locally but not remotely | firewall or bind-address issue | listening address, allowed port, source path |
| Port appears open in one network but not another | different policy by source network | source IP, VLAN, zone, interface |
| DNS and ping work but app still fails | filtering or application issue | allowed port, app logs, listener |
| Change worked once and then failed later | temporary rule or wrong config scope | persistent firewall config, applied rules |
Key takeaways
- firewalls control reachability, not whether the service exists
- port filtering is one of the first things to check after basic routing works
- application troubleshooting is much easier once you separate path problems from policy problems