Ghost in the ARP Cache: Agentless L7 Enforcement at the Subnet Level

One agent. One subnet. Full policy enforcement. Zero endpoint software required.

Every zero trust deployment eventually hits the same wall: the device you need to protect is the one you can't install software on.

It might be a medical device running a locked-down OS. A factory floor controller that hasn't been rebooted since 2019. A contractor's laptop that IT doesn't own. A legacy printer that somehow has access to the accounts payable VLAN. Whatever the reason, the device exists, it has network access, and you have no way to put an agent on it.

The standard answer is network segmentation — put unmanaged devices in their own VLAN and control what they can reach at the perimeter. That works at layer 3 and layer 4. It doesn't give you application-layer visibility. It doesn't let you enforce policies based on what the device is actually doing. And it requires network infrastructure changes that can take weeks to plan and execute.

Threatmatic's answer is different. It's called Gateway Intercept mode — and it works by haunting the ARP cache.

The ARP Insight

Every device on an Ethernet network maintains an ARP cache — a local table mapping IP addresses to MAC addresses. When a device wants to send traffic off-subnet, it looks up the gateway's IP address in that table, finds the corresponding MAC address, and wraps its packets in an Ethernet frame addressed to that MAC.

The key insight: ARP has no authentication. Any device on the subnet can broadcast an ARP reply claiming to be any IP address. If your MAC address is in a device's ARP cache as the entry for the gateway IP, that device will send you its off-network traffic — unconditionally, invisibly, without any configuration change on the device itself.

This is ARP spoofing. It's been known as an attack technique for decades. Threatmatic turns it into a controlled enforcement primitive.

How Gateway Intercept Works

A single Threatmatic agent enrolled in the target subnet operates as a silent inline enforcement point. The sequence is straightforward:

1. ARP interception

The agent continuously broadcasts gratuitous ARP replies to the subnet, advertising itself as the gateway:

ARP Reply: 192.168.1.1 is at <agent MAC address>

Every device on the subnet receives this reply and updates its ARP cache. From that moment, all off-network traffic flows to the agent's MAC address — not the real gateway's.

2. Policy enforcement

Traffic arriving at the agent is inspected against the full Threatmatic policy set:

• Layer 3/4 rules (IP, port, protocol) evaluated first
• Layer 7 rules (domain, path, method, content type) evaluated via the inline mitmproxy engine
• Blocked traffic receives a silent 204 response in 2–8 milliseconds
• Permitted traffic is forwarded to the real gateway

3. Forwarding

The agent maintains IP forwarding and passes permitted traffic upstream to the real gateway, which routes it to its destination. From the destination's perspective, nothing has changed. From the device's perspective, nothing has changed. The agent is invisible to both ends.

4. Telemetry

Every flow — permitted or blocked — is logged to the Threatmatic event store with source IP, destination, application-layer details, and policy decision. Security teams get full visibility into what every device on the subnet is doing, without a single agent installed on any of those devices.

QUIC: Closing the UDP Blind Spot

Modern browsers negotiate QUIC — Google's UDP-based transport — before falling back to TCP. Since mitmproxy operates on TCP, QUIC traffic would bypass inspection.

Gateway Intercept closes this gap with a single forwarding rule:

# Drop UDP/443 — force QUIC fallback to HTTP/2 over TCP
iptables -A FORWARD -p udp --dport 443 -j DROP

Browsers detect the blocked UDP path within ~100ms and transparently retry over TCP. The user sees no interruption. The agent sees everything.

Deployment: Seconds, Not Weeks

The operational contrast with traditional network enforcement is stark.

A Gateway Intercept deployment requires:

1. A Linux host on the target subnet with the Threatmatic agent installed
2. IP forwarding enabled on that host
3. The agent enrolled in the relevant Threatmatic organization

That's it. No router access. No DHCP changes. No network topology modifications. No downtime. The agent broadcasts ARP replies, intercepts traffic, and begins enforcing policy immediately.

Graceful Failover

The one operational concern with ARP-based interception is failure handling. If the agent crashes without restoring ARP, devices on the subnet lose connectivity — their ARP caches point to a MAC address that's no longer forwarding traffic.

Threatmatic's Gateway Intercept mode handles this with a shutdown hook that broadcasts the real gateway's MAC address before the agent process exits:

# On shutdown: restore the real gateway's ARP entry
arpsend -U -i eth0 192.168.1.1 <real_gateway_mac>

For environments requiring higher availability, two agents can share a virtual MAC using VRRP-style failover — if the primary stops broadcasting ARP replies, the secondary takes over within seconds.

What the Policy Engine Sees

Without an endpoint agent, process-level telemetry isn't available — Gateway Intercept can't tell you that chrome.exe made a request, only that 192.168.1.47 did.

The mitmproxy L7 engine compensates significantly. At the application layer, Gateway Intercept surfaces:

• Host and path — the full URL structure of every HTTPS request
• Method — GET, POST, PUT, and the semantic intent they imply
• Response code — 200, 204, 401, 429, and what they reveal about the interaction
• Content type — distinguishing API calls from asset fetches from streaming media
• Duration — latency patterns that can indicate beaconing or tunneling

Combined with network-layer telemetry (source IP, destination IP, port, protocol), this is sufficient to detect the overwhelming majority of threat behaviors — C2 beaconing, data exfiltration, lateral movement, unauthorized SaaS usage — without a single endpoint agent.

The Fleet-Wide Picture

Consider an environment with five network segments that IT doesn't control: a guest Wi-Fi, a building management VLAN, a medical device subnet, a manufacturing floor network, and a legacy systems segment.

Five Threatmatic agents — one per segment, running on any available Linux host. Five Gateway Intercept deployments. Five subnets fully under policy enforcement, with application-layer telemetry flowing into the Threatmatic event store, enforcing the same policy set as the rest of the managed fleet.

No endpoint software on any of the devices in those segments. No network infrastructure changes. No router access requested. No change management tickets filed.

The ghost is in the ARP cache. The subnet doesn't know it. The devices don't know it. The traffic flows through — inspected, enforced, logged — and continues on its way.

Security That Doesn't Wait for Permission

Traditional zero trust deployment asks: "Can we install an agent on this device?"

Threatmatic Gateway Intercept asks a different question: "Is there a Linux host anywhere on this subnet?"

If the answer is yes, enforcement begins in minutes.

Threatmatic Gateway Intercept mode is available to enterprise customers. Contact us to discuss deployment options for your environment.