MikroTik

Posted: **Mon Jun 06, 2011 8:27 pm**

I've tried to search through the forums on this but I can't seem to find anything with my specific issue and resolution.

I've tried an SSTP, PPTP and L2TP tunnel from three locations back to one central location and I seem to be VERY slow speeds. I've played around with MTU's, encryption, compression but it's all just about the same. SSTP seems to be the fastest where I'm getting about 10-15% of the max speed and 5-7% with L2TP and PPTP. The CPU on the VPN server RB is about 3-5% an the remote locations are 0-1%. All locations are RB750G's at the moment. The central location will have a RB1200 soon.

Any suggestions on making things faster or more efficient?

Posted: **Mon Jun 06, 2011 9:05 pm**

On and I don't think the RB750G's are the issue. I set up a desktop with 2GB of Mem and Quad Core 2.3Ghz and 2 NICs and it's still doing the exact same thing with the RouterOS 5.4 ISO demo image.

Posted: **Wed Jun 08, 2011 7:58 pm**

Anyone have any ideas?

When I do a BW Test to the internal SSTP/PPTP/L2TP address I get about 500k-700k. When I test the external IP of the Mikrotik I get about 5Mb-6Mb.

Posted: **Tue Jun 14, 2011 5:06 pm**

Hello,
I have the same problem did you get any solution for this?

Posted: **Tue Jun 14, 2011 6:45 pm**

No I have not. Another thing is I've tried is downgrading to 4.17 but I'm seeing the same issues.

I contacted the reseller I purchased the hardware from and they said they don't provide support. I also contacted mikrotik support directly and I haven't hard back from them.

Posted: **Tue Jun 14, 2011 6:49 pm**

is possiable to chat via massenger and to give me your mail

Posted: **Tue Jun 14, 2011 6:57 pm**

Yes, I guess there's no PM on this forum but here's my spam account. Just email me there and I'll reply with my real email. kshive % yahoo*com

Posted: **Tue Jun 14, 2011 7:08 pm**

did you try to use another VPN account
there is site named bestfreevpn i tried it's free vpn it works normally i don't know why ??
i don't know where is the error
i just want to hide my clients behind the VPN but i still i can't

Posted: **Sun Jul 03, 2011 8:46 pm**

Bump - Anyone have any ideas?

Posted: **Mon Jul 04, 2011 10:23 am**

I hope you do after last time we had a conversation. i still want to solve this problem. why no one from Mikrotikers help?

we have a big issue in VPN client in mikrotik, we connect from windows the VPN works normally but if we connect throw Mikrotik the VPN become very very slowly Why????

Please help in this case??

Posted: **Wed Jul 06, 2011 7:23 pm**

Still having problems with Mikrotik to Mikrotik VPN. I've tried to contact Mikrotik support directly with no response and the vendor I purchased the units from says they don't provide technical support on their products and that I should contact Mikrotik directly.

Is there a forum moderator that can assist with this? It seems like I'm not the only one that's having this issue.

Posted: **Thu Jul 07, 2011 10:41 am**

There can be many reasons.
If a lot of packet retransmits occur due to unstable link then you will get low bandwidth.
MTU is bigger than interfaces between both VPN ends can handle. Check with ping what is the maximum packet size that can be sent without fragmentation.

Posted: **Mon Jul 11, 2011 5:59 pm**

I really tried to check the mtu with the ping utility and reconfigured it depending the results but it does not solve the problem.

We really facing a problem please help in it. Not just me and the topic owner but there is more in the forum with no solution also.

Posted: **Wed Jan 11, 2012 5:10 pm**

I found solution for L2TP, see
http://ask.metafilter.com/153863/Why-is-my-VPN-so-slow

Posted: **Sat Jun 02, 2012 9:59 am**

there is no solution sstp gives me 7 Mbit over windows I get 20 Mbit, I have tweaked the MTU and the MRU and there is no gain that gets this to 20 Mbit, the fastest way to link up for me is creating a VPN appliance using a virtual machine to simply route my VPN internet via ICS to another ethernet port and distribute it via a switch,

I have the 751G with wireless router its a paperweight at this point

