Troubleshooting pfSense Firewall Rule Drops: Fixing High Latency, Packet Loss, and 502 Errors

Understanding the Error

When managing enterprise edge networks, pfSense acts as the critical gatekeeper. Misconfigurations in a pfSense firewall rule rarely manifest as simple 'connection refused' errors. Instead, they produce cascading network degradation symptoms such as pfSense high latency, severe pfSense packet loss, and application-layer anomalies like the dreaded pfSense 502 Bad Gateway error when routing traffic to internal reverse proxies (HAProxy, Nginx, or Traefik).

The root cause usually lies within how the FreeBSD Packet Filter (pf) engine handles stateful tracking, asymmetric routing, and Maximum Transmission Unit (MTU) path discovery. Because pfSense evaluates rules on a top-down, first-match-wins basis, a poorly placed rule or a failure to account for TCP state tracking will silently blackhole traffic. This forces applications into endless retransmission loops, spiking latency and eventually timing out the reverse proxy, resulting in a 502.

Diagnosing the Root Causes

Before making arbitrary changes, you must isolate whether the issue is a state mismatch, a fragmentation drop, or an overzealous block rule.

1. The 502 Bad Gateway & MTU Blackholes

A 502 Bad Gateway from a proxy sitting behind pfSense almost always indicates that the proxy cannot establish a reliable connection to the backend server, or the external client's payload is being dropped. If ICMP 'Fragmentation Needed' packets are blocked by a strict firewall rule, Path MTU Discovery (PMTUD) fails. TLS handshakes (which are often large) get silently dropped. The proxy waits for the handshake to complete, times out, and serves a 502 Bad Gateway.

2. pfSense Packet Loss and High Latency

Packet loss and high latency are frequently tied to asymmetric routing. If a packet leaves the network via WAN1 but returns via WAN2, or if internal VLAN routing creates a loop, pfSense will see a TCP ACK without seeing the initial TCP SYN. Because pfSense is a stateful firewall, it strictly enforces TCP state transitions. Out-of-state packets are immediately dropped. The client attempts to retransmit, increasing perceived latency until the connection eventually fails, mimicking generic packet loss.

Step 1: Real-Time Diagnostic Tracing

The most effective way to identify the culprit is dropping into the pfSense shell (via SSH or the WebGUI console) and directly querying the pf engine.

First, monitor the live firewall log interface. pfSense logs blocked packets to a virtual interface called pflog0:

tcpdump -ni pflog0 -e -vvv host 10.0.0.50

Replace 10.0.0.50 with the IP of your backend proxy or client experiencing the issue.

Look for the rule number in the output (e.g., rule 45/0(match): block in on igb1). Once you have the rule number, you can map it to your actual pfSense rule set:

pfctl -vvs rules | grep '@45'

This explicitly tells you which firewall rule is dropping the packets.

Step 2: Resolving TCP State & Asymmetric Routing Drops

If your packet captures show dropped TCP ACK or TCP FIN packets (often logged as TCP:A or TCP:FA in the firewall logs) but TCP SYN packets are passing, you are dealing with a state tracking issue.

The Fix:

1. Navigate to System > Advanced > Firewall & NAT.
2. Locate the State Timeout or Firewall Optimization Options.
3. If dealing with asymmetric routing that cannot be fixed at the routing layer, you may need to check the box for Bypass firewall rules for traffic on the same interface.
4. Alternatively, edit the specific firewall rule passing the traffic, go to Advanced Options, and change the State Type from keep state to sloppy state. This relaxes the strict TCP sequence number checking, resolving the packet loss and latency spikes.

Step 3: Fixing the 502 Bad Gateway via MSS Clamping

If your tcpdump reveals that large packets are being dropped, or you see ICMP unreachable messages being blocked, you must address MTU and MSS clamping.

The Fix:

1. Ensure that your firewall rules explicitly allow ICMP type 3 (Destination Unreachable) and type 4 (Source Quench) to allow Path MTU Discovery to function.
2. If PMTUD is broken upstream (often the case with PPPoE WAN connections or certain IPsec/WireGuard tunnels), enable MSS Clamping.
3. Navigate to Interfaces > [Your WAN/VPN Interface].
4. Set the MSS field to 1350 or 1400. This forces the TCP handshake to negotiate a smaller Maximum Segment Size, preventing packets from exceeding the MTU limit, thereby stopping the fragmentation drops and the resulting 502 Bad Gateway proxy errors.

Step 4: Rule Optimization and Reordering

Finally, ensure your pfSense firewall rules are logically ordered. A common mistake causing sudden high latency is placing DNS or external Alias lookups in rules that are evaluated for every single packet.

• Move highly specific Allow rules to the top of the list.
• Place broadly defined Block or Reject rules at the bottom.
• Ensure that rules governing high-traffic internal VLANs are processed quickly to prevent CPU bottlenecking and micro-burst packet loss.
• Apply changes and safely flush the state table (Diagnostics > States > Reset States) during a maintenance window to ensure all traffic flows through the newly ordered rule set.