Obfuscated VPN Servers Disguise a Tunnel That Is Easy to Detect

Obfuscation is the setting a VPN app offers when a network refuses to carry the tunnel, and the word promises more than the technique has been shown to deliver. What it adds is a layer of disguise around traffic that is otherwise straightforward to classify. Whether the disguise holds has been measured, and the published answer is narrower than the marketing.

What the wrapper is actually wrapping

Nothing inside the tunnel changes. Your traffic is encrypted and packaged exactly as it was before, and that result is then placed inside a second layer whose job is to present a different appearance to whatever is reading the line. The tunnel underneath is left alone, which is why a provider can offer this as a toggle rather than as a separate product.

What is on the line to begin with, and why a default connection stands out on it, is a question about your own provider and it is answered there rather than here.

The second layer can go in one of two directions, and the two fail differently.

One direction is to resemble something unremarkable. The traffic is shaped so that an observer sorting connections by protocol files it alongside everything else and moves on.

The other is to resemble nothing whatever. Every byte of the payload is encrypted, so there is no version number, no header and no structure left for a signature to match against.

Both sound convincing written down. Both have been taken apart in the open literature.

What happened when researchers tested the first approach

A team from the University of Michigan, Merit Network and Arizona State put this to the test at the 31st USENIX Security Symposium in 2022, under the title “OpenVPN is Open to VPN Fingerprinting”. They built a detector in two stages, a filter reading traffic as it passed and probes sent afterwards to any server the filter flagged, then ran it on live traffic at a regional internet provider serving a million people.

On ordinary connections the result was emphatic. The paper reports identifying “over 85% of OpenVPN flows with only negligible false positives”, which it takes to suggest that “OpenVPN-based services can be effectively blocked with little collateral damage”.

The study also covered commercial obfuscated services, and that is the part that matters here. Of the products it tested, the paper records that their “operators often tout them as ‘invisible’ and ‘unblockable’”. Against that set, the framework “successfully identified connections to 34 out of 41 ‘obfuscated’ VPN configurations”. Taking ten providers from a published ranking, the authors add that “Eight out of the top 10 providers offer obfuscated services, yet all of them are flagged by our Filter.”

The reasons are mundane rather than ingenious. Most implementations examined resembled one widely copied patch that scrambles the payload, which the paper describes as “easily fingerprintable”. Two further weaknesses did the rest. A “lack of random padding at the obfuscation layer” leaves packet sizes telling the story the payload no longer tells, and “co-location with vanilla OpenVPN servers” means the disguised address frequently sits beside an undisguised one belonging to the same service.

The authors are careful about what their result does not condemn, and the qualification is worth repeating. Of the tunnelling tools pressed into service as wrappers, they write: “We note that this does not mean these tunneling tools do not work, but rather that protection against traffic analysis is not among the design goals.” The components are not defective. They were built against a different problem from the one the product description implies.

Their advice to readers is stated without hedging: “We warn users with heightened threat models not to expect that their VPN usage will be unobservable, even when connected to obfuscated services.”

Resembling nothing turns out to be a signature of its own

The second direction fails in a way that is easier to miss, because it feels airtight. If the traffic carries no pattern, there is nothing to recognise.

The counter is to stop recognising and start excluding. A second paper at USENIX Security, in 2023, measured a national firewall doing precisely that, under the title “How the Great Firewall of China Detects and Blocks Fully Encrypted Traffic”. Its subject was the circumvention proxies built this way, among them obfs4, a wrapper the earlier study had also found inside commercial VPN products. The paper describes that family as protocols “which encrypt every byte of the payload in an attempt to ‘look like nothing’”.

Rather than describing the thing it wanted to stop, the system worked backwards. The authors found that “instead of directly defining what fully encrypted traffic is, the censor applies crude but efficient heuristics to exempt traffic that is unlikely to be fully encrypted traffic; it then blocks the remaining non-exempted traffic.”

The exemptions they inferred are coarse and cheap to run. A connection was let through if its opening bytes matched a recognised protocol, or if enough of its bytes fell in the printable range, or if the proportion of bits set sat outside a narrow band. Traffic random enough to match none of the exemptions was blocked.

Two things there are worth keeping. The first is that looking like nothing is itself something to look like, so a design that carries no signature acquires one by elimination. The second is the price of the method: the authors estimate that applied broadly their inferred rules “could potentially block about 0.6% of normal Internet traffic as collateral damage”, which is the bill attached to running it against everything. They also record the dynamic blocking they measured having stopped by March 2023, so it stands as a demonstration of what is available rather than a description of today.

The disguise is not applied to the address

This is the limit the word obfuscation talks over, and the one most likely to matter to you.

Everything above concerns an observer sitting on the line between you and the server. The disguise is put on traffic in motion and taken off at the far end, which means it is not put on the one field the network has to be able to read. Your packets carry an outer address so that they can be delivered at all, and that address belongs to whichever server you connected to, disguised or not.

So the site at the far end is reading something the wrapper does not reach. The signals a site reads off your visible address include “whether your visible IP looks like a VPN”, and an obfuscated server’s address is still an address belonging to a VPN service, so that answer does not improve because the traffic arriving was shaped differently. How those labels come to be attached, and what attaches them, is a separate question about reputation data rather than about protocols.

The browser tells the same story one layer up. What your browser hands over on every request reaches the server unchanged whichever wrapper brought it, and that page makes a point about disguise in general that lands squarely here: a user agent can be overridden, but “changing it can break websites and may make your browser fingerprint more unusual”. A disguise nobody else is wearing is not camouflage.

What the extra layer costs

An extra layer means extra work on every packet, at both ends. If your connection slows once you switch this on, the ordinary causes are worth ruling out first, because an added layer is one candidate among several rather than the obvious culprit.

What it is actually good for

The useful distinction is between a network that is indifferent and a network that is interested.

A hotel or a campus that refuses VPN traffic by blocking a port is not inspecting anything. It is applying a cheap rule, and traffic moved to a port that the rule permits will pass. That is a real problem genuinely solved, and for anyone whose complaint is that the tunnel will not come up on a particular network, the setting is worth trying before anything more elaborate.

A network that is interested is a different proposition, and that is what both papers address. The Michigan authors put the reach of their own method plainly, concluding that tracking and blocking OpenVPN, “even with most current obfuscation methods, is straightforward and within the reach of any ISP or network operator”. That is the sentence to carry away, because it says the capability is ordinary rather than exotic. Against an observer who has decided to look, the published results say to plan on being seen, and to make that assumption before it matters rather than after.