CONCEPT Cited by 1 source
Bump-in-the-wire middlebox¶
A bump-in-the-wire middlebox is a network device — firewall, IDS/IPS, DLP, encryption/decryption, transparent proxy — that is inserted into a traffic path by routing, not by configuring endpoints. Applications sending or receiving traffic are unaware the device is there: their IPs, ports, protocols, and API payloads are unchanged. All that changes is which fabric hops the packet traverses before reaching the destination.
"AWS Network Firewall operates as a 'bump-in-the-wire' solution, which transparently inspects and filters network traffic across Amazon VPCs. It is inserted directly into the traffic path by updating VPC or Transit Gateway route tables, allowing it to examine all packets without requiring any changes to the existing application flow patterns." (Source: sources/2025-11-26-aws-secure-amazon-evs-with-aws-network-firewall)
The defining properties¶
Three properties a design must have to be bump-in-the-wire:
- Transparent to endpoints. The source doesn't send to the middlebox, it sends to the original destination; the middlebox is a hop the fabric puts in between.
- Insertion is a routing change. VPC / TGW route table edit, BGP advertisement, VLAN redirect, PBR, or a TAP — not an application config change, not a DNS pointer flip, not a hostname rewrite.
- Removable by reversing the routing change. The packet path can be restored without touching applications; the middlebox can be bypassed in an emergency by reverting the route.
A forward proxy that clients explicitly dial (HTTPS_PROXY=…) is
not bump-in-the-wire. A TGW attachment that adds a firewall
hop to a default route is.
Why the shape is useful¶
- No application churn. Security / compliance teams can deploy new inspection without asking every service team to re-code, re-configure, or re-deploy anything.
- Uniform coverage. A misconfigured app that forgets to set
HTTPS_PROXYcan evade a forward proxy; it cannot evade a bump-in-the-wire middlebox sitting on its default route. - Policy lives in one place. Rule changes, logging, and upgrades happen on one device rather than N application deployments.
- Decommission by routing. When the device is no longer needed, one RT edit removes it — the applications never needed to know.
Canonical AWS implementations¶
- AWS Network Firewall with native TGW attachment: the firewall is reachable via a TGW attachment of resource type Network Function; route tables direct flows through it (see patterns/pre-inspection-post-inspection-route-tables).
- Network Firewall deployed per-VPC via firewall-endpoint subnets: ditto shape at the VPC scale (see concepts/egress-sni-filtering topology).
- NAT Gateway / Internet Gateway: arguably also bump-in-the- wire at a more primitive level — default-routed-through, invisible to apps.
Costs and caveats¶
- Single point of failure unless the device is itself redundant. Managed offerings (Network Firewall) handle redundancy within the service; self-managed appliances have to engineer it.
- Latency tax. Every transit adds hops and processing; not free.
- Asymmetric-routing hazard. If the return path doesn't also go through the middlebox, stateful inspection breaks. See TGW Appliance Mode for the AWS-specific mitigation.
- Encryption opacity. A bump-in-the-wire middlebox can generally only act on headers and metadata unless it has explicit decryption authority (e.g. mTLS termination, key escrow). Hostname-based filtering via TLS ClientHello SNI is the common best-effort L7 signal available to a non-decrypting middlebox.
- Dependency-chain criticality. Once you've inserted the middlebox on everyone's default route, its outage is every network flow's outage. Staged rollout + alarm coverage are essential.
Related shapes¶
- patterns/managed-sidecar — per-workload sibling: security policy is a separate process co-located with the application. Same "transparent to app logic" property, different insertion mechanism (process-level, not fabric-level).
- patterns/protocol-compatible-drop-in-proxy — application- level bump-in-the-wire: a proxy that speaks the same protocol as the original destination and is inserted by DNS / hostname flip. Different level of the stack, same architectural intent.
- concepts/edge-filtering — bump-in-the-wire at the CDN / edge tier for inbound traffic.
Seen in¶
- sources/2025-11-26-aws-secure-amazon-evs-with-aws-network-firewall — canonical wiki reference; the post's explicit framing of Network Firewall as a bump-in-the-wire middlebox inserted by VPC / TGW route-table updates.
- sources/2026-03-23-aws-generali-malaysia-eks-auto-mode — same shape at VPC-egress scale: Network Firewall in front of EKS, default-routed-through via the private-subnet RT.
Related¶
- systems/aws-network-firewall
- concepts/centralized-network-inspection — a canonical aggregation of the bump-in-the-wire shape.
- concepts/tgw-appliance-mode
- concepts/egress-sni-filtering
- patterns/pre-inspection-post-inspection-route-tables