Context
A firewall rule can be correct while the connection it should permit still fails. With AWS Network Firewall, stateful inspection needs the request and corresponding response to traverse the same firewall endpoint. An asymmetric route can therefore look like a policy problem even when the intended application rule is present.
Draw both directions of one flow
Choose a specific source, destination, protocol, and port. Record the workload subnet, Availability Zone, inspection endpoint, NAT location where applicable, transit attachments, and destination subnet or internet gateway. Then draw the response path independently.
Do not assume that the return path is the forward path reversed. Each subnet and transit route table makes its own destination-based choice. More-specific routes, propagated routes, peering, and a recently added attachment can send responses through a different boundary.
Keep the distinction between a connection's original addresses and translated addresses visible. A capture taken before NAT and a flow log after NAT may describe the same transaction using different tuples. Record where each observation was taken before concluding that traffic disappeared.
Check the inspection architecture
For a decentralized internet inspection design, review the application subnet route and the internet-gateway edge route association described in AWS's architecture guidance. Verify the endpoint belongs to the intended zone and that the firewall subnet's next hop is correct.
For centralized Transit Gateway inspection, inspect both transit route-table associations and propagation. AWS documents appliance mode on the inspection VPC attachment as part of keeping related directions on the same inspection path. Enabling it is not a substitute for correct routes on both sides.
If NAT sits before or after inspection, use the provider's matching reference architecture. Changing the order affects which source addresses the firewall sees and how the response reaches the original client. Avoid combining fragments of two deployment models without tracing a complete packet journey.
Separate routing evidence from rule evidence
Use firewall logs, VPC flow logs, relevant transit observations, and a bounded application test together. A firewall log containing only one direction suggests a path question, but absence alone can also mean logging coverage is incomplete.
Review stateless processing, forwarding into the stateful engine, stateful rule order, and default actions only after confirming which endpoint sees the traffic. A broad allow rule will not reconstruct missing connection state from a response arriving elsewhere.
Also distinguish an initial handshake failure from an idle connection that later expires. Stateful connection timeout and asymmetric routing are different hypotheses. Compare the first successful packet exchange, the quiet interval, and the eventual reset or retransmission.
An illustrative cross-zone regression
A team adds a second zone to improve availability. Outbound requests traverse that zone's firewall endpoint, but a shared return route still targets the first zone's endpoint. Short tests from the original subnet succeed while the new application replicas intermittently fail.
The correction aligns each intended flow with its supported inspection architecture and verifies return routing. The team tests each source zone independently, then rehearses endpoint or zone failure using the approved failover design. It does not describe ordinary cross-zone bypass as a resilience feature.
Quick diagnostic map
| Evidence | Hypothesis | Next check |
|---|---|---|
| Only new-zone clients fail | Zone-specific route mismatch | Forward and return endpoint selection |
| Requests logged; responses absent | Return path or logging gap | Destination route and observation coverage |
| Connection works, then fails after idle | State timeout | Keepalive and documented timeout behavior |
| Policy widening changes nothing | Traffic not reaching expected engine | Stateless forwarding and route path |
A focused operator exercise
Build a flow matrix covering every workload zone and destination class. For each row, record the expected firewall endpoint and translated tuple. Send a small, identifiable test transaction and correlate its evidence across the observation points.
In a nonproduction copy, introduce one deliberate route mismatch and confirm the runbook detects it without widening application permissions. Restore the route and repeat the same request. Capture route-table identifiers and configuration revisions so a future network change can be compared with the accepted path.
Preserve a recoverable network change
Prepare route updates with explicit rollback and independent management access. Validate application traffic, DNS, package retrieval, and monitoring after inspection changes; a business request can work while an essential operational dependency is blocked.
Keep routing and rule ownership connected in change review. The firewall team and network team need a shared definition of the inspected paths, especially when new zones, VPCs, and transit attachments are introduced.
Frequently asked questions
Can a permissive stateful rule fix asymmetric routing?
No. Correct stateful inspection still requires the supported bidirectional path. Establish route symmetry before changing the application's permission scope.
Does appliance mode configure every required route?
No. It addresses an important traffic-affinity behavior in centralized designs. Route associations, propagation, and next hops still require verification.
Continue the investigation
- Firewall Changes: Review the Full Application Flow
- Site-to-Site VPN: Investigate Connected but Unusable Tunnels
Browse the cloud, server and infrastructure guide library for related operational questions.
Explore Clouvenix Firewall & Perimeter Security to discuss implementation, validation and operational handover.