On Monday, Surfshark launched its new, proprietary post-quantum VPN protocol, Dausos. The company says it “breaks all speed barriers” and is “the first protocol built for the user.”
But when I went to test the new VPN protocol I couldn’t connect at all. Far from a speed boost, the protocol was so bulky it rendered the secure web inaccessible on a standard home fiber connection.
How I tested Surfshark’s Dausos protocol
First, I established a baseline using the industry-standard WireGuard protocol. The results were impressive, with download speeds only slightly down compared to my direct connection.
Throughout the tests I was using the latest macOS App Store version as it’s the only version of Surfshark that currently supports the new protocol.
I wanted to use the WireGuard speeds as the benchmark for my tests with Dausos. However, as soon as I switched protocol the connection effectively dropped.
Strangely, the tunnel wasn’t completely dead. Applications with already-established connections — like a Google Sheets tab I was editing and WhatsApp messages — continued to function. But any attempt to open a new, secure website resulted in errors.
I dug deeper using cURL in the macOS Terminal to see exactly where the connection was failing and the results were clear: the VPN made the initial connection, but timed out after the ClientHello stage.
This strongly suggests the existence of a transport-level problem. To confirm, I ran a series of MTU (Maximum Transmission Unit) tests.
MTU is basically the size of the available connection or “pipe.” If a data packet is too big for the pipe, it might be split up and resent or just dropped entirely.
Using the ping command to force specific packet sizes, I found that both 1472 and 1400-byte packets failed with a “Message too long” error while connected to the app.
This strongly indicates that the connection was unable to handle larger packets — for example, those involved in the TLS handshake response mentioned above.
The result? The VPN tunnel is established, but it can’t handle the large security certificates required for an HTTPS handshake. To prove this, I tried to visit a relic of the early internet: a non-encrypted, plain HTTP website.
While the secure web was blocked, this small, outdated and insecure plain HTTP page loaded, while other larger HTTP sites were also effectively blocked.
For a protocol promising “next-gen” security, it’s ironic that it only worked for me when accessing lightweight URLs clearly marked as ‘Not Secure.’
My colleague’s investigation
To see if this was an isolated issue with my home setup, I asked a colleague to replicate the tests on an enterprise-grade office Wi-Fi.
While my colleague was able to browse the secure (HTTPS) web with the new protocol enabled, the underlying MTU measurements showed that it was still struggling.
When running the same ping tests while connected to Dausos, their terminal displayed the same failure: “Request timeout” and “Message too long.”
So, why did their browser work while mine didn’t?
Many enterprise-grade office routers are smart enough to manipulate the connection to ensure it stays working. So in this case, the Wi-Fi may have been intercepting the connection handshake and forcing the protocol to use smaller data segments so it could actually fit through the network.
Alternatively, it may come down to the protocol’s “adaptive” qualities. According to the release notes, the protocol “adapts to your network conditions and device capabilities. Whether you’re on a fast fiber connection or switching between Wi-Fi and mobile data, the protocol adjusts to maintain optimal speed and performance.”
My investigation suggests this “adaptation” has a blind spot. An analysis of my system’s network configuration (ifconfig) while connected via Dausos showed a static 1424 MTU.
For millions of UK residential customers that would be too close to the 1492-byte limit. And, once you add the “bulk” of Dausos’ post-quantum encryption, the total packet size swells beyond what many standard home routers can handle.
Whatever the root cause, the impact was unequivocal — the new protocol just didn’t work for me, on my home setup.
The fix
To prove that Surfshark’s static MTU handling was to blame, I started looking for a fix. By manually overriding the protocol’s configuration, I was able to access the web normally.
Specifically, I forced the MTU down to a conservative 1280 bytes using: ‘sudo ifconfig [interface name] mtu 1280’ and immediately the secure, encrypted web sprang back to life.
By manually reducing the data payload to make room for the bulky encryption, I bypassed the flaw and pushed the connection through my ISP’s 1492-byte limit. Essentially, I did what my colleague’s enterprise Wi-Fi connection did automatically.
In other words, to make the ‘first VPN protocol built for you’ work, I had to open the command line and fix the software myself.
Surfshark’s response
TechRadar reached out to Surfshark to share these findings prior to publication. The company confirmed our diagnosis, admitting that the protocol’s current configuration clashes with residential PPPoE limits.
The company said it is pushing an emergency hotfix for approval today. We will test the patched version of Dausos once it becomes available.
https://cdn.mos.cms.futurecdn.net/iAQEoK33t7WyTZ7KLyjpAT-2560-80.png
Source link
samuel.woodhams@futurenet.com (Samuel Woodhams)