Posted: **Tue Jun 05, 2012 2:36 am**

apparently this issue also exits with openvpn over udp, the solution however on openvpn if you have access to your own server, would be to add

net.inet.ip.fastforwarding = 1 on the server side it does help a bit, but for servers you do not have access to such as pay vpn gateways this will not be an option.

If you have a 20Mbit or better connection the only way you will get this speed is via windows on ICS ( internet connection sharing) although ugly it offers speeds over two network interfaces on either l2tp or sstp at around 17-19Mbit and my application is netflix. The MikroTik RB/751G Indoor Gigabit Wireless Router simply does surpass 7Mbit on the rls 6 Beta 2 router OS ( tried previous versions no diff), no matter what you do, also I do not consider myself a novice at networking or using mikrotik routers.

I am using Vmplayer created a windows XP virtual machine with the lowest requirements 512MB ram 10GB HD and the most minimal XP install to create a virtual machine designed only to route traffic, it works!

Until I discover something faster this is the only solution to break the 7Mbit download speed limit,

Posted: **Wed Jun 13, 2012 3:24 am**

For the sake of information, changing the MTU to 1420 from 1460 upped our router-router PPTP connection speed from an average of 1.5 to 7mbit. This is between an 1100x2 and a 750G. The connection speeds are 25 on one end and 15 on the other, so this is better but still slower than what I would expect.

Posted: **Tue Jul 02, 2013 2:17 pm**

Hello,

Can someone tell me where exactly I should change the MTU and MRU (client/server, which interface etc.) and which values are the best for my connection?
I just have 10% of my Internet speed only through the L2TP/Ipsec connection (clean IPSEC is the same). Clean L2TP goes up to 4.5Mbps which is what I need through IPSEC too.
There's no significant load on CPUs ~5-40%.

Mikrotik Server's connection:
Internet - ADSL, with PPPoE through Ether1.
VPN - L2TP with Ipsec

1. Mikrotik LAN-to-LAN connection:
Internet - Ethernet on Ether1.
VPN - L2TP with Ipsec

2. Windows 7 Roadwarrior connection:
Internet - Ethernet or WiFi.
VPN - L2TP with Ipsec

Thank you,
T.P.

Posted: **Sat Oct 12, 2013 4:42 pm**

Same problem here. I have a 120/10 connection, and I can only using 12-13Mbps over it with NAT on L2TP /wo compression and encryption on my RB450G:

[oreggin@RB450G] > /interface monitor ether1
name: ether1
rx-packets-per-second: 2 020
rx-drops-per-second: 0
rx-errors-per-second: 0
rx-bits-per-second: 12.7Mbps
tx-packets-per-second: 605
tx-drops-per-second: 0
tx-errors-per-second: 0
tx-bits-per-second: 691.7kbps

[oreggin@RB450G] > /interface monitor l2tp
name: l2tp
rx-packets-per-second: 1 010
rx-drops-per-second: 0
rx-errors-per-second: 0
rx-bits-per-second: 11.8Mbps
tx-packets-per-second: 570
tx-drops-per-second: 0
tx-errors-per-second: 0
tx-bits-per-second: 341.8kbps

[oreggin@RB450G] > /system resource print
uptime: 23h7m39s
version: 6.4
build-time: Sep/12/2013 13:52:41
free-memory: 232.9MiB
total-memory: 256.0MiB
cpu: MIPS 24Kc V7.4
cpu-count: 1
cpu-frequency: 680MHz
cpu-load: 18%
free-hdd-space: 482.9MiB
total-hdd-space: 512.0MiB
write-sect-since-reboot: 505
write-sect-total: 2144719
bad-blocks: 0%
architecture-name: mipsbe
board-name: RB450G
platform: MikroTik

[oreggin@RB450G] > /interface l2tp-client export
# oct/12/2013 15:37:13 by RouterOS 6.4
# software id = XXXX-XXXX
#
/interface l2tp-client
add add-default-route=yes allow=pap connect-to=a.b.c.d disabled=no max-mru=1492 max-mtu=1492 name=l2tp password=xxx profile=default user=sb@sw.net

