Hello everyone
My problem is with VPN speed when I config it on the MikroTik router (RB4011IGS+5HacQ2HnD-IN) as the client the speed drop drastically compare to when I connect to the same VPN server on the windows, on both I use PPTP.
I think the problem is with the MikroTik mac address because here IPSs are very restricted about people using VPN on their connections so maybe they got a way to detect the device type by mac address and limit the traffic if they connect to the VPN with those devices. I had this issue somewhere else in the city but in that place, we had internet with ADSL so by configuring the modem on the bridge mode and crease the PPPoE on the router and then route the traffic through VPN (the same server also PPTP as well) and problem solved. but since here the ISP gives you a preconfigured ZLT P19H modem and all of the settings are locked (plus I'm not sure if the modem has bridge mode or not) so can't do the same thing here. that's why I was thinking about changing the mac address of the router to see if it fixes the problem since with a simple google search you can see the mac address is belongs to a MikroTik router.
or maybe you guys got other solutions which I will appreciate if you tell me
speedtest of VPN PPTP on the windows speedtest of VPN PPTP on the router

They do not check device, but ttl time, see other topic already open about that.
If you use the pc, you are directly connected, and is ok,
But if you put between the router, the ttl is decreased by one (device) and the provider understand than you share the connection.

They do not check device, but ttl time, see other topic already open about that.
If you use the pc, you are directly connected, and is ok,
But if you put between the router, the ttl is decreased by one (device) and the provider understand than you share the connection.

Oh is that so, Thank you for your reply.
I searched the forum didn't find a topic about it can you be so kind and send those topic's links to me?

I change the TTL but no difference. I tried different numbers and test with those but all same thing, not sure my configuration is right though.

https://wiki.mikrotik.com/wiki/Manual:I ... throttling

Ping result without VPN: Reply from 1.1.1.1: bytes=32 time=114ms TTL=52
Ping result with VPN on PC: Reply from 1.1.1.1: bytes=32 time=123ms TTL=56
Ping result with VPN on router: Reply from 1.1.1.1: bytes=32 time=125ms TTL=55

When you say "VPN on the PC" vs. "VPN on the router", does that really mean only where you run the VPN client, or do you also connect the PC directly to the ISP's modem (excluding the 4011 from the path)?

@rextended

you saying (MT wiki) that if we change the TTL on the LTI we would be able to get more bandwidth, why is that?
Cant find any logical explanation

hi,

what @rextended trying to say most ISP capped your connection if they determined you put a router in between by observing the TTL and decremented by 1 and triggered them to reduced your bandwidth, since you try to reset the TTL to 65 the ISP shouldn't notice you put a router and in theory should not capped your connection, in this case this could be something else and i don't think this is a port negotiation mismatch issue on your Ethernet port towards the WAN interface, could you check if this is the case there's no harm in trying

@nichky,

if we change the TTL on the LTI we would be able to get more bandwidth, why is that?
Cant find any logical explanation

the logic behind is that mobile operators want to discourage subscribers from using LTE to connect whole networks, assuming that networks generate more traffic than individual phones. So the ISPs offer specific (more expensive) tariff plans for connection of networks. And by the TTL value they distinguish packets sent by the mobile phone itself from packets sent by devices connected to the phone externally.

When you say "VPN on the PC" vs. "VPN on the router", does that really mean only where you run the VPN client, or do you also connect the PC directly to the ISP's modem (excluding the 4011 from the path)?

No it's just VPN client on windows. the PC is always connect to the rb4011.

hi,

what @rextended trying to say most ISP capped your connection if they determined you put a router in between by observing the TTL and decremented by 1 and triggered them to reduced your bandwidth, since you try to reset the TTL to 65 the ISP shouldn't notice you put a router and in theory should not capped your connection, in this case this could be something else and i don't think this is a port negotiation mismatch issue on your Ethernet port towards the WAN interface, could you check if this is the case there's no harm in trying

Hey man
Thanks for your reply, how exactly can I test this? as you can see I'm pretty new to MicroTik and also a network beginner

Given the awful upload performance, are you sure you have MTU / MSS set properly?

Given the awful upload performance, are you sure you have MTU / MSS set properly?

The ISP given maximum upload speed is 8Mbps

My internet connection is: 40Mbps download - 8Mbps upload

No it's just VPN client on windows. the PC is always connect to the rb4011.

If so, the MAC address of the 4011 plays no role in the VPN throughput, because the VPN provider can never see a MAC address, whereas the ISP can always see the MAC address of the 4011's WAN, no matter where the VPN client is running.

2 ms difference on 123 ms of ping round-trip time is nothing, so I would assume the issue to be caused by the PPTP transport packets getting fragmented and many of the fragments to get lost. The thing is that the VPN client on the PC advertises a small enough MTU on the payload interface so that fragmentation wouldn't happen, whereas the PPTP client on the Mikrotik may advertise a too high MTU on the payload interface, resulting in the PC sending 1500-byte packets as per the Ethernet MTU, and the 4011 passing them on fragmented, and a good deal of the small second fragments getting lost on the path between the 4011 and the VPN server. Post the text export of the Mikrotik configuration, following the mini-howto in my automatic signature below.

Also it's worth mentioning that sometimes the speed with VPN on the PC or phone got also slow to about 13Mbps but without VPN it's more than 40Mbps.
but it's just sometimes and I'm sure it's not about VPN server bandwidth cause it's 10Gbps and the 1Mbps speed I got when I have the VPN on the router is not even close to 13Mbps.
Something else I notice is that in those sometimes speed down (when using VPN (no difference on the device type)) I still have full upload bandwidth (it's 8Mbps MAX) but when I have the VPN on the router I got no upload bandwidth.

No it's just VPN client on windows. the PC is always connect to the rb4011.

If so, the MAC address of the 4011 plays no role in the VPN throughput, because the VPN provider can never see a MAC address, whereas the ISP can always see the MAC address of the 4011's WAN, no matter where the VPN client is running.

2 ms difference on 123 ms of ping round-trip time is nothing, so I would assume the issue to be caused by the PPTP transport packets getting fragmented and many of the fragments to get lost. The thing is that the VPN client on the PC advertises a small enough MTU on the payload interface so that fragmentation wouldn't happen, whereas the PPTP client on the Mikrotik may advertise a too high MTU on the payload interface, resulting in the PC sending 1500-byte packets as per the Ethernet MTU, and the 4011 passing them on fragmented, and a good deal of the small second fragments getting lost on the path between the 4011 and the VPN server. Post the text export of the Mikrotik configuration, following the mini-howto in my automatic signature below.

Thank you very much for your reply.
here you go:

Is there a way to completely cover the VPN so ISP never understand I'm using one?

Is there a way to completely cover the VPN so ISP never understand I'm using one?

Definitely not with PPTP, whose encryption is so weak that it actually hides nothing; IPsec or something-over-IPsec is also obvious, so you'd have to use an SSTP VPN which looks like a normal HTTPS session, except that the packet sizes and traffic patterns may be unusual, plus SSTP has some drawbacks for the user (speed being one of the first ones to bother you). So no, no way to hide the fact that you are using a VPN from someone really determined to find out.

To your speed issue - the default max-mtu and max-mru settings of PPTP client interface, 1450 bytes, assume that the PPTP transport packets will be sent over an Ethernet interface with MTU of 1500 bytes. However, your WAN interface is a PPPoE one, which means a MTU of 1480 bytes or smaller, hence reducing the max-mtu and max-mru values in /interface pptp-client to 1400 might do the trick. If it doesn't, try to add the following firewall rules:

/ip firewall mangle add chain=forward in-interface=pptp-out1 protocol=tcp tcp-flags=syn action=change-mss new-mss=1300
/ip firewall mangle add chain=forward out-interface=pptp-out1 protocol=tcp tcp-flags=syn action=change-mss new-mss=1300

With L2TP/IPsec, the issue is one step more complicated as the PPP transport packets are encapsulated into UDP rather than GRE, and the UDP ones are encapsulated into ESP, which may be encapsulated into UDP again. So even more overhead, and thus you need to reduce the max-mtu and max-mru even more to prevent fragmentation.

Is there a way to completely cover the VPN so ISP never understand I'm using one?

your WAN interface is a PPPoE one

No that PPPOE is disabled and it was for ADSL from past, right now the wan is just a Ethernet cable to port 10 of the rb4011 and no need any configuration. also about L2TP it's disabled as well I use only PPTP

OK, so try just the mangle rules.

Is there a way to completely cover the VPN so ISP never understand I'm using one?

To your speed issue - the default max-mtu and max-mru settings of PPTP client interface, 1450 bytes, assume that the PPTP transport packets will be sent over an Ethernet interface with MTU of 1500 bytes. However, your WAN interface is a PPPoE one, which means a MTU of 1480 bytes or smaller, hence reducing the max-mtu and max-mru values in /interface pptp-client to 1400 might do the trick.

I changed them to 1400 and still the same

OK, so try just the mangle rules.

After I add those it's still the same

Grrr... I forgot the obvious... disable the action=fasttrack-connection rule in /ip firewall filter and try again.

Grrr... I forgot the obvious... disable the action=fasttrack-connection rule in /ip firewall filter and try again.

Oh man o man it worked it workeddddddddddddddddddddd
Thank you so so much I called the ISP they said there is a technical difficulty that's might be the reason it's 25Mbps
thanks again man I highly appreciate your help

Also once I got this speed but after it was mostly 17Mbps - 28Mbps which I think it's because of the VPN connection, maybe with SSTP it will be better.

Is there a way to completely cover the VPN so ISP never understand I'm using one?

Definitely not with PPTP, whose encryption is so weak that it actually hides nothing; IPsec or something-over-IPsec is also obvious, so you'd have to use an SSTP VPN which looks like a normal HTTPS session, except that the packet sizes and traffic patterns may be unusual, plus SSTP has some drawbacks for the user (speed being one of the first ones to bother you). So no, no way to hide the fact that you are using a VPN from someone really determined to find out.

@sindy What about Wireguard? I think it's available on RouterOS v7

Also once I got this speed but after it was mostly 17Mbps - 28Mbps which I think it's because of the VPN connection, maybe with SSTP it will be better.
Screenshot 2021-09-06 014845.jpg

I found very very interesting thing. So let's say the speed drop to about 17Mbps - 28Mbps (17Mbps when downloading files - 28Mbps when using speedtest) with VPN but when I start downloading a file it start with about 4MB/sec then find stability at about 1.8MB/sec and then I start downloading another one and again start with about 4MB/sec then find stability at about 1.8MB/sec so apparently I was downloading at the speed of 3.6MB/sec in total, then I start downloading another one and again start with about 4MB/sec then find stability at about 1.8MB/sec so now I was downloading at 5.4MB/sec (about 43Mbps) in total (PPTP was enabled on the router). any idea why it was limit for each file that was downloading but in total it was about 40Mbps? (and I know there is not any kind of speed limiter on the download server)

@sindy,
So the problem was because of packet fragmentation ?

Solution was at #26 by disable fasttrack-connection and this #26 should be marked as SOLVED tag..

About limit 40Mbps I discover it at all RB who not have a IPSec acceleration.
PPTP and L2TP etc have limit ~40Mbps per one vpn connection. I do a both type vpn and use them in route as ECMP. I can reach some 60-80 max.

Solution was at #26 by disable fasttrack-connection and this #26 should be marked as SOLVED tag..

Yeah you are right I test this by disabling those mangles and disable fasttrack-connection and it works pretty fine.
Thank you very much
P.S. I really like your avatar

@jaxed8,

What about Wireguard? I think it's available on RouterOS v7

Yes, Wireguard is available in ROS 7, and it is pretty fast as such on a 4011. However, TCP and ~120 ms round trip delay may mean lower throughput even if encryption and decryption alone works very fast.

The only VPN protocol to be hardware accelerated on some Mikrotik devices (including the 4011) to date is bare IPsec. As it is more flexible than Wireguard, its configuration is more complex. You have to try which of the two performs better with your VPN provider.

Regarding obfuscation, there is little difference between the two.

SSTP can never be faster than L2TP or PPTP because all of them use the same PPP encapsulation, but SSTP encypts it using TLS (which means higher CPU load) and the transport protocol of SSTP is TCP whereas L2TP uses UDP and PPTP uses GRE, so at least SSTP has more overhead, but also tunneling TCP (the payload) inside TCP (the SSTP transport) is a very bad idea as soon as packet drops may occur.

Regarding the "solution" - disabling the action=fasttrack-connection rule was actually a diagnostic step in first place. If the CPU load of the 4011 is below 30 % even now, it can stay as a solution; if it is higher, you can make it work even with that rule enabled if you let the routing table for the VPN traffic be chosen using an /ip route rule row rather than an /ip firewall mangle rule, or use the fasttracking rule selectively.


@Zacharias,

So the problem was because of packet fragmentation ?

Not in this case. Packet fragmentation does cause issues with VPNs for multiple reasons (increasing the PPS rate to 150 % wrt the non-fragmented case, higher loss rate for tiny packets/second fragments in some networks). But here, it was the well-known incompatibility between fasttracking and assigning routing-marks using mangle rules.

Yes, Wireguard is available in ROS 7, and it is pretty fast as such on a 4011. However, TCP and ~120 ms round trip delay may mean lower throughput even if encryption and decryption alone works very fast.

The only VPN protocol to be hardware accelerated on some Mikrotik devices (including the 4011) to date is bare IPsec. As it is more flexible than Wireguard, its configuration is more complex. You have to try which of the two performs better with your VPN provider.

Regarding obfuscation, there is little difference between the two.

SSTP can never be faster than L2TP or PPTP because all of them use the same PPP encapsulation, but SSTP encypts it using TLS (which means higher CPU load) and the transport protocol of SSTP is TCP whereas L2TP uses UDP and PPTP uses GRE, so at least SSTP has more overhead, but also tunneling TCP (the payload) inside TCP (the SSTP transport) is a very bad idea as soon as packet drops may occur.

Thanks man I test them and will share the results.

Regarding the "solution" - disabling the action=fasttrack-connection rule was actually a diagnostic step in first place. If the CPU load of the 4011 is below 30 % even now, it can stay as a solution; if it is higher, you can make it work even with that rule enabled if you let the routing table for the VPN traffic be chosen using an /ip route rule row rather than an /ip firewall mangle rule, or use the fasttracking rule selectively.

My CPU load is almost always at 0%
Can I disable those two /ip firewall mangle rules?
Also can you take a look at post #29 and tell me what you think and why it was like that (right now it's okay)?

My CPU load is almost always at 0%
Can I disable those two /ip firewall mangle rules?

You can try to disable them and see whether it affects the performance or not. Given that the overall performance is not stable, you may have to do several tests in each state to make a reliable conclusion.

Also can you take a look at post #29 and tell me what you think and why it was like that (right now it's okay)?

I have seen the post, but I know nothing about the load of the VPN servers nor about the network path between your home and the VPN server. The fact that the VPN server has 10 Gbit/s interfaces says nothing about the total number of clients using it, nor about the bottlenecks between your home and the VPN server. The 120 ms round-trip delay didn't come out of blue. Use /tool traceroute ip.of.the.vpn.server to see where the delay is.

Plus there may be some intentional bandwidth throttling somewhere along the path, I've seen people from ISPs to openly admit here that they decrease priority of TCP connections once they've passed enough data for a typical speedtest session - which kind of makes sense, because you mostly need the bandwidth for interactive services, huge downloads can wait.

You can try to disable them and see whether it affects the performance or not. Given that the overall performance is not stable, you may have to do several tests in each state to make a reliable conclusion.

I would say no difference after I disabled them so I will keep it this way

I have seen the post, but I know nothing about the load of the VPN servers nor about the network path between your home and the VPN server. The fact that the VPN server has 10 Gbit/s interfaces says nothing about the total number of clients using it, nor about the bottlenecks between your home and the VPN server. The 120 ms round-trip delay didn't come out of blue. Use /tool traceroute ip.of.the.vpn.server to see where the delay is.

Plus there may be some intentional bandwidth throttling somewhere along the path, I've seen people from ISPs to openly admit here that they decrease priority of TCP connections once they've passed enough data for a typical speedtest session - which kind of makes sense, because you mostly need the bandwidth for interactive services, huge downloads can wait.

I've done that but didn't understand the results that much

Yeah that might be the case as well

I've done that but didn't understand the results that much

The results show you (or not) IP addresses of the routers between your home and the destination, and the total round-trip delay (i.e. including the previous hops) to each of them.

Can you paste the result here, hiding the actual addresses of the servers that did respond, but allowing the rows where no IP address has been shown to be distinguished from those which did contain an IP address?

Also, do a /tool traceroute 8.8.8.8 routing-mark=PPTP_OVH238 and post the results as well, obfuscated the same way.

I've done that but didn't understand the results that much

The results show you (or not) IP addresses of the routers between your home and the destination, and the total round-trip delay (i.e. including the previous hops) to each of them.

Can you paste the result here, hiding the actual addresses of the servers that did respond, but allowing the rows where no IP address has been shown to be distinguished from those which did contain an IP address?

Also, do a /tool traceroute 8.8.8.8 routing-mark=PPTP_OVH238 and post the results as well, obfuscated the same way.

Here you go:

Those pictures show that most of the delay is between your ISP and the VPN provider's network.

The first one shows that the responses from the last private IP in the ISP's network arrive in 15 ms on average, whereas the responses from the first responding OVH server arrive in 116 ms on average.

The second one shows that the path from the OVH's VPN server to the local copy of 8.8.8.8 contributes just 9 ms (110 vs 101) to the total.

Those pictures show that most of the delay is between your ISP and the VPN provider's network.

The first one shows that the responses from the last private IP in the ISP's network arrive in 15 ms on average, whereas the responses from the first responding OVH server arrive in 116 ms on average.

The second one shows that the path from the OVH's VPN server to the local copy of 8.8.8.8 contributes just 9 ms (110 vs 101) to the total.

Thanks man.. So I guess it's something that we can't do anything about it.

It depends. If you are in mainland France, you may be able to choose an ISP for your home that has a better connection to OVH's network. If you are overseas, so there is a satellite link somewhere in the path, it's very likely that all ISPs will have the same issue.

It depends. If you are in mainland France, you may be able to choose an ISP for your home that has a better connection to OVH's network. If you are overseas, so there is a satellite link somewhere in the path, it's very likely that all ISPs will have the same issue.

Thank you very much

@sindy,
Yes i know that the mangle rules did not work because of fast-track being enabled, my question was actually, why did you suggested an MTU of 1300 Byte on the PPTP ?

jaxed8 write:

Screenshot 2021-09-06 023232.jpg

This software is like TeraCopy ? What it's ?

Solution was at #26 by disable fasttrack-connection and this #26 should be marked as SOLVED tag..

About limit 40Mbps I discover it at all RB who not have a IPSec acceleration.
PPTP and L2TP etc have limit ~40Mbps per one vpn connection. I do a both type vpn and use them in route as ECMP. I can reach some 60-80 max.

intresting. I'm assuming you combine l2tp with ipsec

nichky write:

intresting. I'm assuming you combine l2tp with ipsec

Clear L2TP what is done between both MikroTik.

Two location have CRS125 (1xCPU 600Mhz without IPSec acceleration) and
Site A ISP Orange 300/100
Site B ISP ATMan 100/100

I cannot reach stable 80/80 between them at any VPN I configure, whatever Site is a Server of VPN.
PPTP or L2TP have ~20/10Mbps
SSTP ~8/8Mbps
IPSec - no comment..

I back to 1x PPTP and 1xL2TP and use at both of them ECMP, what can give me sometimes transfers like ~ 40/40Mbps from 100/100 possible.

-----------------

Other Client location
Site A CCR1009 && Site B hEX - both with IPsec hardware acceleration whenre a hEX max ~470 Mbps what is not reach here.
Max of PPTP or L2TP is 40Mbps per one VPN type.
ECMP both the same type like PPTP & PPTP not change max limit of 40Mbps
ECMP both differ tyle like PPTP & L2TP give more like max 80Mbps and not more...
IPSec not tested yet, I wait for maintenance window...

Yes i know that the mangle rules did not work because of fast-track being enabled

That's not exactly true. The mangle rules adjusting TCP MSS actually do work even when the fasttracking rule is enabled, because these particular rules handle just the first two packets of each TCP session, the SYN and SYN+ACK one. And the initial SYN packet has connection-state=new, so the default action=fasttrack-connection rule ignores it as it doesn't match on connection-state=new, whereas the SYN+ACK packet already matches connection-state=established the connection doesn't get actually fasttracked until one of its packets matches the action=fasttrack-connection rule, and that packet itself still takes the "slow" path. So only the third packet of a connection can be actually fasttracked.

my question was actually, why did you suggested an MTU of 1300 Byte on the PPTP ?

Because short fragments are not treated well in some ISPs' networks, and 1300 is a low enough MTU value to make sure that even with several layers of encapsulation the outermost transport packet will still fit into the MTU of the physical interface. So by using this low value, I wanted to exclude any issues related to fragmentation.

nichky write:

intresting. I'm assuming you combine l2tp with ipsec

Clear L2TP what is done between both MikroTik.

Two location have CRS125 (1xCPU 600Mhz without IPSec acceleration) and
Site A ISP Orange 300/100
Site B ISP ATMan 100/100

I cannot reach stable 80/80 between them at any VPN I configure, whatever Site is a Server of VPN.
PPTP or L2TP have ~20/10Mbps
SSTP ~8/8Mbps
IPSec - no comment..

I back to 1x PPTP and 1xL2TP and use at both of them ECMP, what can give me sometimes transfers like ~ 40/40Mbps from 100/100 possible.

-----------------

Other Client location
Site A CCR1009 && Site B hEX - both with IPsec hardware acceleration whenre a hEX max ~470 Mbps what is not reach here.
Max of PPTP or L2TP is 40Mbps per one VPN type.
ECMP both the same type like PPTP & PPTP not change max limit of 40Mbps
ECMP both differ tyle like PPTP & L2TP give more like max 80Mbps and not more...
IPSec not tested yet, I wait for maintenance window...

i was more exciting, and i did the test. By using ECMP one site can use one tunnel ,other site other one tunnel which is fine. (see picture below)

Also i was playing with BCP and bonding , so that can give me more proper ballaning the traffic, but it seems like i cant get this work.
I can ping remote site but im not getting throughput at all, i did teste all bonding mods

@SiB

i thing we can get this work by using 2 eoip tunnels + bonding rr.
BCP was bad scenario

I have a theory.. that any tunnels with MPEE encoding are limited to 40Mbps by whole unit. Like max is 40Mbps in one direction and your bonding rr just cut this into 2x20Mb.
I use ECMP at both ends and think this give me litle more like 40-60max.

Yes i know that the mangle rules did not work because of fast-track being enabled

That's not exactly true. The mangle rules adjusting TCP MSS actually do work even when the fasttracking rule is enabled, because these particular rules handle just the first two packets of each TCP session, the SYN and SYN+ACK one. And the initial SYN packet has connection-state=new, so the default action=fasttrack-connection rule ignores it as it doesn't match on connection-state=new, whereas the SYN+ACK packet already matches connection-state=established the connection doesn't get actually fasttracked until one of its packets matches the action=fasttrack-connection rule, and that packet itself still takes the "slow" path. So only the third packet of a connection can be actually fasttracked.

my question was actually, why did you suggested an MTU of 1300 Byte on the PPTP ?

Because short fragments are not treated well in some ISPs' networks, and 1300 is a low enough MTU value to make sure that even with several layers of encapsulation the outermost transport packet will still fit into the MTU of the physical interface. So by using this low value, I wanted to exclude any issues related to fragmentation.

@sindy, you' re right...

jaxed8 write:

Screenshot 2021-09-06 023232.jpg

This software is like TeraCopy ? What it's ?

sorry for the late reply. It's IDM (Internet Download Manager) https://www.internetdownloadmanager.com/