VPN is fast, but Internet traffic is slow

Hello

I created VPN between two Mikrotik routers. Overall connection is pretty fast between routers and between computers in different networks (I added routes in both routers to pass traffic between local network and remote network through vpn interface).

Then I added in one of the routers a route:
destination: 0.0.0.0/0
gateway: vpn-interface
routing mark: everything coming from local network
Idea is that I want to connect one of the networks to Internet over VPN.

So far so good. I mean, it works. I don’t say it’s a valid way of doing things! :slight_smile:

Now I have problem however. Client network connects to Internet over VPN, but connection speed is terrible. Like I get 0.3Mbit download, and upload often fails in speed tests. Direct traffic between networks over VPN is closer to 10-20Mbit.

I tried different things and nothing helps really. However by accident I discovered that if on the server side I start “/tool torch”, immediately Internet traffic over VPN speeds up and I get results closer to 10-20Mbit I would expect. When I disable torch application, traffic speed becomes terrible again.

I tried both pptp and l2tp ipsec, to check if they behave in any way different. Starting torch on client side doesn’t have any impact as well. I just wonder why torch application helps to resolve my issue…

Regards,
Krzysztof

When traffic is slow, does Tools > Profile show any processes with high CPU?

When Torch is disabled and I start speed test, CPU is about 5-10%. Traffic is extremely slow, some pages don’t even open.
When Torch is enabled in the same scenario, I get pretty decent speed and CPU is 65-90%.
When I disable Torch, traffic is slow again, and CPU drops to 5%.

Internet traffic is slow in both ways. If I route all Internet traffic via VPN from server to client, it behaves in exactly the same way. Starting Torch on server speeds up Internet traffic in both ways.

btw: Both routers have v6.39.2

btw: I was not able to send this message routing Internet via VPN without starting Torch :slight_smile:

I found someone having similar issue like me (Torch improves speed):
https://wiki.mikrotik.net/viewtopic.php?f=2&t=121421

There are similar things we both try to do, and also according to this person, issue may be related to v6.39 and v6.39.1. I have v6.39.2.

not sure if important, but my both routers are 2011UiAS-2HnD

Link I pasted above mentioned something about fast-track. Indeed, when I disabled fast-track, Internet speed improved.

I consider it semi-solved then. I mean, it works now, but does anybody know why? Can I keep fast-track and use VPN? Or prevent fast-track to affect VPN traffic?

I’m not really good with routers, and overall fast-track thing is out of scope of my expertise. :slight_smile: It would be nice to somehow prevent fast-track of packets going via VPN - maybe it would help. Not sure if it is related, but I have only one NAT per router - eth1 interface with WAN. I saw some examples when people were setting NAT for VPN as well. I think I tried to set NAT on VPN interfaces, but it didn’t help.

I did further investigation… I tried GRE and GRE with IPSec. Both fail to transport Internet over tunnel quickly. If I remember correctly, I also tried IPSec on its own, and it also didn’t work well. Only solution for me is to switch off fast-track. Effect is immediate and Internet is routed very quickly.

Just in case someone is having issue like me, in order to switch off fast-track, you need to disable a firewall rule with chain=forward and action=fasttrack connection.

I have maybe similar issue. 750Gr3, 6.39.2. IKEv2 IPsec. NAT. No fasttack firewall rules. OS X 10.12.6 native client. Connection is established normally, after some load, f.e. with speedtest.net from client, traffic stops completely (but OS X client continues to show that VPN is active). Only reconnect helps.

Seems that something wrong in IPsec. Locally connected clients does not experience any problems.

In the 6.39.x release there is an issue with fast track and dynamic MAC on interfaces. I had this issue and this was resolved by adding forced MAC to my bonded interfaces. My guess is you are suffering from something similar on VPN interfaces.
6.40rc has a fix for this and MT said this fix should be added to 6.39.3 once released.

Test upgrading to 6.40 which should solve this

What’s new in v6.40 (2017-Jul-21 08:45):
*) fasttrack - fixed fasttrack over interfaces with dynamic MAC address;

Make sure you activate your fasttrack again after the upgrade :slight_smile: