Building a DPDK‑Based Domain Interception Gateway with TCP Hijacking

Background Introduction

Business Background

Company policy requires that services cannot use unregistered domain names. Simple textual rules are insufficient, especially for public‑cloud environments, so an effective mechanism is needed to detect and block traffic to unregistered domains.

Internally, traffic analysis can parse request packets to find unregistered domains and notify the responsible department. In public‑cloud scenarios this is inadequate, so a dedicated traffic‑control node— a virtualized gateway— is introduced, giving rise to the domain‑break gateway.

Business Scenario

The domain‑break gateway is placed before a virtualized gateway and intercepts HTTP/HTTPS services based on content, similar to a WAF but focused solely on domain registration status.

Gateway Design

Overall Architecture

The gateway, like the FIP gateway, is built on DPDK to leverage high‑performance packet I/O. The system consists of a control layer and a data layer.

The control layer creates lock‑free queues via DPDK to communicate configuration (domain rules) to the data layer. Network devices use DPDK PMD drivers for user‑space packet I/O. For connections that need interception, the data layer uses DPDK’s KNI module to hand the connection to the kernel, where Nginx processes the request.

The data layer receives packets from the NIC, performs connection tracking, parses the payload to extract the domain name, checks it against a whitelist, and either forwards the traffic or intercepts it with a block page.

Packet Processing Flow

The processing follows a simplified Netfilter‑like pre‑routing hook, handling only TCP ports 80 and 443. Packets are stripped layer by layer until the application layer, where HTTP host headers or TLS ClientHello SNI fields provide the domain name.

For HTTP, the plain‑text Host header is extracted via string matching. For HTTPS, the TLS handshake’s ClientHello extension contains the Server Name Indication (SNI), which reveals the domain.

Extracted domains are matched against a whitelist using the high‑performance Aho‑Corasick‑based multi‑pattern matching (acbm) algorithm. Allowed connections are marked and forwarded; disallowed ones trigger the interception flow.

Domain‑Break Processing Flow

To return an interception page for HTTPS, the gateway performs TCP connection hijacking by customizing the SYN‑proxy mechanism: the client’s window is not zeroed, allowing the client to send the first data packet. The gateway then adjusts TCP sequence numbers to keep the connection alive, effectively acting as a man‑in‑the‑middle.

After hijacking, the connection is redirected to a local Nginx instance via DPDK’s KNI interface, which passes the packet to the kernel’s network stack. Nginx generates the block page, which is sent back through KNI, DNAT‑ed to the original client address.

Two diagrams illustrate the HTTP and HTTPS interaction flows (images omitted for brevity).

Advantages and Limitations

TCP hijacking bypasses SSL encryption, and KNI enables a single‑machine deployment, simplifying network topology and saving server resources. However, KNI’s performance is lower than direct access, limiting scalability under high concurrency or large traffic volumes. Since domain‑block responses are lightweight (≈1 KB), the solution is acceptable for typical use cases, with possible extensions such as switch‑level blocking for heavy abuse.