Firewalls and connection state

A firewall permits or drops traffic according to policy. Rules may consider direction, interface, IP protocol, source and destination addresses, ports, and connection state. Reading a firewall decision means checking each of those dimensions against the packet in question.

The most important concept is state. A stateful firewall tracks connections. It can allow reply packets for a connection that began from the trusted side while rejecting unrelated new inbound traffic. That’s how your laptop browses the web freely while accepting no unsolicited connections: outbound requests create state, and replies match it. This tracking is separate from TCP state maintained by the endpoints — the firewall keeps its own table.

Look at a real policy

On Ubuntu and similar systems, ufw shows a readable policy:

sudo ufw status verbose

Status: active
Default: deny (incoming), allow (outgoing)

To         Action      From
--         ------      ----
22/tcp     ALLOW IN    Anywhere

Read it as: everything outgoing is allowed, everything incoming is denied, except new connections to TCP port 22. Replies to outgoing connections are permitted by connection tracking, which is why the browsing works without any explicit “allow” rule for it.

On macOS the application firewall reports its state differently:

/usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate
# Firewall is enabled. (State = 1)

Firewalls stack

Firewalls exist at several boundaries: on the host, home router, cloud network, or service edge. A packet from the Internet to a cloud VM might cross a provider security group, a subnet ACL, and the VM’s own ufw — three separate policies. One allowed layer does not override a deny at another layer. The packet gets through only if every layer says yes.

This is why “but I opened the port!” so often fails: you opened it in one place, and a different layer is still dropping the traffic.

Diagnose without weakening anything

Do not diagnose by disabling every firewall. Turning protection off to see if a problem disappears leaves you exposed and teaches you almost nothing about which rule mattered.

Instead: identify the exact flow — source, destination, protocol, port, direction. Inspect the relevant rule and log at each layer; most firewalls can log dropped packets, and one log line names the offender precisely. Make the smallest authorized change, such as one allow rule for one port from one source. Then retest the flow and confirm the log shows it passing.