Rule action: block, reject, pass

The action on a firewall rule is what PF does when the rule matches. OPNsense exposes three core actions: pass, block, and reject. They look similar in the GUI but they have very different effects on the client, the network, and the diagnostic trail. The right action for a rule depends on what you want the client to experience and what signal you want to give to an attacker.

This lesson covers what each action does at the network level, the diagnostic and security trade-offs, and the production pattern that uses each action in the right place.

Pass: the packet goes through

pass is the action that allows the packet. The packet is forwarded, state is created (for TCP/UDP/ICMP where applicable), and the connection proceeds.

For TCP: pass creates a state entry. Subsequent packets in both directions match the state and are forwarded without re-evaluation. When the connection closes, the state is removed (after a timeout).

For UDP and ICMP: pass creates a “soft” state entry. The state times out after the configured interval (60 seconds for UDP by default). The connection is inferred from the source/ destination tuple.

For everything else: pass allows the packet but does not necessarily create state. IPsec ESP, for example, passes without state because there is no reliable way to track the “connection” — ESP is connectionless at the IP layer.

Pass is the action for traffic that should be allowed. There is no production trade-off for using pass on legitimate traffic.

Block: the silent drop

block (specifically block drop in PF syntax, which is OPNsense’s default for block actions) is a silent drop. The firewall receives the packet, decides to drop it, and sends nothing back. The packet vanishes.

For TCP: the sending host’s SYN is dropped. The host retries the SYN. After several retries, the connection times out. The timeout is typically 75 seconds (the kernel’s default TCP retransmission schedule), but can be longer depending on the host’s TCP stack.

For UDP: the packet is dropped. The application typically retries; after several retries, the application gives up with an ICMP “port unreachable” or with a timeout. The application behaviour depends on the application.

For ICMP: the packet is dropped. The sending host does not get a response. Traceroute stops at the firewall (because ICMP time-exceeded is generated by routers along the path, but the firewall is not generating them for the dropped packets — see the lesson on ICMP for the production pattern).

The advantage of block: an attacker cannot tell whether the packet reached a host that is down, a host that does not have the port open, or a firewall that is dropping the packet. The attacker gets no signal.

The disadvantage of block: a legitimate user who is trying to connect gets no immediate signal either. Their application appears to hang until the timeout fires. This makes troubleshooting harder — the user sees “connection timed out” without a clue about why.

$ tcpdump -ni igb0 host 203.0.113.10

03:14:15.123456 IP 192.0.2.50.51820 > 203.0.113.10.443: Flags [S], seq 1000000000, win 65535, length 0
03:14:18.126543 IP 192.0.2.50.51820 > 203.0.113.10.443: Flags [S], seq 1000000000, win 65535, length 0
03:14:24.130112 IP 192.0.2.50.51820 > 203.0.113.10.443: Flags [S], seq 1000000000, win 65535, length 0
(no response — silent drop)

Reject: the explicit refusal

reject sends an explicit refusal back to the sender. For TCP, the firewall sends a TCP RST. For UDP, the firewall sends an ICMP “port unreachable” (type 3, code 3). For ICMP, the firewall sends an ICMP “host unreachable” or “protocol unreachable” depending on the match.

The sending host receives the refusal immediately and gives up. For TCP, the application sees “connection refused” within milliseconds instead of waiting for the SYN timeout. For UDP, the application sees “ICMP port unreachable” and gives up quickly.

The advantage of reject: the client gets immediate feedback. A user who mistypes a port or hits a closed service sees “connection refused” immediately instead of waiting 75 seconds. Troubleshooting is faster.

The disadvantage of reject: an attacker can tell that the firewall is there and that the port is being filtered. Rejecting tells the attacker “there is something at this IP that is dropping my traffic on purpose”, which is more information than block-drop provides. For perimeter defence, the silent drop is preferred because it leaks less information.

The third disadvantage: reject can be used as an attack amplification vector if the source IP is spoofed. A negligible concern in most estates but a consideration in some.

Diagnostic trade-offs

The action choice affects what shows up in the firewall log and in client-side diagnostics.

Block (drop)

• Firewall log: the dropped packet is logged if the rule has logging enabled. The log shows source, destination, protocol, and port — the same information as for any action.
• Client log: the client sees a timeout. No ICMP, no TCP RST. The application typically logs “connection timed out” after 75 seconds (TCP) or after the application’s UDP retry budget (variable, often 30-60 seconds).

Reject

• Firewall log: the rejected packet is logged if the rule has logging enabled. The log shows the same information as for block.
• Client log: the client sees an immediate refusal. For TCP, “connection refused”. For UDP, an ICMP port unreachable. The application logs the failure within milliseconds.

Pass

• Firewall log: the passed packet is logged if the rule has logging enabled. Most pass rules do not have logging enabled (it would flood the log) but rules that create state are typically logged once (the first packet) for audit purposes.
• Client log: the client sees a successful connection. No diagnostic signal from the firewall.

When to use each action

The decision tree:

The pattern: drop on the perimeter, reject internally. The exception is when the operator explicitly wants the silent treatment for internal security reasons (e.g. blocking a known-compromised internal host from reaching a service — drop to make the host’s malware wait for a timeout and possibly give up).

Summary

• Pass: the packet is allowed. State is created. The client succeeds.
• Block (drop): silent. No response. The client times out.
• Reject: explicit refusal. TCP RST or ICMP unreachable. The client gets immediate feedback.
• Production pattern: drop on the WAN, reject on internal interfaces.
• The action affects client behaviour, diagnostic signal, and information leaked to attackers.