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 try the new VPN protocol I couldn’t connect at all. Far from increasing speeds, the protocol was so bulky that it made the secure network 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 slightly slower download speeds compared to my direct connection.
During testing I used the latest version from the macOS App Store, as it is the only version of Surfshark that currently supports the new protocol.
I wanted to use WireGuard speeds as a benchmark for my testing with Dausos. However, as soon as I changed protocols, the connection dropped.
Curiously, the tunnel was not completely dead. Apps with connections already established, such as a Google Sheets tab I was editing and WhatsApp messages, continued to work. 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 connecting. CustomerHello scenery.
This strongly suggests the existence of a transportation problem. To confirm, I ran a series of MTU (Maximum Transmission Unit) tests.
MTU is basically the size of the connection or “pipe” available. If a data packet is too large for the pipeline, it may be split and resent or simply dropped entirely.
When using the ping command to force specific packet sizes, I found that both 1472 and 1400 byte packets failed with the “Message too long” error while connected to the application.
This clearly 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 demonstrate, I tried visiting a relic from the early days of the Internet: a simple, unencrypted system. HTTP website.
While the secure web was blocked, this small, outdated and insecure simple HTTP page was loaded, while other larger HTTP sites were also effectively blocked.
For a protocol that promises “next generation” security, it’s ironic that it only worked for me when accessing lightweight URLs clearly marked “Not Secure.”
My colleague’s research
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 network.
While my colleague was able to browse the secure web (HTTPS) with the new protocol enabled, the underlying MTU measurements showed he was still having issues.
Running the same ping tests while connected to Dausos, your terminal showed the same error: “Request timed out” and “Message too long.”
So why did your browser work and mine not?
Many enterprise-grade office routers are smart enough to manipulate the connection and ensure it keeps working. So in this case, Wi-Fi may have intercepted the connection handshake and forced the protocol to use smaller segments of data so that they can actually pass through the network.
Alternatively, it may all 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 using a fast fiber connection or switching between Wi-Fi and mobile 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, that would be too close to the 1492 byte limit. And, once the “bulk” of Dausos’ post-quantum encryption is added, the total packet size increases beyond what many standard home routers can handle.
Whatever the root cause, the impact was unmistakable: the new protocol simply didn’t work for me in my home setup.
The solution
To prove that Surfshark’s static MTU handling was the culprit, I started looking for a solution. By manually overriding the protocol settings, 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 and encrypted web came to life.
By manually reducing the data payload to make room for the bulky encryption, I avoided the failure and pushed the connection over my ISP’s 1492-byte limit. Basically, I did what my colleague’s enterprise Wi-Fi connection did automatically.
In other words, to get the ‘first VPN protocol built for you’ to 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 ahead of publication. The company confirmed our diagnosis, admitting that the current protocol configuration conflicts with the limits of residential PPPoE.
The company said it is pushing for an emergency review for approval today. We will try the patched version of Dausos once it is available.