I would like to use the L2TP for primary internet connection at home. The MTU/MRU trick is ineffective. If I stop my torrent client then other FTP session is lagged but can continue transfer for some seconds later. The RB450G can use 120M speed over native connection or over GRE and NAT with 60% CPU. Only the L2TP is slow.

Posted: **Wed Jul 29, 2015 10:46 pm**

I found this topic and I would like to correct me. L2TP client MTU/MRU is 1460 if uplink MTU is 1500byte. This because L2TP uses UDP encapsulation (UDP port 1701). IPv4 + UDP header = 20+20 = 40 byte. 1500-40=1460.
With these options I can reach almost the maximum speed of the router capability @ 100% CPU.

Posted: **Fri Aug 21, 2015 2:07 pm**

Hello!
What is the maximum speed in VPN tunnels. I'm can't provide over 250 Mbps with different types of tunnels (pptp, gre, EoIP, IPoIP, etc).
Please, help me with VPN performance.

Posted: **Fri Aug 21, 2015 2:42 pm**

Depends on CPU speed and packet size.

Posted: **Mon Aug 24, 2015 7:50 am**

Depends on CPU speed and packet size.

I'm test with iperf on both sides with packet size 40 bytes

Posted: **Fri Feb 26, 2016 9:46 am**

i built up a test setup today ....

RB751 = server
RB750 = client

both connected via eth1<=>eth1 100MBit/s full duplex link
RB751 - eth1 = 10.11.0.1/30
RB750 - eth1 = 10.11.0.2/30

then i tested PPTP and OpenVPN Tunnel throu that link.

establishment and IP assigning ... no problems
RB751 - vpn - 10.22.2.1 (vpn server)
RB750 - vpn - 10.22.2.2 (vpn client)

BTest Results:

ETH to ETH (wo/ tunnel, bidirectional, UDP)

[admin@751_server] /tool> bandwidth-test direction=both protocol=udp 10.11.0.2
                status: running
              duration: 32s
            tx-current: 82.2Mbps
  tx-10-second-average: 86.3Mbps
      tx-total-average: 65.3Mbps
            rx-current: 97.5Mbps
  rx-10-second-average: 87.9Mbps
      rx-total-average: 72.9Mbps
          lost-packets: 7081
           random-data: no
             direction: both
               tx-size: 1500
               rx-size: 1500

4 TCP Streams, bidirectional:

[admin@751_server] /tool> bandwidth-test direction=both protocol=tcp tcp-connection-count=4 10.11.0.2
                status: running
              duration: 14s
            tx-current: 54.3Mbps
  tx-10-second-average: 54.9Mbps
      tx-total-average: 54.6Mbps
            rx-current: 54.5Mbps
  rx-10-second-average: 55.0Mbps
      rx-total-average: 55.1Mbps
           random-data: no
             direction: both

4 TCP streams, one way:

[admin@751_server] /tool> bandwidth-test direction=transmit protocol=tcp tcp-connection-count=4 10.11.0.2 
                status: running
              duration: 8s
            tx-current: 94.1Mbps
  tx-10-second-average: 90.8Mbps
      tx-total-average: 90.8Mbps
           random-data: no
             direction: transmit (quite similar result for "receive")

now the "funny" part throu the VPN.... to say beforehand, CPU load was at a average load between 70-82% (PPTP) and 87-92% (OpenVPN)

PPTP (just for measurement ... not a real live use any longer):

UDP, bidirectional

[admin@751_server] /tool> bandwidth-test direction=both protocol=udp 10.22.2.2                           
                status: running
              duration: 25s
            tx-current: 7.5Mbps
  tx-10-second-average: 9.0Mbps
      tx-total-average: 11.2Mbps
            rx-current: 51.5Mbps
  rx-10-second-average: 50.0Mbps
      rx-total-average: 37.9Mbps
          lost-packets: 395
           random-data: no
             direction: both
               tx-size: 1450
               rx-size: 1450

UDP transmit:

[admin@751_server] /tool> bandwidth-test direction=transmit  protocol=udp 10.22.2.2
                status: running
              duration: 15s
            tx-current: 55.8Mbps
  tx-10-second-average: 37.0Mbps
      tx-total-average: 28.5Mbps
           random-data: no
             direction: transmit
               tx-size: 1450

