Building DPI bypass systems on top of wireguard

[Saeid Akbari]

On Wednesday, June 19, 2019 5:11:03 AM +0430 Amir Omidi wrote:
> Hi,
> 
> I've lived in countries under oppressive DPI systems and I want to see if
> its possible to create a DPI bypass system using the wireguard protocol.
> During my time under these DPI systems, I've seen them evolve and grow and
> get stronger and better in detecting various bypass systems.
> 
> In Iran, when there's a lot of political news the government deploys a
> traffic/endpoint ratio strategy. Essentially, instead of blocking specific
> protocols, they block amount of traffic going to a specific IP (or
> sometimes IP:PORT combination if they want to be less strict). This breaks
> every single bypassing solution as they all rely on sending traffic to
> another endpoint.
> 
> The strategy I had in mind was creating a microservice VPN that can be
> deployed across thousands of endpoints with thousands of IPs and Ports. The
> servers would be in contact with each other to "restructure" a packet that
> has gone through to them, and send it off to the actual endpoint.
> 
> Essentially, the client can split a packet into many pieces, send it off to
> a thousand systems, and then get a response back from several servers and
> reconstruct the actual message itself. This would break the ratio based
> detection system. Alongside general hiding techniques such as masquarding
> as https/dns/QUIC traffic, this could be a pretty robust and unstoppable
> system. Especially with IPv6 becoming a lot more popular and maintaining an
> IP ban list much more expensive.
> 
> Thoughts?
> 
> Thanks!

Hi,

I get you man, and I know exactly what you are talking about :)) Anyway, 
here's my two cents.

In theory, yes, but in practice, this is far from being even possible. For 
starters, the amount of overhead it incurs is just massive and unbearable by 
any network; there is some kind of packet re-ordering and assembling involved, 
which makes any slight difference in servers' latencies problematic (let alone 
the packet loss). Also, the communication between the servers is just 
unnecessary and detrimental to the packet throughput.

Even if the proposed solution doesn't sacrifice throughput for fault-tolerance, 
it definitely would be darn inefficient to the network as a whole; so I don't 
think any company or community really wants to implement such an 
infrastructure.

However, the closest thing I've encountered, is VTrunkD project which is not 
maintained anymore, and it's meant to be run on a single server and a single 
client, utilizing only multiple *network interfaces*, not servers and such.