Troubleshooting AWS Transit Gateway & Fortinet Routing: The Case of the Missing Session

Cloud Security & Infrastructure Series by I AM TAC Engineering

Beyond the Interface: When Packet Sniffers Lie

Ever run a packet sniffer, watched the traffic hit your security appliance perfectly, but noticed that the connection state simply refuses to build? In complex public cloud fabrics, this is a classic indicator of an underlying architectural mismatch. This engineering breakdown reviews a common edge case involving AWS Transit Gateways (TGW) and FortiGate Next-Generation Firewalls (NVAs) where packet visibility did not equate to routing predictability.

Figure 1: Architectural overview of the asymmetric routing challenge between AWS TGW and the FortiGate NVA.

1. The Symptom: Missing Stateful Session Tables

During a post-deployment phase, a secondary server located inside an isolated Spoke VPC lost the ability to negotiate traffic out to the public internet. Initial diagnostics on the FortiGate unit via the command-line packet sniffer tool confirmed packet arrival:

diagnose sniffer packet any 'host 8.8.8.8' 4

The ICMP requests were visibly arriving at the FortiGate internal interface via the AWS Transit Gateway attachment. However, auditing the system's global session table returned empty results. The firewall was receiving the frame but refusing to track the state.

2. The Investigation: Flow Tracing Policy 0 Drops

To safely peer past the interface layer, we initialized Fortinet’s low-level flow tracing mechanism to catch the packet lifecycle in real time:

diagnose debug flow filter daddr 8.8.8.8
diagnose debug flow trace start 100
diagnose debug enable

The engine caught the raw packet but explicitly evaluated the drop action under Policy 0 (the implicit deny). In standard security engineering, a Policy 0 drop indicates a missing firewall policy. However, even after binding a temporary, wide-open any-any testing policy with Source NAT (SNAT) active, the traffic continued to drop instantly.

3. The Root Cause: Reverse Path Routing Conflict

Digging deeper into the debugging metrics exposed the core failure. The FortiGate’s internal state machine verifies egress topology before completing session construction. The unit's standard routing table was attempting to steer the internet-bound outbound traffic out of port2—the internal, transit-facing interface pointing back at the AWS Transit Gateway—rather than forwarding it to port1, the external WAN interface wired directly to the AWS Internet Gateway (IGW).

4. The Fix: Overriding with Policy-Based Routes (PBR)

To correct the path selection without altering the global routing properties of internal VPC traffic, we introduced a Policy-Based Route (PBR) on the FortiGate appliance. By defining an explicit forwarder that targets the specific source subnet of the Spoke VPC when heading toward 0.0.0.0/0, the PBR manually overwrote the standard routing table evaluation.

This forced the egress traffic out of the designated WAN interface, successfully triggering the state engine, completing the SNAT binding, and restoring end-to-end internet availability.

Conclusion: Designing Robust Cloud Interconnects

When implementing third-party Network Virtual Appliances (NVAs) inside highly distributed AWS Transit Gateway fabrics, traditional routing logic often breaks down due to asymmetric pathing hazards. Packet capturing alone is insufficient; engineers must actively audit the flow trace path to determine exactly which interface the security appliance intends to use.

At I AM TAC, we specialize in demystifying complex transit routing. In multi-tenant enterprise clouds, maintaining strict control over the host-level and appliance-level routing tables is a foundational requirement for any modern infrastructure architect.