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 that it made 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 slower compared to my direct connection.
Throughout the tests, I used the latest version of the macOS App Store, as it is the only version of Surfshark that currently supports the new protocol.
I wanted to use the WireGuard speeds as a benchmark for my tests with Dausos. But as soon as I switched protocols, the connection effectively dropped.
Oddly enough, the tunnel wasn’t completely dead. Programs with already established connections — like a Google Sheets tab I was editing and WhatsApp messages — continued to work. However, any attempt to open a new secure site resulted in errors.
I dug deeper using cURL in the macOS terminal to see exactly where the connection failed, and the results were clear: the VPN made the first connection, but timed out after Customer Hello stage.
This strongly suggests that there is a problem at the transport level. 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 large for the pipe, it may be split up and sent again or simply dropped altogether.
Using the ping command to force certain packet sizes, I found that both 1472 and 1400-byte packets failed with a “Message too long” error while connecting 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 cannot handle the large security certificates required for an HTTPS handshake. To prove this, I tried to visit a relic of the early Internet: an unencrypted, plain HTTP website.
While the secure web was blocked, this small, outdated and insecure plain HTTP page was loaded while other major HTTP sites were also effectively blocked.
For a protocol that promises “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 a business-grade office Wi-Fi.
While my colleague was able to browse the secure (HTTPS) web with the new protocol enabled, the underlying MTU metrics showed it was still struggling.
When they ran the same ping tests while connected to Dausos, their terminal showed the same error: “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 up and running. So in this case Wi-Fi may have intercepted the connection handshake and forced the protocol to use smaller data segments so that it could actually fit through the network.
Alternatively, it may come down to the “adaptive” qualities of the protocol. 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 cellular data, the protocol adjusts to maintain optimal speed and performance.”
My research suggests that 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 it 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 reason, the effect was unequivocal – the new protocol just didn’t work for me, on my home setup.
The correction
To prove that Surfshark’s static MTU handling was to blame, I started looking for a solution. By manually overriding the protocol configuration, I was able to access the Internet 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 to life again.
By manually reducing the data payload to accommodate the voluminous encryption, I bypassed the error and pushed the connection through my ISP’s 1492 byte limit. Basically, I did what my colleague’s Wi-Fi connection to the company did automatically.
In other words, to get the ‘first VPN protocol built for you’ to work, I had to open the command line and repair the software myself.
Surfshark’s response
TechRadar contacted Surfshark to share these findings ahead of publication. The company confirmed our diagnosis and admitted that the protocol’s current configuration conflicts with residential PPPoE limits.
The company said it is pushing an emergency hotfix for approval today. We will test the patched version of Dausos when it becomes available.
