Skip to main content
This architecture describes how Suricata-based Intrusion Prevention System (IPS) and TLS man-in-the-middle (MITM) decryption inspect east-west traffic. East-west traffic is traffic between workloads attached to different spoke gateways, as distinct from north-south traffic leaving the network. It explains why east-west inspection depends on symmetric routing between a spoke’s gateway pair, and how traffic flows through the inspection point once that dependency is satisfied.
East-west Suricata IPS and TLS MITM inspection is in Preview in Controller 10.1. The symmetric routing this design depends on (see AZ Affinity and Symmetric Routing Architecture ) is generally available (GA) in Controller 10.1. Only the east-west L7 inspection layer described on this page is Preview.

​
Overview

East-west traffic between spoke gateways has no NAT step, unlike egress traffic, where NAT naturally pins a flow’s return path to the gateway that handled the outbound leg. Stateful inspection (Suricata IPS and TLS MITM decryption) requires both directions of a flow to reach the same gateway instance. Without a mechanism that pins forward and return traffic to a shared gateway pair, nothing guarantees that a request and its response are ever inspected together. This architecture explains that dependency and the traffic path through the inspection point once symmetric routing supplies it. Use this architecture when you are planning IPS or TLS MITM coverage for traffic between spokes (inter-VPC/VNet, not internet-bound). You need to understand what has to be true of your routing topology before that coverage is reliable. Prior to this architecture, DCF’s own documented constraints stated the limitation this page addresses: rules using Layer 7 (WebGroups, and by extension IPS and TLS MITM) did not support asymmetric traffic. East-west traffic, which has no NAT step to force symmetry, was therefore limited to Layer 4 rules. See DCF Constraints and the Deep Packet Inspection row group (Suricata IDS (Egress only), Suricata IPS (Egress Only)) in Distributed Cloud Firewall Supported Capabilities . Symmetric routing is what lifts that limitation for east-west traffic between spokes that have it enabled. The rest of this page explains how.

​
Architecture Diagram

East-west traffic flow between two spokes through Transit, where the same spoke gateway pair carries both the request and the response so Suricata IPS and TLS MITM inspection sees the complete flow.
East-west traffic flow without symmetric routing, where the request and the response reach different members of a spoke gateway's HA pair, so neither gateway instance sees a complete bidirectional flow to inspect.
Contrast with north-south: an egress or ingress flow is naturally pinned to one gateway by NAT, so the diagram above does not apply there. SeeIntrusion Prevention System (IPS)for the north-south configuration pattern, which this architecture does not repeat.

​
Scope and Prerequisites

East-west IPS/MITM inspection has a structural prerequisite: it only functions where the routing design that provides gateway-pair symmetry is in place and applicable.
  • Symmetric routing must be enabled on both spokes in the flow. A flow between Workload A and Workload B is only reliably inspected if the spoke fronting Workload A and the spoke fronting Workload B both have symmetric routing enabled. AZ Affinity is a separate, optional setting covered by the same architecture below. It is not required for east-west inspection. See AZ Affinity and Symmetric Routing Architecture .
  • Symmetric routing is supported for AWS only in Controller 10.1. The routing mechanism this architecture depends on is supported for AWS only in this release. Azure, OCI, and GCP are not currently covered.
  • East-west inspection is not supported with FireNet-attached spokes.
  • DCF must already be enabled, with an IPS Profile and, if TLS visibility is required, TLS Decryption configured, exactly as for north-south traffic. See Intrusion Prevention System (IPS) .

