The problem is reproduced even on the latest version of ROS. Source data:
SSTP Server - CHR
SSTP Client - any hardware mikrotik
Built-in Bandwidth test from Client to Server over SSTP shows:
Download - overal normal speed.
Upload - ~5 mbit. Tested on hap ax lite, hap ax^3. The processor is not loaded.
If the client is CHR, the problem does not repeat, the speed is normal in both directions. If the client is Windows, there is no problem either. But as soon as the RouterBoard client - the upload is terrible.
I will also note that this does not depend on the key length and is easily repeated even on clean configurations. Some other settings and attempts to fix the situation did not help either, so I am here. I ask the developers to check and confirm the bug.
A few days ago I got a response to the ticket, but it contained standard advice like decreasing MSS and nothing useful. When I asked to repeat the problem - silence.
Why isn't anyone responding to this major, easily reproducible bug? Developers, where's the support? No one's responding to the ticket either. What's going on? Where else can I report the bug so it's at least confirmed and taken into consideration?
I just tried this on my equipment, took an empty configuration, CHR 7.19.6 as server - local network - client AX Lite 7.19.6, speed 56/26 Mbps (receiving, sending), then tried it with one of my remote devices, AX2 7.20rc6 over the Internet, speed 75/2-4 Mbps. I see that you are right.
Based on my experience with support, if the issue isn't a key one and doesn't have a large number of responses, there won't be any response from support.
The only thing we can do is index the issues for quick search results and select equipment based on the specifics of its malfunction.
Who are we? Are you an official MikroTik representative? That's not how it works, anyway. The functionality is there, and it does its job. For example, I like it better than OpenVPN and other protocols. Its implementation exists and is supported, so the bug needs to be fixed, or SSTP support shouldn't be advertised at all.
This is the user forum. If you're just looking to correspond exclusively with MikroTik, email them at staff@mikrotik.com.
Here, users with their own experience and inexperience share their experiences with various products.
And in my experience, from what I've tried so far, the worst VPN (ignoring security) is definitely SSTP.
Then there are definitely worse ones (ignoring security)...
Anyway, I agree that if it is a feature supported by ROS and there is a bug, it should be fixed. You would need to convince MikroTik support to accept your detailed report rather than debating it here.
It simply doesn't work without some adjustments, and it's not a high-performance protocol anyway.
Support has already told you to change the MSS because from the connection, starting if you have 1500 or 1492 you have to remove all the hoverhead that TCP encapsulation has within TCP encapsulation...
Use a modern VPN like wireguard, maybe even something based on IPSEC (has proven performance more then enough), ... but not SSTP.
Too many Microsoft dependencies.
I suppose opening a port to 8192 is not acceptable for you ?
The reason a VPN over TCP does not work well is that the IP layer is supposed to be "datagram", i.e. a best-effort delivery mechanism, but TCP is not. It will re-transmit packets when they are not acked in time.
But the next higher layer in this case is also TCP, so it will also re-transmit. That means that while the VPN layer is still re-transmitting packets, the file transfer TCP later will also re-transmit and put more packets in the lower layer.
When the upper layer TCP is not well designed (exponential timer backoff) that will mean an avalanche of data being transmitted, of which only a small part is useful data. Hence the terrible throughput.
As I mentioned in the first message, there's no problem between CHR and CHR, nor between CHR and Windows. Even when transmitting data from the server to the hap-client, there's no problem. It only manifests itself when sending data from the hap-client to CHR server, regardless of the MTU. This is clearly a bug.
