Routing, state, access policy, NAT, and the return path
Troubleshooting a Security Gateway requires a coherent view of forwarding and enforcement. Identify the interfaces through which the traffic should enter and leave, the applicable routing information, the next-hop adjacency, and any address translation. Then examine the relevant access-policy decision and other enabled protections. A route permits a forwarding choice; it does not by itself authorize traffic through the security policy. An allow decision likewise does not guarantee that a downstream server exists, listens on the requested port, or can send replies through the expected path.
Read a packet as a tuple and a direction. Source and destination addresses, source and destination ports, and protocol identify the flow more usefully than a vague service name. A reply normally reverses the endpoints and ports, subject to translation and encapsulation. If a filter assumes that both directions use the server port as the destination, it may miss replies. With NAT, note the addresses before and after translation at the points where they are observed. Do not interpret a translated source as evidence that the original client generated a new connection from that address.
Stateful inspection makes path consistency important. If the first packet and its response traverse different enforcement points without the necessary shared state or supported design, a reply can be treated differently from the initial flow. Investigate routing and state evidence rather than responding by broadly weakening inspection. A successful new connection does not prove that an older connection retained state after a failover or a disruptive change. Similarly, packet retransmissions show missing acknowledgment from the sender's perspective, not a uniquely identified firewall drop.
Anti-spoofing uses interface topology and expected source networks to help detect traffic arriving from an inappropriate direction. A legitimate routing or topology change can expose stale assumptions. Verify the actual source, ingress interface, routes, and configured topology before changing enforcement. Avoid disabling a protection globally simply because a packet is dropped. Investigate the specific rule, layer, object, network definition, or translation condition that applies. A broadly permissive test rule can conceal the cause and introduce unrelated access if used without control.
Check basic connectivity without confusing layers. ARP concerns local IPv4 neighbor resolution, not an application login. DNS maps a name to an address but does not establish service availability at that address. A completed TCP handshake does not demonstrate successful TLS validation. MTU problems can allow small packets while disrupting larger transfers. Use packet size, direction, ICMP feedback, and endpoint observations to narrow the issue. A disciplined answer explains which observation supports a hypothesis, which alternatives remain, and the next bounded test needed to distinguish them.