Transit Gateway Stateful Inspection: Explain the Forward and Return Path

Trace one private VPC-to-VPC connection through a centralized inspection VPC, separate route selection from firewall session evidence, and preserve missing AZ and...

Primary sources checked 2026-10-09

Start with the connection, then explain both directions

Before changing appliance mode, establish which route table governs each arrival at Transit Gateway, which inspection endpoint each direction reaches, and what evidence connects those decisions to the same connection. A forward path through a firewall says nothing by itself about the return path. An enabled attachment setting also cannot repair a more-specific route that bypasses inspection.

This guide helps a network engineer produce a paired path decision record for one private IPv4 TCP connection between two VPCs through one Transit Gateway and a dedicated inspection VPC using AWS Network Firewall. The useful output is a dated explanation with explicit unresolved fields, ready for the network, security and application owners to challenge. It is not permission to change a route or weaken a firewall rule.

The example, resource aliases, route entries and observation references are fictional. The companion exercise evaluates declared records offline. It makes no AWS requests, forwards no packets, predicts no hash result and tests no firewall policy. Even a favorable result means only MODEL_REVIEW_ONLY. Internet gateways, NAT, peering, VPN, Direct Connect, multiple Transit Gateways, IPv6, TLS inspection and third-party appliances require different evidence and are excluded from this exercise.

Pin the source, destination and inspection boundary

Our fictional application opens TCP from 10.10.1.10:49152 in App VPC to 10.20.2.20:5432 in Data VPC. App runs in symbolic AZ-A, Data in AZ-B. These are stable location aliases for the exercise, not real account-specific Availability Zone names. The inspection VPC has attachment subnets and firewall endpoints in both zones. Its endpoint aliases are FW-A and FW-B. There is no address translation in the selected path.

Record the exact source process as well as its address. A service name can represent several tasks, retries or connection pools. The response under review reverses this connection's address and port pairs; another connection to the same database does not prove this one's return behavior. Retain a bounded time window and distinguish an existing session from a newly opened session after a change. If translation, proxying or pooling makes the tuple relationship uncertain, stop using this simple model and document the additional correlation layer.

For an actual investigation, the collector needs approved read access to configuration, permitted connection metadata and the relevant application and firewall records. Detailed routing and identity data can reveal internal relationships without containing payloads. Keep exact identifiers in an access-controlled evidence store and use aliases in a wider review. This guide grants no packet-capture authority, logging changes or unrestricted query budget.

The AWS centralized inspection reference distinguishes inspection attachment subnets from firewall subnets and routes each stage accordingly. Our example follows that separation. A route to Transit Gateway in an application subnet is only the first stage; the inspection VPC's local subnet routing must still deliver traffic to the selected endpoint and back toward Transit Gateway.

Separate association, propagation and the winning route

Use three different worksheet fields. Association identifies the Transit Gateway route table used for traffic arriving from an attachment. Propagation identifies which attachment routes are installed in a table. The winning route identifies the next attachment for this destination. A propagated App prefix in the inspection table does not establish which table App uses when it sends a request.

AWS documents one associated route table per attachment and propagation into one or more tables. Route selection first considers the most specific matching destination; an equal-prefix static route takes precedence over a propagated one. See Transit Gateway routing. The exercise implements only IPv4 longest-prefix comparison and equal-prefix static versus VPC-propagated entries. It rejects unsupported kinds and contradictory equal-priority entries rather than inventing a general AWS route engine.

In the stipulated baseline, APP-ATT and DATA-ATT associate with SPOKE-RT. That table sends both workload prefixes to INSPECT-ATT. INSPECT-ATT associates with INSPECT-RT, whose workload-prefix routes point to APP-ATT and DATA-ATT. App and Data prefix propagation into INSPECT-RT is explicitly recorded. Direct workload propagation into SPOKE-RT would be a different candidate configuration and needs a new winning-route calculation.

Preserve every applicable more-specific entry, active state and route origin. An architecture drawing with one default arrow can conceal a host route installed during troubleshooting. A proposed inspection route does not dominate a more-specific bypass merely because it is static. If the export omitted part of the table, record incomplete coverage. Do not conclude that the intended route wins by searching only for its presence.

