This is a call for help. I am having headaches with OpenVPN client-server thoroughput on MikroTik’s baby RB750. Client->server traffic is like ~13KB/s maximum and server->client ~25KB/s maximum. The usual sustained speeds are at about half of the max figures. In a word, beyond horrible. All aspects of vpn connection are tolerable, except the speed.
Being relatively new to RouterOS world I am struggling to figure out what may be causing the problem.
Status:
→ Configuration based on MikroTik Wiki recommendation, TAP method in use (have tried TUN mode briefly but wasn’t any better performance wise)
→ Server is managed fully by RouterOS
→ Clients are OpenVPN installation v2.1.1 (older been tested too) on Windows (XP, Vista, 7)
→ LAN segment is 192.168.2.0/24, VPN segment is 192.168.3.0/24, bridged
→ No packet loss occure in VPN communication
→ Went through RouterOS 4.0 to 4.4 upgrades, problem remains
→ CPU load is low during VPN sessions (CPU is not the bottleneck here)
Here’s an interesting observation:
VPN connections initiated from LAN do perform nicely and the thoroughput is limited purely by CPU, thus ~3MB/s at average depending on encryption method used. VPN connection initiated from WAN are crippled as stated above.
Changing encryption method doesn’t solve the problem (blowfish, aes, no encryption, …).
Changing MTU in server and client configs doesn’t solve the problem.
Switching SRC NAT off (to rule out possible interference) doesn’t solve the problem.
No useful information is noted in client and server logs.
Would you recommend trying downgrade to v3, does it worth the hassle?
This is just a brief description, I may post further configuration details later.
Is your WAN connection stable? When you have heavy packet loss on the WAN connection, you would see a huge drop in OVPN’s throughput!
I had a similar issue when my WiFi link was unstable.
I’m not sure if it could be something related to OpenVPN, since you can get a nice 3MB/s throughput when connecting from the LAN. You could always try to send & receive stuff via FTP and see if you also get such bad throughput. sergejs’s suggestion for running a comparison of PPTP vs OpenVPN would be better
Are these TCP connections over the VPN? OpenVPN in RouterOS is utterly useless as it uses TCP. The effects are more pronouced over the WAN connection probably due to increased latency and the TCP retransmission algorithm coming into play. OpenVPN’s preferred protocol is UDP, which RouterOS for some reason does not support and is mute about the subject.
So in short you’ll need to use PPTP or IPsec if you want to continue to use RouterOS for VPN connectivity.
No, I don’t have Queues configured yet. So far the configuration of RB750 is rather trivial (SRC NAT, OpenVPN and about 20 simple DST NAT rules), with only WAN and LAN master ports active. I have even reverted settings to factory default and set up everything from scratch again.
The internet connection is stable, no abnormal packet loss occures on WAN. I have measured thoroughput using FTP connection, thus TCP traffic only. At any time of day and under any load the VPN traffic is capped at those funny xxKB/s figures. The same applies to scenario with Bridge OFF and FTP connection to MikroTik inbuilt FTP over VPN. Non-VPN traffic runs fast and smooth.
Yes, I might try other inbuilt VPN solutions but had best hopes for OpenVPN for several reasons. PPTP is rather outdated and often cannot be used because of NAT unfriendly GRE packets (no go for clients except dialup and adsl). L2TP relies on numerous TCP and UDP ports being open (no go for road warriors). SSTP not (yet) supported by MTK. Both PPTP and L2TP on Windows connects via horrible MS client that interferes with default gateway setting (no go for anyone used to anything better than MS VPN client). God bless KerioVPN, I was enormously satisfied with that and expected MTK OpenVPN to follow the trend. Any chance of having KerioVPN server ported to MTK one day?
At this point I am tempted to downgrade to RouterOS 3.30 and try again.
Now this is interesting finding. OpenVPN relations connected over internet are SLOW as desribed. But OpenVPN relations connected from the very same WAN port directly inhouse are FAST!
Knowing these it points on a kind of packet shaping at my local ISP that hampers OpenVPN traffic specifically. Sounds silly but could be.
There is a slim, but very remote chance that’s the problem. The problem is most likely TCP over TCP as I described before. Try doing a bandwidth test through the OpenVPN tunnel using UDP. That will answer your question.
I had tried to change OpenVPN ports and it didn’t have any effect. So either ISP is using packet inspection to set traffic priorities (they do something like that for sure) or OpenVPN over TCP implementation is not good as someone above indicated. There are VPN solutions that rely on TCP and perform nicely, so it can’t be global problem.
Which VPN solutions use tcp for traffic transport? I can’t really think of any off the top of my head. PPTP uses TCP for setting up the connection, but GRE is used for transport.
Did you try a udp bandwidth through the openvpn tunnel?
Which VPN solutions use tcp for traffic transport?
Proprietary KerioVPN and a new SSTP by Microsoft. These are two I am aware of. I am actually attempting to make a replacement for Kerio which did a great job for me over the period of 5 years (albeit being based on TCP only, hmm…).
Did you try a udp bandwidth through the openvpn tunnel?
No not yet. First need to pick up suitable tools for taking the measurement as my normal tasks evolve exclusively around TCP traffic.
TBH I am reluctant to accept that MTK would integrate and market a VPN solution (or a feature stripped incarnation of it) with their product if it would be completely useless at global scale. And 13KB/s is really not that much better than useless in 2010. I would be fine with getting VPN to operate at ~50% of my real internet connection capacity, due to overhead. 13KB/s is pathetic, considering my traffic isn’t traveling around the globe, quite contrary, the latency is low (<3ms) and packet loss minimal (or none) due to both VPN end points are situated within eye sight distance of one city.
Still, I am anxious to hear how my local ISP will react to inquiry. They are first to blame
Guess what. My ISP adjusted their QoS and that solved the thoroughput problem. Hurrah Well it’s still far from being very fast, but quite tolerable (~110KB/s download at 3mbit client line with some other usual traffic running).
Are they rate limiting just your OpenVPN connections? Who is your ISP if you don’t mind me asking.. Sounds like some shady practices.
I’m not too familiar with SSTP, but Kerio uses udp for transport and tcp for the control channel. I’m anxious to see a udp bandwidth test. You can use Mikrotik’s bandwidth test utility, it supports both tcp and udp.
No idea tbh. Have never experienced such massive regulation with them except OVPN by now. It’s a small local ISP you’ve never heard of (wms.cz) anyway.
Ah I stand corrected - haven’t realized it actually makes use of UDP. My bad.
What a handy util you’ve pointed me on, cool
Ok, top speeds are same(ish) for both TCP and UDP methods. Reaching 1000kbps on my (crappy) end point. Stability clearly being strong aspect of UDP.
Direction:receive
UDP: sustained speed close to max (MTK-CPU <30%, drops down to 3% now and then)
TCP: a lot of speed fluctuation and spikes, 368kbits to 1000kbits (MTK-CPU =100% {!!!} regardless encryption algo used) Direction:send
UDP: 200kbps to 800kbps (MTK-CPU <15%)
TCP: 130kbps to 800kbps (MTK-CPU <15%)
Having kind of the same problem with RB750Gr3 6.42.1, i can get a max speed of 12mbps using BF-CBC and MD5 if i change to aes-256-cbc and SHA1 it’ll go down to 6-7mbps even when copying from hosts in my own LAN connected either from inside or outside the network, internet is stable and idle during tests FTTH 300/300, hopefully it will be fixed some day in a future update.