​
Design Principles

  • Symmetric routing is a prerequisite, not a feature of IPS/MITM itself. Suricata IPS and TLS MITM decryption are stateful: they track a connection across both directions to evaluate signatures and to complete the decrypt/re-encrypt cycle. East-west inspection does not add new logic to the inspection engine; it depends entirely on the surrounding routing design pinning both directions of a flow to the same gateway pair. See AZ Affinity and Symmetric Routing Architecture .
  • Inspection runs on the spoke gateway, not the transit. East-west L7 inspection features apply at the spoke gateway that a workload’s subnet routes through. As a result, the routing property that matters is which spoke gateway instance a flow’s forward and return legs resolve to, not which transit gateway instance carries the traffic in between. IPS specifically cannot run on a transit gateway at all in Controller 10.1; it is restricted to spoke gateways by design.
  • The inspection engine is direction-agnostic. DCF, Suricata IPS, and TLS MITM decryption do not have a separate east-west code path or a separate policy model. The same IPS Profile and the same TLS Decryption/Intrusion Analysis policy fields that apply to north-south traffic apply to east-west traffic; what differs is only whether the surrounding routing guarantees the engine sees a complete flow.
  • The design is cloud-provider independent, but this release has a cloud-specific dependency. The east-west inspection architecture itself does not assume a specific cloud service provider (CSP). In Controller 10.1, however, its only routing dependency (symmetric routing) is supported for AWS only. See Scope and Prerequisites.
  • This architecture adds no new enablement surface. It does not introduce a CoPilot workflow of its own. See Enabling East-West Inspection.

​
Components

​
Traffic Flows

​
East-West Flow (Inspected)

1

Workload A sends a request

A workload attached to one spoke VPC/VNet sends traffic to a workload attached to a different spoke VPC/VNet. There is no NAT step on this path: the flow retains its original source and destination addresses as it enters the fabric.
2

The outbound leg reaches Spoke Gateway 1

Symmetric routing directs the outbound leg of the flow to a specific gateway instance in Workload A’s spoke gateway pair (see AZ Affinity and Symmetric Routing Architecture for how that pinning is established).
3

DCF policy evaluates the flow

DCF policy on Spoke Gateway 1 determines whether the flow is selected for IPS inspection, TLS MITM decryption, or both, exactly as it would for a north-south flow. SeeIntrusion Prevention System (IPS)for the policy fields involved.
4

Traffic crosses the fabric to Spoke Gateway 2

The flow continues over ActiveMesh to the gateway pair fronting Workload B’s spoke.
5

Workload B receives the request and responds

On each side, the return leg of the flow must traverse the same gateway that handled the outbound leg: Spoke Gateway 2 on Workload B’s side, Spoke Gateway 1 on Workload A’s side. Only then does the connection state tracked by IPS and TLS MITM decryption remain valid across both directions.

​
North-South Flow (Contrast)

A north-south flow (egress to the internet, or ingress from it) is naturally pinned to a single gateway by the NAT step that egress and ingress traffic already require. As a result, the same-gateway-pair dependency described above does not need a separate mechanism on that path. North-south IPS and TLS MITM configuration is already documented in Intrusion Prevention System (IPS) and is out of scope for this architecture.
A conceptually related but architecturally distinct problem (establishing routing symmetry for stateful inspection without relying on NAT) also appears in Aviatrix’s Transparent Inspection for AWS Transit Gateway design (bump-in-the-wire insertion into an existing TGW network). That design makes the same general point as this architecture: symmetry for stateful L7 inspection has to be a property the routing configuration establishes up front, not something the inspection engine reconstructs per packet. That source material is specific to TGW insertion. Its source-IP-preservation mechanics and its route-table-level implementation do not apply to this east-west overlay design, and are not repeated here. It is cited only for the shared architectural principle.

​
East-West Flow Without Symmetric Routing (Fail-Safe Behavior)

If a DCF policy rule includes an IPS or TLS MITM action and targets east-west traffic, but the spoke gateway pair handling that traffic does not have symmetric routing enabled, the policy engine does not attempt partial or best-effort inspection. Instead:
  • The IPS or TLS MITM action on that rule is automatically converted to a Deny action for the affected east-west traffic.
  • A notification tagged DCF-l7-non-symmetric-routing is raised in CoPilot, so the change is visible rather than failing with no signal at all.