Treat AZ selection as a separate piece of evidence

AWS's VPC attachment guidance explains source-zone attachment availability and appliance-mode behavior. Appliance mode preserves an inspection attachment zone for a flow. For the documented different-zone case, flow hashing selects a zone; it does not promise that the operator can choose the source zone. Current guidance also distinguishes propagation-dependent AZ awareness from fallback hashing. Do not infer an exact selected endpoint from an enabled toggle.

For our cross-zone baseline, the stipulated selected inspection attachment ENI is INSPECT-ENI-A in AZ-A in both directions. We choose this as supplied evidence, not a hash calculation. The corresponding inspection ingress subnet routes to FW-A. The reverse record must identify the same inspection attachment ENI, zone and endpoint under this no-translation, single-attachment contract. A missing value stays UNKNOWN, even when the configured topology looks symmetric.

Cross-account reviews should retain stable AZ IDs instead of comparing account-local letters. AWS's shared Transit Gateway guidance explains that account mappings can differ. The exercise uses aliases inside one fictional account, so it deliberately does not test cross-account zone equivalence or Resource Access Manager permissions.

Enabling appliance mode on an existing attachment needs an authorized change plan because existing flow placement can be affected. Preserve pre-change configuration, active-session expectations and the observation strategy. Do not promise that all established sessions survive, that failures automatically resume elsewhere, or that symmetric declared routes prove failure-domain resilience. Those are separate workload and service checks.

Walk the complete fictional route chain

Read the request from App to Data and the response from Data to App independently. The lists below stipulate all destination-applicable candidates at each stage, including the second Transit Gateway lookup after inspection. They are not complete route-table exports. Both lists are configuration reasoning, not captured packet traces.

Request record, F-01

APP-SUBNET-RT selects the Data prefix route to TGW-ONE for destination 10.20.2.20. APP-ATT has an enabled attachment subnet in App's AZ-A.
Arrival through APP-ATT uses its associated SPOKE-RT. The matching 10.20.0.0/16 route selects INSPECT-ATT, not DATA-ATT.
The declared flow placement selects INSPECT-ENI-A in AZ-A. INSPECT-INGRESS-A selects a route to FW-A for the Data prefix.
FW-A is the stipulated endpoint; the security owner separately declares both directions forwarded to stateful processing under policy revision POLICY-7. Policy acceptance and an actual allowed session remain untested.
FIREWALL-SUBNET-A selects TGW-ONE for the Data prefix. Arrival through INSPECT-ATT uses INSPECT-RT, whose Data route selects DATA-ATT.
The destination attachment subnet route delivers the Data address within Data VPC. The application result is NOT EXECUTED.

Response record, R-01

DATA-SUBNET-RT selects the App prefix route to TGW-ONE for destination 10.10.1.10. DATA-ATT has an enabled attachment subnet in Data's AZ-B.
Arrival through DATA-ATT uses SPOKE-RT. Its 10.10.0.0/16 route selects INSPECT-ATT, not APP-ATT.
The supplied reverse placement is also INSPECT-ENI-A in AZ-A. INSPECT-INGRESS-A selects FW-A for the App prefix.
The endpoint and declared stateful-processing scope match F-01. The reverse tuple is 10.20.2.20:5432 to 10.10.1.10:49152, protocol TCP.
FIREWALL-SUBNET-A selects TGW-ONE for the App prefix. INSPECT-RT then selects APP-ATT for that destination.
The App attachment subnet route delivers the App address within App VPC. A record about this delivery is still not evidence that the client accepted a database response.

AWS Network Firewall requires the related request and response to reach the same endpoint. Its asymmetric-routing guidance also warns that stateless processing can send directions differently to the stateful engine. Keep endpoint routing and policy-stage forwarding as separate gates. A matching endpoint identity cannot establish that both directions received the intended stateful inspection.

Fictional request and response each visit the same TGW-ONE twice. The workload attachment uses SPOKE-RT toward supplied INSPECT-ENI-A in AZ-A and FW-A. Firewall subnet routing returns to the same gateway through INSPECT-ATT and INSPECT-RT toward the destination. Endpoint and stateful-processing declarations are separate; no traffic or application result was observed.

