Deep Packet Inspection (DPI) Explained: How It Works and How to Bypass It

ISPs and Deep Packet Inspection

ISPs have two problems:

• they are legally required to restrict access to certain data;
• no company wants to pay extra for a dedicated link to an upstream provider, which obviously incurs charges.

Both issues can be addressed by restricting specific requests or entire protocols—exactly what deep packet inspection (DPI) is designed for.

This deprives everyday users of many capabilities. An ISP, for instance, can block or severely throttle all BitTorrent traffic, making torrent downloads effectively impossible. Or, in pursuit of extra revenue, it might “switch off” VoIP and Skype for everyone except those who have specifically paid for access.

DPI can detect and terminate connections based on defined rules, and its capabilities vary by equipment vendor. The one constant is that DPI operates from the transport layer of the network model upward.

The Networking Model

Computer networks are built to let you focus on complex applications, not on cables and bits.

To that end, four layers of abstraction were defined. Each higher layer makes it easier to work with the information transmitted over the network.

• Link layer (Level 1). Based on physical processes. It identifies and connects devices using hardware (MAC) addresses. Key protocols: ARP, L2TP, and PPP.

• Routing layer (Level 2). Operates with IP addressing and builds logical paths between nodes using IPv4, IPv6, and IPsec. These first two layers are foundational: they describe how computers can find each other.

• Transport layer (Level 3). Concerned with moving data and the quality of that delivery. TCP and UDP are the core protocols here. TCP provides reliable, ordered delivery; UDP is lightweight and connectionless, used when low overhead matters.

• Application layer (Level 4). Extremely broad because of the huge number of protocols, and whether it’s used depends on the application. When it is, protocols like HTTP and WebSocket power web browsing, MMORPGs, and chat. FTP is mainly for file transfers, while POP and IMAP are used for email.

DPI appliances typically operate at the transport layer, inspecting TCP and UDP packets and reading not just the headers but also the payload.

Packet Analysis

Every protocol has a well-defined internal logic and specific signatures that allow the peers in a connection to determine who is speaking and what is being communicated.

HTTP

Let’s use HTTP—the most widely used protocol—as our example. We’ll send a request to http://example.com.

A standard browser request: it’s sent to IP 178.248.232.27 (the site’s server address, publicly known because it’s used for routing) and asks for the resource at / on xakep.ru (via the Host header). The key to identifying HTTP traffic is its distinctive headers.

• The characters from the start up to the first space are the HTTP method. The key ones are GET, POST, and HEAD. There are others, but these three account for over 97% of all HTTP requests.
• Everything after the second space to the end of the line is the protocol version, typically HTTP/1.1 or HTTP/1.0.

All this data can be used to determine what the request is and where it’s headed. And once the destination is known, you can decide to block it or, in the case of xakep.ru, prioritize the connection.

But HTTPS is becoming increasingly widespread these days—so what about that?

Because the traffic is encrypted, you can’t read its contents without special preparation. One way to do it is a man-in-the-middle (MITM) attack, where an attacker (or an ISP) inserts themselves into the connection, posing as the server to the user and as the legitimate client to the server.

But that would require full access to the victim’s computer, because the certificate (and its private key) used to secure the connection is signed and can’t be altered.

In that situation, providers have no choice but to block traffic based on the only remaining signal—the IP address. That leads to blocking not just a single page (as would be possible without HTTPS), but the entire site—and, if you’re unlucky, other sites hosted on the same infrastructure as well.

BitTorrent

Because peer-to-peer (P2P) traffic carries a large volume of data, ISPs sometimes try to throttle these transfers. The data transfer mechanisms in P2P networks are much more complex than HTTP, but DPI vendors have still found ways to identify them.

If you break down the BitTorrent protocol, you can split it into several components, each representing a set of relatively easy-to-identify connections. In µTorrent, connections always start either from a *.torrent file or from a magnet link. Inside is metadata in Bencode format: file names, directory structure, piece layout, and, of course, trackers (announce).

