SSTP Speed issue since 6.13 (also 6.14rc)

RouterOS General
1

Since the update to 6.13 I have quite big trouble with the speed of sstp-connections. So I made several tests the last days but I can’t figure out how I could make it work and it really seams to be a correlation with the software version.

I’ve drawn the layout in the file attached, so to sum it up, the main site has a VDSL-connection with 50mbit down and 10mbit up and the client site has ADSL with 16mbit down and 2mbit up.
The issue is the same with different client sites but I tested the different configurations only at one site. On both ends there’s a Fritzbox 7490 DSL Router as also the phone system is running over VoIP and the configuration is fixed in these boxes.

On the main site there’s a 1100AHx2 and I installed a x86-machine on the client side as I thought it might have something todo with performance… but this seems not to be the issue.

I also tried to lower the MTU by mangle the SYN-packets down in stept to values that shouldn’t definitely be fragmented. BTW. the MTU between the sites can be 1492 without fragmentation.

So, with version 6.12 the speed of the link (main-site > client) is about 6Mbps, what’s maybe less than it could be but that’s fine. (see wan.jpg a)
That’s when using Mikrotik on both ends of the VPN and a Windows 7 machine behind the Mikrotik Client. (See layout A).
When I now switch both Mikrotiks to 6.13 (or 6.14rc) I get result about 1500kbps (like shown in file wan.jpg b) and that’s really too less to work with.

If I know replace the Client Mikrotik Router with the Windows 7 PC directly (layout B), though connecting with the Windows machine by Microsoft-SSTP-Client to the RB1100AHx2 that’s working pretty well and faster. It’s about 6.5Mbps with Version 6.12 (wan.jpg c) and about 4.5Mbps with Version 6.13 (wan.jpg d). So the effect that 6.13 has on the speed is much less with the Windows SSTP Client but still definitely to see.

The next setup was to replace the WAN-Link with a 100mbit LAN Link, so there won’t be any issue at provider side I can’t see (Layout C & D). And in fact it’s really faster but the difference is again quite big.

Layout C
While I get a speed of about 23Mbps using Mirkrotik at both ends with version 6.12 (lan.jpg a) I only get less than 8Mbps with version 6.13 (lan.jpg b).

Now again, replacing the client Mikrotik with the Windows SSTP Client I get way better results. (Layout D)
With version 6.12 I get about 73Mbps and with version 6.13 I get about 86Mbit… That’s both fine and don’t differ too much. (lan.jpg c/d).

As there are issues with SSTP in Version 6.12 I’ll have to use 6.14 in future (connection drops that should be fixed in 6.14).
So I’d appreciate any help finding out what’s making the WAN-SSTP-Link so slow with 6.13/6.14rc.

@Mikrotik: Might it be possible to see/know what change for 6.13 could be the cause for this and to fix it in a 6.14rc-version to test?

I’d be happy to give more test result as it’s needed.

Thanks a lot for help!!
Stefan
lan.jpg
wan.jpg
layout.jpg

2

This is a very real performance issue in 6.13 that is easily reproduced and needs to be fixed.
Thanks for writing it up in such detail.

Have you contacted Mikrotik support via their email address?

3

I did, Ticket #2014060266000621.

The strange thing I don’t understand is that the speed measured in the LAN is higher that the speed over the DSL-Link. In my thinking, then the DSL-Link-Speed should be able to be achieved… Very weird, it looks the SSTP Link only uses a percentage of the availible bandwith.

And I have no Idea what I could change furthermore for testing. The next step I could think about is to capture the packets and compare them between <6.13 and >0 6.13 but I’m missing the time at the moment.

thanks

4

There will be always some problems over DSL links. Because of TCP retransmits.

5

In general the DSL-links are quite stable and I’m not aware of retransmits issues. I tested the final 6.14, the speed is the same. So for the 10mbit link (in theory) I get about 1.4mbit transfer. That’s only about 15%.

If it’s caused by TCP retransmits it shouldn’t have such a big influence in the LAN scenario I think. And there should not be such a difference between the versions <= 6.12 and > 6.12. There was nothing changed but the software on the two routers.

Please could you have a more detailed look at this?

6

What speed do you get when testing with UDP bandwidth test and packet size around 1400?

7

Hi, it’s working with 9.6Mbps up to 1492.
bandwidthtest.jpg

8

Hi, it’s still all the same with 6.15. Have you found anything yet?

9

Hi,

now, after having gone back to 5.26 I finally found the solution.

In 5.26 I noticed if I set a rate limit for the ppp profile I never got over ~ 2mbps … and that’s was similar to the stuff above. when I set the buffer of the default small queue up to 50 (I think it was 5?) then I suddenly got more throughput (up to the 10mbps i wanted…).

In 6.15 it seems to have something in common but not exactly the same.

I also set up the default-small queue to 50. But without setting a rate limit in the profile it still stuck with 2mbps.

with 6.15 I HAVE to enable the rate limit and set it BELOW the maximum possible transfer speed of ~10mbps.

As proof:If I set it to 15M like in the screenshot I only get the ~2mbps… as it started with 6.13.
15m.jpg
I really have to set the rate limit so low that the router has to start queueing. Otherwise it’s not working fast enough.
And though I finally get quite a great percentage in throughput but not all I could get.
9m.jpg
Can this please be fixed in an upcoming release!!!

Thanks!

10

By the way: This test was not using the SSTP tunnel. I understood that you wanted to see the quality of the connection itself.
Just to clarify

11

Is this issue solved in the meantime?

12

Have you created a support ticket for that? If yes, post the number here with the last response from mikrotik and if it was not satisfactory, reply back to the support…

13

This was the last answer that sounded like it’s like that because of stability…

The performance drop that you see in RouterOS 6.13 and later is because of our
stability improvements over tunneling protocols which also affects SSTP
performance. There were several crashes reported in v6.12 using SSTP that were
reportedly fixed in v6.13.

We strongly advise you to use the latest RouterOS version to get the best experience.

I now started to write back again, so maybe it’s solved one day

Stefan

14

Keeping fingers crossed.

15

Hi,
I have very much the same problem. SSTP is extremely slow, I get ~2Mbit max, even if the bandwidth between the both ends is ~10x higher.
I’ve also tried the connection from the same endpoint to the other endpoint via OpenVPN running on the same Mikrotik and the speed was much higher, using almost the whole bandwidth, as it should.
So the problem really seems to be related to SSTP.
However I don’t understand the logic of the solution you’ve proposed. You define a Queue which acts in the end as a throttle and in the end you get faster connection? That seems weird to me.
Or did I understand it wrong?
I have to admitt I have no experience with the Queues at all.

16

That kind of solution looks like a workaround for a TCP-over-TCP meltdown problem. Quite clever, I’d say.

17

Try the l2tp instead.

18

L2TP has it own limitations. For example you need to have public ip directly on router (on CPE with DMZ to the router won’t work).

19

Not true for l2tp. You need just one side to be accessible from outer world. No need of public ip on the devices, 1:1 nat or port redirect is enough on the server side. Client side doesn’t need anything special at all.