Solid arrows describe stipulated candidate packet directions. Dashed annotations identify attachment association, not propagation. Both tracks use one TGW-ONE, the supplied INSPECT-ENI-A/AZ-A placement and FW-A. POLICY-7 forward-to-stateful is a separate declaration. Session and application results remain NOT EXECUTED; MODEL_REVIEW_ONLY grants no change authority.

F-01 follows App VPC through the first TGW-ONE lookup, supplied inspection placement and FW-A, then returns to the same gateway for the INSPECT-RT lookup toward Data VPC.

F-01 is a stipulated request path, not a packet capture. The two gateway symbols are visits to the same TGW-ONE. Endpoint placement, stateful processing and destination delivery remain supplied declarations; no session or application check was executed.

R-01 reverses the tuple from Data VPC through SPOKE-RT, the same supplied inspection placement and FW-A, then revisits TGW-ONE through INSPECT-RT toward App VPC.

R-01 must be reviewed independently of F-01. The same endpoint and declared policy stage do not prove a live allowed session. Solid arrows mean candidate direction and dashed annotations mean association. MODEL_REVIEW_ONLY authorizes no route or firewall change.

Challenge the path before considering a change

Case B adds an active 10.10.1.10/32 route from SPOKE-RT directly to APP-ATT. It is more specific than the App /16 inspection route. The request still reaches FW-A; the response now bypasses inspection. Appliance mode remains enabled. The exercise returns HOLD with a return inspection-route finding. This is a routing contradiction, not a reason to broaden a firewall allow rule.

Case C retains the route chain but declares FW-B for the response. The endpoint mismatch holds the pair. Case D retains FW-A but declares reverse stateless processing as pass rather than forward-to-stateful. That also holds the record. The cases distinguish where the inconsistency lives; they do not reproduce dropped packets or determine which error a real client would display.

Case E removes the inspection placement reference. The output is HOLD for missing evidence, not a conclusion that AWS selected the wrong zone. Case F declares an enabled source-zone attachment missing. The declared route alone cannot establish the workload's path. Case G supplies an equal-priority duplicate prefix with a conflicting attachment. The bounded selector returns ambiguity rather than picking whichever row appears last.

This synthetic selection comparison uses the union of supplied candidates for the same route owner and revision. A /32 filed only with the request still affects the return lookup. Distinct workload subnet owners remain separate. Selection arrows are not observed packets or automatic fixes. A bypass, conflicting shared record or missing required evidence means HOLD; the baseline is MODEL_REVIEW_ONLY.

Under SPOKE-RT and CFG-17, the return App /32 wins over its /16 and reaches APP-ATT without FW-A. Enabled appliance mode cannot override route precedence. Missing placement holds, and omitted export coverage remains unknown.

Only declared routing consistency is compared. Supplied candidates are reconciled by owner and revision across both directions; conflicting records hold. Unknown placement does not imply FW-B. Neither the favorable baseline nor HOLD is runtime proof or change authorization.

Retain the original packet beside each mutation. If an investigator changes a route export, endpoint alias and observation window simultaneously, the resulting explanation cannot isolate which premise changed. A successful retry after a modification is useful new evidence, but it does not retroactively prove the original failure cause. Name alternative explanations such as an application timeout, a denied rule, stale connection state, a missing destination route or incomplete logging.

Combine observations without claiming a packet trace

Configuration evidence answers what a declared routing arrangement should select under stated assumptions. Transit Gateway records, firewall records and application outcomes answer different observation questions. Preserve their collection windows, query definitions, field availability and coverage rather than merging them into one green check.

The Transit Gateway flow-log reference defines attachment, paired-attachment, address, port, protocol, ENI, zone and direction fields. It also describes unavailable values, approximate metadata, aggregation timestamps and skipped records. A correlation must allow those limitations. An absent reverse record in an incomplete interval does not establish that no response existed, and a flow record does not establish a specific application transaction succeeded.

Ask the firewall owner which approved record establishes endpoint identity, policy revision and the relevant session or inspection behavior. Ask the application owner which harmless operation establishes the expected response and which connection carried it. Keep a separate observation disposition for each owner. In this manuscript every such result remains NOT EXECUTED; the fixture's evidence aliases are supplied strings without underlying logs.

