Network Ports and Firewalls

Introduction

A backend can be healthy but unreachable because it listens only on loopback or a firewall drops traffic. Reachability depends on the process listener, address binding, route, and each firewall boundary.

This guide traces a connection through those layers and shows how to expose only the ports a service needs. It covers inbound and outbound policy, a Linux UFW example, and common failures such as blocked health checks or missing return routes.

Where firewalls fit

Host firewalls filter traffic on the server; network firewalls, security groups, and ACLs filter at a boundary. Stateful rules track connections; stateless rules may need return-path rules. Traffic also needs a route and listener.

flowchart LR
    C[Client] --> N[Network firewall]
    N --> L[Load balancer]
    L --> H[Host firewall]
    H --> S[Service listening on TCP 8080]
    S -->|response| H
    H --> L
    L --> C
    S -->|outbound dependency call| E[External service]

Inbound rules govern arriving traffic; outbound rules govern traffic leaving. A web tier might accept public HTTPS at a load balancer and allow application traffic only from that balancer. Egress may need DNS, telemetry, updates, or specific APIs. Many cloud environments allow outbound traffic by default, so inspect the effective policy.

Proxies and load balancers do different work: firewalls permit or block network flows, proxies relay application connections, and load balancers select backends. Application controls do not replace network segmentation. See load balancing and cloud security.

Stateful and Stateless Firewall Rules

A stateful firewall records metadata for an allowed flow and can permit its response packets when they match that state. For example, after allowing a client connection to a service on TCP port 443, it can recognize the reply as part of that connection without a separate broad inbound rule for the client’s temporary source port.

A stateless filter evaluates each packet against its rules independently. It needs policy for both directions: the request to the server port and the response back to the client’s address and ephemeral port range. A missing return rule can look like a connection timeout even when the inbound rule is present. Keep return-path rules scoped to the expected peers, protocol, and port ranges; avoid opening all ephemeral traffic to every source.

State tracking is a useful policy mechanism, not a substitute for explicit access decisions. Confirm which device is stateful or stateless on the path, and inspect its effective rules and flow logs when a connection behaves differently in each direction.

When to use ports and firewall rules

Use explicit listener and firewall configuration when a service crosses a trust boundary, such as an API exposed publicly or an admin endpoint. A local process may need only loopback. Identify a port’s owner and clients before opening it. See the backend engineering roadmap for related topics.

Safe implementation example

On Linux with UFW, allow HTTPS publicly, SSH from an administrator address, and deny other inbound traffic. Replace the documentation-only address below. Confirm SSH access before enabling the firewall.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from 203.0.113.10/32 to any port 22 proto tcp
sudo ufw allow 443/tcp
sudo ufw status verbose

For a private service, bind to its private interface or container network and allow its port only from the load balancer’s identity or subnet. Keep debug ports such as 9229 private. Store rules in reviewed infrastructure configuration and test the policy in staging.

Production failures and mitigations

Clients time out despite an open rule. The process may be stopped, bound to loopback, or blocked at another boundary. Check the listener, then inspect effective cloud and host rules before adding exceptions.

A subnet change breaks deployment. Rules tied to old addresses can strand a service. Prefer stable security-group references and review routes with firewall policy.

The API cannot reach a dependency. Egress restrictions, DNS, or a missing return route can break calls while inbound checks stay green. Document required destinations and alert on connection and DNS errors.

Backends fail health checks. The check may use a different port or source range. Allow the documented health-check path, verify the binding, and monitor health status with host logs. Silent drops often appear as timeouts.

Firewall trade-offs

Choose the narrowest working policy and verify both directions.

Observability checklist

• Record listener state at deploy time; alert when sockets disappear.
• Retain rule changes and flow logs with timestamps and source/destination addresses.
• Track timeouts, refusals, load balancer health, DNS, and dependency errors separately.
• Test from the client network; a local request does not prove external reachability.
• Include protocol and port in incident notes and correlate with application logs.

Security notes and common pitfalls

Expose only needed ports. Restrict administration to a VPN or management network and use encrypted protocols. Review IPv4 and IPv6 separately, and treat container port publishing as an exposure decision. A port scan shows reachability from one vantage point; it does not prove which application is behind the port.

Quick Recap Checklist

• Confirm the listener, interface, and protocol.
• Identify network and host firewall boundaries.
• Allow only required inbound sources and ports.
• Check egress, DNS, routes, and return traffic.
• Verify load balancer health-check access.
• Review IPv4, IPv6, containers, and admin paths.

Interview Questions

Further Reading

• Load Balancing — route traffic across backends and manage health checks.
• Cloud Security — apply network controls and identity boundaries in cloud environments.
• HTTP and HTTPS Protocol — understand the application traffic commonly exposed through firewall rules.
• Incident Response — coordinate investigation and recovery when reachability failures affect users.
• IANA Service Name and Transport Protocol Port Number Registry lists registered service names and port numbers by transport protocol.
• Ubuntu Server firewall documentation explains UFW rules and host firewall configuration.

Conclusion

When a connection fails, check the listener, binding, route, and firewall boundaries. Keep public entry points small and restrict backend access.