UDP receive:

[admin@751_server] /tool> bandwidth-test direction=receive   protocol=udp 10.22.2.2  
                status: running
              duration: 15s
            rx-current: 59.6Mbps
  rx-10-second-average: 58.1Mbps
      rx-total-average: 46.3Mbps
          lost-packets: 570
           random-data: no
             direction: receive
               rx-size: 1450

4 TCP Streams, bidirectional:

[admin@751_server] /tool> bandwidth-test direction=both protocol=tcp tcp-connection-count=4 10.22.2.2
                status: running
              duration: 10s
            tx-current: 18.1Mbps
  tx-10-second-average: 18.2Mbps
      tx-total-average: 18.2Mbps
            rx-current: 18.2Mbps
  rx-10-second-average: 18.3Mbps
      rx-total-average: 18.3Mbps
           random-data: no
             direction: both

4 TCP streams, transmit/receive:

admin@751_server] /tool> bandwidth-test direction=transmit protocol=tcp tcp-connection-count=4 10.22.2.2 
                status: running
              duration: 10s
            tx-current: 27.9Mbps
  tx-10-second-average: 18.7Mbps
      tx-total-average: 18.7Mbps
           random-data: no
             direction: transmit

[admin@751_server] /tool> bandwidth-test direction=receive protocol=tcp tcp-connection-count=4 10.22.2.2    
                status: running
              duration: 10s
            rx-current: 35.5Mbps
  rx-10-second-average: 33.6Mbps
      rx-total-average: 33.6Mbps
           random-data: no
             direction: receive

now, the in more practical VPN and daily use (for me at least) situation ... OpenVPN (SHA1/AES-256):

UDP, bidirectional / transmit / receive:

[admin@751_server] /tool> bandwidth-test direction=both protocol=udp 10.22.2.2                           
                status: running
              duration: 15s
            tx-current: 4.3Mbps
  tx-10-second-average: 2.4Mbps
      tx-total-average: 3.3Mbps
            rx-current: 14.8Mbps
  rx-10-second-average: 13.8Mbps
      rx-total-average: 13.2Mbps
          lost-packets: 582
           random-data: no
             direction: both
               tx-size: 1500
               rx-size: 1500

[admin@751_server] /tool> bandwidth-test direction=transmit protocol=udp 10.22.2.2 
                status: running
              duration: 8s
            tx-current: 17.5Mbps
  tx-10-second-average: 15.7Mbps
      tx-total-average: 15.7Mbps
           random-data: no
             direction: transmit
               tx-size: 1500

[admin@751_server] /tool> bandwidth-test direction=receive protocol=udp 10.22.2.2  
                status: running
              duration: 9s
            rx-current: 16.6Mbps
  rx-10-second-average: 14.3Mbps
      rx-total-average: 14.3Mbps
          lost-packets: 864
           random-data: no
             direction: receive
               rx-size: 1500

4TCP Streams; bidirect. / transmit / receive:

[admin@751_server] /tool> bandwidth-test direction=both protocol=tcp tcp-connection-count=4 10.22.2.2    
                status: running
              duration: 10s
            tx-current: 5.7Mbps
  tx-10-second-average: 5.3Mbps
      tx-total-average: 5.3Mbps
            rx-current: 5.4Mbps
  rx-10-second-average: 5.5Mbps
      rx-total-average: 5.5Mbps
           random-data: no
             direction: both

[admin@751_server] /tool> bandwidth-test direction=transmit protocol=tcp tcp-connection-count=4 10.22.2.2     
                status: running
              duration: 10s
            tx-current: 10.6Mbps
  tx-10-second-average: 10.7Mbps
      tx-total-average: 10.7Mbps
           random-data: no
             direction: transmit

[admin@751_server] /tool> bandwidth-test direction=receive protocol=tcp tcp-connection-count=4 10.22.2.2  
                status: running
              duration: 10s
            rx-current: 11.5Mbps
  rx-10-second-average: 11.7Mbps
      rx-total-average: 11.7Mbps
           random-data: no
             direction: receive