New collection has operating consequences. Approve retention, access and query scope before enabling it. Logging can incur ingestion, storage and query charges; this guide includes no rate estimate. Never collect database payloads or credentials to fill a routing worksheet. If only restricted evidence can resolve a claim, have its owner attest to the narrowly defined fact and retain the protected source reference in the permitted location.

Compare designs only after fixing the requirement

The chosen design centralizes Network Firewall endpoints in an inspection VPC. It suits this exercise because the routing responsibilities are visible at two Transit Gateway lookups and two inspection subnet stages. That visibility adds several configuration relationships to keep consistent. Whether it is appropriate for a real workload depends on the inspection policy, organizational ownership, availability requirements and accepted operating burden.

A decentralized design gives each workload its own assessed inspection arrangement. It can change ownership and failure boundaries, but this guide's route lists would no longer describe it. A direct workload-to-workload path may satisfy connectivity when centralized inspection is genuinely not required; a network engineer cannot remove a mandated inspection boundary merely because a direct path is simpler. Security ownership decides the requirement before cost or convenience changes the route.

Current AWS documentation also describes managed Network Firewall network-function attachments. That is a distinct alternative to the explicit inspection VPC used here, not an absent capability. The Transit Gateway service reference documents its managed arrangement and static routing boundary. Evaluate its current support and ownership separately rather than relabelling INSPECT-ATT in this worksheet and assuming identical subnet evidence.

Third-party appliances behind Gateway Load Balancer add target health, endpoint, encapsulation and vendor session-state responsibilities. Multiple Transit Gateways add separate flow-state choices. The present fixture rejects those scopes instead of pretending that identical endpoint aliases validate them. A useful comparison can end with a new investigation boundary and named evidence owners, not a universal recommended architecture.

Fill a decision record with inspectable references

Use these labeled records rather than a dense code block. The blank worksheet retains every field from the filled example. Replace illustrative values only in an approved evidence store. UNKNOWN is a valid unresolved value and prevents a favorable model result for required fields.

Record and owner: PAIR-17, network owner N, security owner S, application owner A; fictional.
Scope and time: One account, symbolic Region R, TGW-ONE, no NAT, IPv4 TCP; stipulated window T1 to T2.
Forward connection: 10.10.1.10:49152 to 10.20.2.20:5432; App AZ-A to Data AZ-B.
Return connection: 10.20.2.20:5432 to 10.10.1.10:49152; same bounded connection.
Attachments and associations: APP-ATT and DATA-ATT use SPOKE-RT; INSPECT-ATT uses INSPECT-RT; configuration CFG-17.
Propagation and winning routes: App/Data prefixes propagated into INSPECT-RT; both spoke destinations select INSPECT-ATT; both post-inspection destinations select their workload attachment.
Local subnet stages: Both workload subnets select TGW-ONE; inspection ingress selects FW-A; firewall subnet selects TGW-ONE; destination delivery is stipulated.
Placement and appliance mode: Enabled on INSPECT-ATT; both supplied placements INSPECT-ENI-A, AZ-A, FW-A; placement references PLACE-F and PLACE-R.
Policy and controls: POLICY-7 declares both directions forward-to-stateful; network controls declared reviewed under CTRL-17; no real policy evaluation.
Observation and coverage: All configuration inputs STIPULATED; firewall session and application operation NOT EXECUTED; no live completeness claim.
Disposition and authority: MODEL_REVIEW_ONLY for the baseline; no change authorization. Case B holds return inspection selection.
Next check and expiry: N obtains approved forward/return evidence; S reviews policy stages; A owns harmless application check. Reopen on any relevant configuration or flow-identity change.

