In this guide
What a firewall does
A firewall controls traffic between security zones or interfaces according to policy. Modern firewalls commonly combine packet filtering with connection tracking, NAT, application inspection, logging and other security controls.
The basic question remains simple: should this flow be allowed from this source to this destination using this protocol and port? Everything else helps the firewall make that decision or enforce additional policy.
Stateful inspection
A stateful firewall tracks connections. For TCP, it can recognise the initial connection attempt and associate subsequent packets with the established session. This means a rule allowing an outbound connection can often permit the corresponding return traffic without a separate “allow the reply” rule.
Stateful does not mean the firewall can ignore routing. The firewall still needs to receive the packet on the expected interface, select a valid route, apply policy and be able to send the response towards the correct next hop.
| Observation | Useful interpretation |
|---|---|
| SYN leaves, no SYN/ACK returns | Investigate destination, return routing, filtering and upstream loss. |
| SYN receives RST | The destination or an intermediary actively reset the connection. |
| Connection works by IP but not hostname | Investigate DNS before firewall policy. |
| ICMP works but TCP/443 fails | Do not treat this as contradictory; different protocols may have different policy. |
ACLs and security policies
An ACL is typically an ordered set of permit/deny statements. The exact processing model differs by platform, but engineers should always confirm whether the ACL is applied inbound or outbound and to which interface or logical interface.
A common conceptual rule is: allow the specific traffic required, then deny what should not cross the boundary. Be careful with broad rules such as “any to any”. They can hide a design problem and make later troubleshooting harder.
When reading a policy, record the source zone/interface, source address, destination zone/interface, destination address, service, action and any NAT or inspection profile. Logging the first packets of a deliberately tested flow can be extremely useful.
NAT and PAT
Network Address Translation changes addressing as traffic crosses a device. SNAT changes the source address, commonly so private clients can access external networks. PAT also uses transport ports so many internal sessions can share one public address.
For example, an internal client 192.168.10.25 might be translated to a public address when accessing the internet. The destination server sees the translated source rather than the original private address.
NAT is not inherently a security policy. A firewall may combine NAT with policy enforcement, but the two functions should be reasoned about separately.
Port forwarding and DNAT
Destination NAT changes the destination of an incoming flow. A common use is publishing an internal web server through a public address and TCP/443. The firewall receives traffic for the public address, applies the relevant security policy and translates the destination to the internal server.
When troubleshooting published services, test each stage: did the packet arrive on the WAN interface, did NAT match, did security policy permit it, did the firewall route it internally, did the server receive it, and can the reply return through the firewall?
Asymmetric routing
Asymmetric routing occurs when traffic takes different paths in each direction. Some routers handle this normally, but stateful firewalls can reject or drop traffic if they do not see the expected session state on the appropriate path.
Common causes include multiple firewalls, dual WAN links, dynamic routing changes, incorrect default routes and unequal Layer 3 paths. When a flow is intermittent or one direction appears healthy, compare both directions explicitly.
Troubleshooting a failed flow
- Write down the exact source IP, destination IP, protocol and port.
- Confirm the source has a route to the destination.
- Confirm the firewall receives the packet on the expected interface.
- Check which security policy and NAT rule match.
- Check whether the firewall creates a session.
- Check the egress interface and next-hop resolution.
- Verify the destination actually receives the packet.
- Inspect the return path and firewall session state.
- Use a packet capture on both sides of the firewall where possible.
A useful packet-capture pattern
If you see the packet on the firewall's ingress interface but not its egress interface, concentrate on routing, policy or NAT. If you see it leave but never see a response, investigate the destination and return path. If you see a response arrive but it is not forwarded back to the client, investigate state, policy, NAT and routing.
Key takeaways
Firewall troubleshooting becomes much simpler when routing, policy and NAT are considered as separate stages of the same packet journey. Define the flow, locate the first missing packet and work from evidence. A successful ping is useful evidence, but it does not prove that every application flow is permitted.