Hi, I?m making several experiments connecting 2 mikrotiks by a SSTP tunnel, then using bandwith test. Shortly, in all cases I can’t go over 30megabit/s using one way, and also about 30 as sum down/upload. As best combination platforms experiment, I’ve tried with CHR that has good CPU on a server farm, and a Hex connected gigabit to a home router with 1gbps. The thirs router is an ac3 with a 100mbps connection.
I’ve used UDP, with TCP on send I have only 6,5mbps instead of 30, but receive they are almost similar. stange, it looks fragmentation coming but only on one sense.
Anyway, how can I improve this limit of 30 mbps? With wireguard I can get 65.. any limitation involved on a fake https connection by the providers?
You can only improve your performance of SSTP with hardware encryption. IIRC, ac3 doesn’t support that. Ax3 does, however.
That’s the nature of SSTP protocol, which uses TCP, compared to Wireguard and UDP. ANd encryption algorithm also matters.
I understand, unfortunately due to restrictions, only SSTP works, so I’m focusing on it.
Thanks for sharing your experience
I’ve managed to push 400 Mbit btest between gigabit single-core CHR VMs with SSTP and H flag on it. This could be more I suppose, because btest also takes CPU cycles to generate UDP traffic. Wireguard pushed around 850+ same channel, so you can compare the numbers.
I have an ax3 with 300Mbit channel at home, and it can push whole 300Mbit to a VM over SSTP without being fully utilized (no fasttrack also).
Cool, so I know there is no limitation, but.. limitation can be somehow made by providers?
I’ve never reached 100% cpu but not low too, on HEX went up to 60%, on ac3 about 35-40.. on CHR about 30, for 30 megabit.
I don’t think it’s caused by crypting data, but chances are to light up this process? I’m not too interested to protect data, I?m more interested on speed.
Does fasttrack slow the process? Better to turn it off?
I’m pretty sure it’s bottlenecked by a single core of your routers. Since it’s stream cipher, I doubt it can be multithreaded, as packet order should be preserved. HEX has two cores, so one of cores is fully loaded, that’s why it’s slightly above 50%. Ac3 has four cores, that’s why it’s slightly above quarter. CHR cores should be more potent than hap/hex cores, so they aren’t under full load.
You can check what loads your router with /tool profile utility also available in GUI and maybe have some answers.
Yes it’s cipher, is it possibile to disable it or choose a lighter one to improve throughput?
Thanks
No, SSTP uses AES and you can’t just disable it, as it defeats the purpose of protocol, best you can do with that is use device with aes-hw-offload. Or use another protocol which has optimized software encryption, like wireguard.
Thank you for your kind explanation 
Unfortunately by now only SSTP can be used
I have a hAP AX3 model and it supports the AES-GCM SSTP hardware offloading. Unfortunately, the AES-CBC code is still working software. I have now tested the speed to my Chr (udp 500 Byte) and got the following results:
85M up CBC 40% CPU SW
85M down CBC 24% CPU SW
85M up GCM 18% CPU HW
85M down GCM 15% CPU HW
- The numbers are purely indicative and strongly “walk” in both directions.
Versions of Router OS everywhere from 7.16 to 7.19beta. My Internet provider provides a 100M tariff.
I have no hardware offloading on the hAP AC2 and AC3 (ARM 32B). I think the hardware offloading of the GCM will work on all ARM64 processors.
Whoever uses SSTP needs to understand that it is highly inefficient, by design. Every packet, no matter if TCP or UDP, is encapsulated in an SSL connection, running over TCP, requiring the usual ACK packets again. Even a CCR2116 manages only about 100-200 Mbit/s per connection, and jitter goes 20x, while not even peaking a single CPU core. WireGuard in contrast runs at wire speed with barely no changes in ping and jitter. The use-case for SSTP is punching through restrictive firewalls and it working everywhere, but it’s always associated with a lot of overhead.
Exactly. Whenever I run into this topic, I like to link to this page: Why TCP Over TCP Is A Bad Idea
SSTP is a last-ditch, “I’m desperate and literally nothing else will work” VPN protocol. If someone is in that situation, I do not blame them for using it and for trying to make it perform the best it possibly can, given the realities. But if anyone is expecting it to perform super-awesomely, well…