Posted: **Fri Feb 26, 2016 9:51 am**

how can it be that VPN connections are that much slowed down?
i also get similar results when i made the BTest with a CRS109-8G-1S-2HnD-IN as VPN Server.....

Posted: **Tue Jul 05, 2016 6:18 pm**

I found this comparison chart: read halfway down the page how much bandwidth is lost Unbelievable!!!!!!!!!!

http://rickfreyconsulting.com/mikrotik-vpns/

reliable?

Posted: **Tue Jul 05, 2016 6:40 pm**

There is something wrong with those tests.

You will never get 667Mbps on CRS with ipsec tunnel with "highest encryption method". ~24Mbps is good result for this mips CPU with AES eencryption.
If you get 70%+ loss on Gre, IPIP, EoIP, PPTP, PPPOE tunnels, there is something seriously wrong with your test setup.

Posted: **Tue Jul 05, 2016 6:58 pm**

(sorry for my english but I use google translator)

So I do not know where it can be the cause of the problem. I have a IPSec tunnel between two mikrotik (RB3011UiAS) and the data transfer speed between the two locations is very fast, (virtually that of the rated bandwidth of the connection).
Whereas a data transfer of a OVPN tunnel from my mikrotik and another one have a bandwidth limited to 355KB / Sec, I also tried it with "chiper null" setup but the speed is as if it were self-limited!

The CPU usage is very low on both Mikrotik... bhu!!!

Posted: **Wed Jul 06, 2016 9:53 am**