No API error is returned and no step blocks rule creation in the UI. The notification is the only signal, so watch for it if you are rolling out symmetric routing and east-west L7 policy together. This fail-safe means the traffic is blocked rather than passed through uninspected, and it also means enabling symmetric routing later can change previously-Denied east-west traffic to actively inspected traffic without any change to the DCF policy itself.

​
Failover Behavior

Symmetric routing preserves the same-gateway-pair guarantee across a spoke gateway failover. If one instance in a spoke’s gateway pair fails, its subnets are reassigned to the surviving instance, and both directions of new flows continue to resolve to that surviving gateway. What does not survive failover is inspection state: Suricata sessions and TLS MITM decryption state are tracked per gateway instance and are not replicated between members of a gateway pair. When a failover occurs:
  • New connections are inspected correctly on the surviving gateway.
  • Connections that were already established and being inspected before the failover are reset; the client and server must re-establish them.
This is the same limitation any stateful inline inspection device has across a failover. It is not specific to east-west traffic. However, east-west inspection depends on symmetric routing, and therefore on gateway-pair health, in a way that north-south inspection, pinned by NAT to a single gateway, does not.

​
Variants and Trade-offs

​
Sizing and Scale Considerations

  • East-west inspection adds the same per-flow inspection cost (signature matching, and decrypt/re-encrypt if TLS MITM is enabled) that north-south inspection already adds on a spoke gateway. This architecture does not introduce a second inspection engine or a separate resource pool.
  • Symmetric routing is scoped per spoke group. Each spoke’s gateway pair independently carries the inspection load for flows terminating in that spoke; there is no shared or centralized east-west inspection point across spokes.
  • No performance impact numbers (added latency, throughput ceiling per gateway size) are published for this design.

​
Security Considerations

  • What this design protects: stateful Suricata IPS signature matching and TLS MITM decryption visibility for traffic between workloads in different spokes, to the same degree of coverage already available for north-south traffic, provided the symmetric-routing prerequisite above is met.
  • What this design does not protect: traffic between workloads attached to the same spoke gateway pair is not affected by the symmetric-routing dependency described here (both directions already resolve to the same gateway), but is still subject to whatever DCF policy applies to it. This architecture does not change that. On spokes that do not have symmetric routing enabled, IPS and TLS MITM actions on east-west rules are converted to Deny rather than left to run without the same-gateway guarantee. See East-West Flow Without Symmetric Routing (Fail-Safe Behavior).
  • Inspection state does not survive gateway failover. See Failover Behavior.
  • Out of scope for this architecture: IPS rule management (custom Suricata rule feeds, SID exceptions) and threat intelligence feed integration are separate capabilities, already covered in Intrusion Prevention System (IPS) and not re-explained here.
  • Decrypted-traffic handling: TLS MITM decryption relies on the same Decryption CA Certificate and trust-bundle mechanism already documented for DCF generally. See About Distributed Cloud Firewall Settings . This architecture does not introduce a separate certificate or trust model for east-west traffic.

​
Enabling East-West Inspection

There is no separate, east-west-specific enablement workflow in CoPilot. An inspected spoke gateway is an ordinary DCF-enabled gateway; what determines whether east-west inspection is effective is the routing topology, not a distinct configuration surface. In practice, enabling east-west IPS/MITM inspection means:
  • Turning on Symmetric Routing on the relevant spoke gateway pair on both sides of the flow you want inspected. AZ Affinity is optional for east-west inspection. See AZ Affinity and Symmetric Routing Architecture for the design Symmetric Routing implements and its current scope (AWS only, not supported with FireNet, in Controller 10.1).
  • Configuring Distributed Cloud Firewall IPS and TLS MITM decryption policy exactly as already documented for north-south traffic in Intrusion Prevention System (IPS) . No east-west-specific IPS Profile, policy field, or configuration step exists: the same profile and policy apply regardless of traffic direction.
Once both are in place, east-west traffic between the affected spokes is inspected using the same DCF policy, the same IPS Profiles, and the same TLS Decryption mechanism already in effect for that policy. No additional step is required.