Record and owner: Record alias; network, security and application owners; collector authority.
Scope and time: Account/Region aliases, Transit Gateway, supported protocol/address family, translation exclusions and bounded window.
Forward connection: Source process/address/port, destination/address/port, protocol, workload subnets and stable zones.
Return connection: Related response tuple and correlation reference; unresolved translation or pooling.
Attachments and associations: Exact ingress and inspection attachment aliases, associated tables and dated revision.
Propagation and winning routes: Propagation sources, complete applicable entries, selected prefix/origin/target and competing routes in both lookups.
Local subnet stages: Workload egress, inspection ingress, firewall subnet egress and destination-delivery route references for each direction.
Placement and appliance mode: Configured setting, enabled attachment zones, selected inspection ENI/zone/endpoint and supplied evidence per direction.
Policy and controls: Policy revision, both processing-stage dispositions, security-group/NACL/host-control review references.
Observation and coverage: Observed, inferred, stipulated or UNKNOWN per claim; queries, windows, gaps and separate application/session result.
Disposition and authority: Supported narrow conclusion or HOLD reasons; independently approved action reference, otherwise none.
Next check and expiry: Missing evidence, owner, safe next read, stop condition and configuration/identity triggers requiring renewed review.

Use the offline exercise to challenge declared evidence

The companion folder contains a dependency-free evaluator, fictional baseline and negative tests. Run its Node test file locally. No credentials, account IDs, endpoint URLs or network access are needed. It checks a pinned route-record contract, tuple reversal, selected inspection identities and required declarations. It cannot establish that the supplied configuration is complete, current or authentic.

Each packet declares one common configuration revision and destination-applicable route subsets. Before selecting either path, the evaluator reconciles overlapping entries belonging to the same route owner, revision, prefix and origin. Conflicting targets or states hold even when one row does not match that direction's destination. Selection then uses all supplied candidates for that owner and revision, so a known more-specific or higher-priority route cannot disappear because it was placed in the opposite subset. The fixed topology derives shared SPOKE-RT and INSPECT-RT owners, inspection ingress and firewall subnet owners from AZ-A/B, and separate App/Data workload subnet owners. It rejects unsupported owner premises instead of accepting a renamed table that hides a contradiction. Different subnet owners may legitimately have different entries. Rows omitted from every supplied subset still cannot establish export completeness; that remains an independently reviewed premise.

Read the tests before modifying the baseline. Expected outcomes are separately stipulated in test assertions. A favorable baseline must remain non-authorizing and explicitly lack runtime proof. Mutations exercise more-specific bypass, blackhole, unsupported route kind, ambiguous equal-priority target, missing evidence, endpoint mismatch, incorrect reverse port and omitted stateful forwarding. These failures are meaningful even when appliance mode remains enabled.

Do not use the fixture output as an AWS validation report. It does not reproduce routing convergence, TCP state, firewall rule matching, availability transitions, packet fragmentation, throughput or latency. A fabricated evidence reference passes a presence check as easily as a genuine one; provenance must be reviewed by the authorized owner. Keep that limitation beside the result rather than burying it in an appendix.

Download the synthetic paired-path source package (ZIP). It contains only README.md, path.mjs, packets.mjs and path.test.mjs. Extract all four files into one directory and use Node.js 22 or later. From that directory run:

node --test path.test.mjs

The 75 offline tests exercise declared-record consistency, including shared-owner candidates supplied with the opposite direction. They make no AWS requests and cannot authenticate evidence, establish export completeness, prove a firewall session or authorize a change.

Close the explanation and keep change authority separate

Accept the path record only when the two directions, all route stages, attachment placement and policy-stage assumptions are explicit and independently reviewed. Missing observations can leave the record useful but inconclusive. Do not convert a configuration-only explanation into a claim that a production transaction was inspected successfully.

If an authorized change follows, define the exact route or setting revision, blast radius, observation window, stop owner and restoration plan before implementation. Recheck both directions with the same scoped operation and new connection evidence. A restored route table does not resurrect a lost session or undo a database side effect. The application owner must account for failed or retried work separately.

Retain the old record, the proposed change and the post-change readback rather than overwriting the failure. Stop on an unexpected destination, an unapproved bypass, exposed metadata or an observation gap that prevents the required conclusion. Route rollback itself is an owned change, not an action authorized by this guide.

Bring one unresolved field to the next network/security review: the source attachment's associated table, the actual winning return route, the selected inspection endpoint or the stateful-processing evidence. The egress investigation playbook addresses a different next question when a known path needs financial attribution. Here the completed artifact is a paired routing explanation with an honest evidence boundary.