I have pretty much similar problem with vpn. Bandwidth test between mikrotiks shows great speed, but when it comes to speed between 2 devices behind each of mikrotik - speed drops drastically. Emils from support was on this problem, did nothing, made couple strange suggestions and then promised to look one more time and disappeared for over a month now. Support ingores all follow letters, meanwhile we're suffering from low vpn speed and noone can help even with a hint on my config. That's another end of 160 employees company I think. VPN speed wont go higher than 20 mbps, when real speed between routers is greater then 60 mbps even with encryption.
[Ticket#2016052266000207]

Posted: **Wed Jul 06, 2016 11:32 am**

I have pretty much similar problem with vpn. Bandwidth test between mikrotiks shows great speed, but when it comes to speed between 2 devices behind each of mikrotik - speed drops drastically. Emils from support was on this problem, did nothing, made couple strange suggestions and then promised to look one more time and disappeared for over a month now. Support ingores all follow letters, meanwhile we're suffering from low vpn speed and noone can help even with a hint on my config. That's another end of 160 employees company I think. VPN speed wont go higher than 20 mbps, when real speed between routers is greater then 60 mbps even with encryption.
[Ticket#2016052266000207]

20 Mbps to 60 Mbps is 1/3 of the total speed of the connection

if my OVPN connection was so fast I would be very happy!!
Also, I noticed an interesting thing:
Without traffic on OVPN tunnel, out of a total of 50 PING the average time is 7ms. Good.
The same test carried out during a data transfer, on a total of 50 PING is the average of the time of 260ms!!

(sometimes loses some package)
This situation with IPSec tunnel does not happen! The PING response time does not change (or at least very little change) if the tunnel is busy or not.

Posted: **Wed Jul 06, 2016 11:35 am**

This situation with IPSec tunnel does not happen! The PING response time does not change (or at least very little change) if the tunnel is busy or not.

This is a common problem related to TCP meltdown. You shouldn't use TCP tunnels on a long distance nor many hops. Use L2TP or PPTP for it. We're all waiting ROS7 for OVPN UDP support.

Posted: **Wed Jul 06, 2016 5:43 pm**

Can you post your VPN config output. I use pptp and l2tp and can consistently push 50M+ with no issue.

Does your server have enough bandwidth to handle the tx/rx of your speed test? How far is the server from the location and what server are you running a speed test to?

Are you running the test via bandwidth test, or a website like speedtest.net?

Posted: **Thu Jul 07, 2016 12:35 am**

Can you post your VPN config output. I use pptp and l2tp and can consistently push 50M+ with no issue.

Does your server have enough bandwidth to handle the tx/rx of your speed test? How far is the server from the location and what server are you running a speed test to?

Are you running the test via bandwidth test, or a website like speedtest.net?

I believe that the correct answer was written by DJGlooM.
Today I did some tests before using PPTP tunnel and then L2TP, the data transfer speed was great and also the PING response time. The low speed problem is only with OVPN tunnels.
Unfortunately Router OS 6.X does not support UDP on OVPN tunnels, but only TCP.
I have internet access in 100 Mbit optical fiber in both companies, this is why I am sure that the line is not a problem.
Tomorrow I'll try to setup an IPSec tunnel, I am sure that this type of VPN is very fast because I already tried on two other companies.
The only doubt I have is that the second company I have only one public IP available and I do not know if you can use an IP for the IPSec tunnel and the same IP to get out the traffic on the internet without tunnel.
Bha! Tomorrow the answer

Posted: **Fri Jul 08, 2016 3:12 am**

Can you post your VPN config output. I use pptp and l2tp and can consistently push 50M+ with no issue.

Does your server have enough bandwidth to handle the tx/rx of your speed test? How far is the server from the location and what server are you running a speed test to?

Are you running the test via bandwidth test, or a website like speedtest.net?
I believe that the correct answer was written by DJGlooM.
Today I did some tests before using PPTP tunnel and then L2TP, the data transfer speed was great and also the PING response time. The low speed problem is only with OVPN tunnels.
Unfortunately Router OS 6.X does not support UDP on OVPN tunnels, but only TCP.
I have internet access in 100 Mbit optical fiber in both companies, this is why I am sure that the line is not a problem.
Tomorrow I'll try to setup an IPSec tunnel, I am sure that this type of VPN is very fast because I already tried on two other companies.
The only doubt I have is that the second company I have only one public IP available and I do not know if you can use an IP for the IPSec tunnel and the same IP to get out the traffic on the internet without tunnel.
Bha! Tomorrow the answer

If you're interested in maximizing throughput, I recommend using L2TP without IPsec. Of course this isn't secure, but it requires the least overhead in regards to packet overhead. On that subject, you may want to verify your path MTU to make sure you aren't trying to use a VPN tunnel with an MTU size that exceeds the capacity of the connection.
If you have a public IP on both devices, you can just set up an EoIP tunnel to make a layer 3 tunnel. The most bandwidth I have seen pushed over a VPN tunnel in mikrotik has been over EoIP.

Posted: **Fri Jul 08, 2016 4:00 am**

If you have a public IP on both devices, you can just set up an EoIP tunnel to make a layer 3 tunnel. The most bandwidth I have seen pushed over a VPN tunnel in mikrotik has been over EoIP.

EoIP is layer 2 tunnel, also EoIP is GRE, so instead of using it in layer 3 you can use pure GRE tunneling. And yes, GRE slightly faster, than L2TP because overhead is lesser and I think GRE packets are routed faster than UDP packets.

Posted: **Mon Jul 18, 2016 5:43 pm**

Hello, we have three CCRs
1009-8G-1S-1S+
1009-8G-1S
1016-12G-1S
Those connected via GRE tunnels over IPsec transport with the same settings. (Md5 aes-128-cbc).

Link between 1016-12G-1S and 1009-8G-1S is 50 Mb/s and we use almost full its bandwidth (SMB)
Link between 1016-12G-1S and 1009-8G-1S-1S+ is 100Mb/s but we have only less then 10Mb/s in that tunnel! The same picture in tunnel between 1009-8G-1S-1S+ and 1009-8G-1S.

Then encryption is disabled GRE tunnels utilize full bandwidth.
Is it a misconfiguration of CCR1009-8G-1S-1S+ or some bugs in CCR’s IPSec algorithm?

Posted: **Mon Jul 18, 2016 5:59 pm**

Support told me there could be IPSec problem which they struggling with, Try to create Simple Queue for IPSec after marking it in mangles, then processing will be put to 1 core and performance should increase. Also check your MTU values.

Posted: **Mon Jul 18, 2016 9:03 pm**

1. Do you use last RouterOS version on all routers? If not - try use Camelia-128 instead AES-128. Reason - AES uses hardware acceleration. Camelia - software. Sounds like joke but for a long time hardware acceleration was slower than software one in CCRs. In last versions it seems to be fixed (I use GRE+IPSEC with AES-256 on 100M channels - bandwidth tools show ~70-80Mbits inside channel, 20 TCP connections).
2. How did you measure connection speed?

Posted: **Mon Jul 25, 2016 12:00 pm**

All CCRs are 6.35.4
All GREs are Clamp TCP MSS
And yes, chahging to camellia-128 somewhat improves SMB speed (just copying big files) betweeen sites up to 4.5MB/s on 100Mbs connections on both sides.

Posted: **Mon Jul 25, 2016 12:10 pm**

Copying big files with SMB over a WAN connection is normally not the best way to get high trhroughput...
You can test using a plain IP tunnel or GRE tunnel without IPsec and see if that is working much better.
The "problem" in the accelerated encryption on the CCR appears to be re-ordering of the packets.
However, that means that the end systems also get part of the blame, as re-ordered packets are part of
the spec of IP, and so the end systems are supposed to handle them without so much effect on performance.

For better performance, try:
- a protocol that uses a TCP connection to transfer the entire file without sending requests back and forth
(FTP, HTTP, RSYNC)
- an end system with a different operating system with hopefully better TCP implementation

Posted: **Thu Jul 28, 2016 10:34 am**

Yes, it is much better without encription. Systems are Windwos 7, 8.1, 10 and we need tunnels mostly for SMB. (GRE for BGP)

Posted: **Thu Feb 25, 2021 4:45 pm**

For some reason, my SSTP connection was slow unless I either TORCHED the connection or enabled a QUEUE TREE on the interface (even though nothing goes through the queue tree, apparently). Without that in place, my RDP screen updates were quite a bit slower, and file transfers (~20 MB) via RDP were painfully slow. This was with up-to-date router OS as of March 2021 (v6.47.9).

The solution that helped me and I hope may be helpful to others is to script creation of a QUEUE TREE for each PPP VPN connection at the time it is established. You also have to kill it when disconnecting, so that it can be re-established next connection. Support indicated this may be a helpful technique because, "forces the traffic to be handled by a single core." I don't know if that is the case or not. To me -- without the queue tree or torch -- I felt like packets were getting delayed or lost, or that throughput was choked-down for no reason. With the queue tree or torch, packets clearly flow and are delivered efficiently. This worked for my SSTP connection, but I think I read that others had noticed torching other types of VPNs improved performance. So, I recommend giving this a try for L2TP, etc...

In PPP -> PROFILE -> SCRIPTS -> ON UP, I have:
--------------------------------------------------------------------------------------------------------------------------
local interfaceName
set interfaceName [/interface get $interface name]

/queue tree add name="$interfaceName" parent="$interfaceName" priority=1 queue=default

In PPP -> PROFILE -> SCRIPTS -> ON DOWN, I have:
--------------------------------------------------------------------------------------------------------------------------
:local ppp ("<sstp-$user>");
[/queue tree remove $ppp];

I realize that the UP and DOWN methods are a little inconsistent, but I wasn't going to fix "what ain't broke".

Posted: **Thu Feb 25, 2021 7:07 pm**

For some reason, my SSTP connection was slow unless I either TORCHED the connection or enabled a QUEUE TREE on the interface (even though nothing goes through the queue tree, apparently).

That means you are using "fasttrack" in a situation where it cannot be used.
(fasttrack is enabled by default, but still you need to understand its limitations)

Posted: **Thu Feb 25, 2021 7:43 pm**

That means you are using "fasttrack" in a situation where it cannot be used.

Are you sure that adding a /queue tree item prevents the packets handled by the queue from getting fasttracked? Yes, sniffing does disable fasttracking, maybe torching does as well, but adding a queue?

Plus there is no policy matching in SSTP like in IPsec, so fasttracking cannot prevent packets from getting to the tunnel. So I'd buy the explanation of support that the improvement comes from having all packets of that SSTP connection handled by the same CPU core, but how can torching cause the same?

Posted: **Thu Feb 25, 2021 9:24 pm**

Are you sure that adding a /queue tree item prevents the packets handled by the queue from getting fasttracked? Yes, sniffing does disable fasttracking, maybe torching does as well, but adding a queue?

You are right, adding a queue tree to an interface (vs a global queue tree) should not disable fasttrack.
Well, first thing I do when receiving a router is always to disable fasttrack and fastpath so I have not so much experience with these issues...

Posted: **Sun Feb 28, 2021 1:06 am**

Thanks for your quick responses. I am fairly settled with my solution, but I am willing to continue exploring this problem for the benefit of everyone's understanding (including my own, of course).

When I first dug into this, I saw that Fastrack could be a source of such symptoms. I therefore researched how to disable it, but it is either not active on my router, or I did not understand what the instructions were telling me to do. Please tell me specifically what to check, and I will do it. Assuming it is on and I can disable it, I will then retest my connection without the Queue Tree in place.

Posted: **Sun Feb 28, 2021 8:18 am**

To disable fasttracking, it is enough to disable (or remove) a firewall rule action=fasttrack-connection ... in chain forward of /ip firewall filter (or all such rules in the unlikely case that you've got more than one).

If a packet matches this rule, fasttracking of the connection the packet is a part of gets activated, and the connection remains fasttracked until it ends for natural reasons. Hence test the effect of removal/disabling of that rule using newly created connections.

Posted: **Mon Mar 01, 2021 3:36 pm**

Yeah, I don't see anything in my IP Firewall Filter rules that has "Fasttrack" in it. I put this unit in a long time ago, so either I disabled it for some reason at that time, or perhaps the factory configuration pre-dated Fasttrack. I think it is safe to conclude that the VPN slowness I experience is not related to Fasttrack, but that torching or adding a Queue Tree resolves the issue. Performance may be improved because one CPU is used to handle all the traffic, or perhaps it is something else -- nobody knows at this point. I'd love it if MT would look into this, because I'll bet that a lot of folks suffer from poor VPN performance unnecessarily. I'll bet that the root cause could be identified and fixed in upcoming firmware without need for someone going through what I did to find this queue tree workaround (which, I'll bet, most people won't do -- they'll probably just continue to suffer, or conclude that it isn't the right solution).

Speaking of the workaround, I went ahead and updated my ON UP and ON DOWN scripts, because the ones I posted above weren't just inconsistent, but they also resulted in inconsistent Queue names that were then not closed-out properly on disconnect. So, here are the PPP scripts that I am using now:

ON UP
----------
:local ppp ("<sstp-$user>");
[/queue tree add name="$ppp" parent="$ppp" priority=1 queue=default];

ON DOWN
---------------
:local ppp ("<sstp-$user>");
[/queue tree remove $ppp];

I would also tick the "yes" radio button under the "Only One" option in PPP-> PROFILE -> LIMITS. My understanding is that this workaround -- the way that I've got it scripted -- is only going to be compatible with one active connection at a time PER USER.

Posted: **Mon Mar 01, 2021 5:37 pm**

I would also tick the "yes" radio button under the "Only One" option in PPP-> PROFILE -> LIMITS. My understanding is that this workaround -- the way that I've got it scripted -- is only going to be compatible with one active connection at a time PER USER.

Yes, the generated name of the interface differs if the second connection from the same user gets established.It will be <sstp-user-1> etc., so the way you create the interface and queue names, you'd be creating another queue with the same name, which would obviously fail. And if the additional connection would go down first, you would remove the queue for the surviving connection, also not good.

A way out could be to use the $interface variable (which holds the id of the interface being processed, not its name), to retrieve its actual name (see this very useful post by @Pada), but you have to try whether the $interface value is available also to the on-down script.

Posted: **Mon Mar 01, 2021 8:48 pm**

Thanks, Sindy. I believe I tried the $interface variable first, and found that it was not available in ON DOWN. I am pretty sure that is what brought me to the solution that I have now.

MikroTik

Slow VPN tunnels (SSL, PPTP, L2TP)

Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)

Re: Slow VPN tunnels (SSL, PPTP, L2TP)