This is a human-readable view of a .torrent file for the Ubuntu 18.04 distribution. The most important part is the list of trackers — coordination points. Typically, these are just HTTP servers that know which peers are currently willing to upload data to you, and they also track your progress and status in the swarm.

The first step in downloading a torrent is a peer request over HTTP or TCP, which DPI systems can detect either by the destination IP or by the Host header in the request. In addition, the request body will contain bencoded data—something specific to BitTorrent traffic.

The second stage is exchanging handshakes with the newly discovered peers. For each peer we keep four flags: am_choked and peer_choked — whether data transfer to/from the peer is currently choked (blocked); and am_interested and peer_interested — whether either side has pieces the other wants (i.e., anything worthwhile to transfer).

The handshake with peers, as well as the request to the tracker, is populated with data (client ID, file hashes, and so on) using Bencode. This makes identification easier. Moreover, depending on the protocol version and the client, the data may contain the string BitTorrent protocol (or another client-specific string), which simplifies identification even further.

The third stage of communication—the actual data transfer—runs over UDP. Messages control flow and the choked/interested states and, most importantly, carry the payload itself. Some of these messages have a strictly fixed body length, which can serve as a fingerprint for DPI equipment when analyzing traffic.

These phases are easy to spot, which lets inspection gear detect them and either block or throttle the connection. Some vendors kill connection attempts outright. Others, a bit savvier, spoof the traffic so that everything looks normal to the client, but the download never actually starts.

VoIP

Voice over Internet Protocol (VoIP) is a crucial part of modern communication. Skype alone has 300 million monthly users. This technology powers calls in WhatsApp, Telegram, Viber, and more.

That said, the relationship between VoIP and DPI is less adversarial: there’s no rigid, standardized client-to-client interaction, no common data format, and some applications even encrypt their connections.

SIP (Session Initiation Protocol) helps the packet analyzer by defining how clients initiate, manage, and terminate their sessions. It exposes several parameters in an HTTP-like format, which makes it easy to analyze.

Like HTTP, SIP uses its own three-digit status codes that are transmitted in the clear, and this combination lets DPI (Deep Packet Inspection) identify the protocol—if not from the first packet, then by the second or third—and immediately take the necessary actions.

Evasion Techniques

When dealing with DPI, the key is to trick scanners that are tuned for normal requests. Small tweaks to the request structure can throw them off.

The most effective way to defeat traffic analysis is to encrypt the entire payload and send it to a private, unknown server on the internet that decrypts the data and executes the request on your behalf. That’s exactly the approach used by obfs4proxy.

Originally designed as a pluggable transport for Tor, obfs4 can also run in both client and server modes, letting almost any application route its traffic through an obfuscated tunnel. A good example is OpenVPN, which handles this well while also providing an encrypted data channel.

OpenVPN can also masquerade as legitimate HTTPS traffic, which Deep Packet Inspection (DPI) systems will treat as normal.

You can try routing your VPN traffic over port 443 instead of the default 1194, though that doesn’t always do the trick. Alternatively, use stunnel as an SSL tunnel. SSL encryption makes the tunnel’s data packets almost indistinguishable from regular HTTPS traffic, helping you evade DPI.

You can also try to fool the analyzer directly using tricks from the TCP segmentation world. One technique for breaking large packets into smaller ones to reduce loss leverages the TCP Window Size, which controls data flow over the connection. Pre-setting it to 2 for each packet will cause the sender to split it into two segments.

First:

Second:

None of these packets will be recognized as a legitimate HTTP session, so the traffic slips past all the filters.

An address-based site block (based on the Host header) can also be bypassed with the following request:

Instead of manually obfuscating every packet, you can use the GoodbyeDPI utility to do it for you. It helps you choose the most effective combination of tweaks so your traffic slips past DPI inspection.

Conclusion

As you can see, traffic analysis algorithms are keeping pace with circumvention technologies. Every new advance in monitoring user traffic makes it harder to access the unfiltered internet. The community of engaged users strives to keep the internet free from control and censorship, and thanks to their efforts we can continue to operate on the open network.