Community discussions

 
SteelRat
just joined
Topic Author
Posts: 6
Joined: Fri Dec 30, 2016 5:54 pm

Weird behaviour (slowness) of OpenVPN traffic routing in some cases

Sat May 27, 2017 2:14 am

RouterOS: v6.39.1
Device: RouterBOARD 750G r3 (hEX)

I have set up routing of specific (marked) addresses to OpenVPN client. The weird thing is that normally it's very slow, but if you start Tools-Torch/Packet Sniffer it starts to be pretty fast.
normal router state (vk.com ip is marked to be routed to VPN):
$ time curl https://vk.com
real 0m3.336s
with any traffic monitoring tool running on the router:
$ time curl https://vk.com
real 0m0.919s
I did the checks several times and timings are always the same +-100ms. I tried to connect to my friend's OpenVPN Linux server and didn't found any changes, it's slow again. But he says when he connects with his RouterBOARD - it works perfectly. I have compared our VPN client configs and found no differences.
One more interesting point, before I upgraded to 6.39.1 (was on 6.37.x, as I remember) in normal state it was not working at all. I saw it was marking my requests, masquerading traffic going to VPN interface and that's all, looked like router ignored the answer from server. Again with Torch it was working perfectly.
I think there is something wrong with my router config. Please, help me to debug the problem.

Here is my config:
/ip route print detail 
 0 A S  dst-address=0.0.0.0/0 gateway=ovpn-out1 gateway-status=ovpn-out1 reachable check-gateway=ping distance=1 scope=10 target-scope=30 routing-mark=vpn 
 1 ADS  dst-address=0.0.0.0/0 gateway=186.36.0.1 gateway-status=186.36.0.1 reachable via  ether1 distance=1 scope=30 target-scope=10 vrf-interface=ether1 
 2 ADC  dst-address=10.0.1.0/24 pref-src=10.0.1.1 gateway=ether2-master gateway-status=ether2-master reachable distance=0 scope=10 
 3 ADC  dst-address=186.36.0.0/14 pref-src=186.36.50.241 gateway=ether1 gateway-status=ether1 reachable distance=0 scope=10 
 4 ADC  dst-address=192.168.0.0/24 pref-src=192.168.0.1 gateway=ether2-master gateway-status=ether2-master reachable distance=0 scope=10 
 5 ADC  dst-address=192.168.255.1/32 pref-src=192.168.255.6 gateway=ovpn-out1 gateway-status=ovpn-out1 reachable distance=0 scope=10
/ip firewall mangle print 
 0  D ;;; special dummy rule to show fasttrack counters
      chain=prerouting action=passthrough 
 1  D ;;; special dummy rule to show fasttrack counters
      chain=forward action=passthrough 
 2  D ;;; special dummy rule to show fasttrack counters
      chain=postrouting action=passthrough 
 3    chain=prerouting action=mark-routing new-routing-mark=vpn passthrough=yes dst-address-list=vpn log=yes log-prefix="mark"
/ip firewall nat print 
 0    chain=srcnat action=masquerade out-interface=ovpn-out1 log=yes log-prefix="masq" 
 1    ;;; defconf: masquerade
      chain=srcnat action=masquerade out-interface=ether1 
/certificate print 
 #          NAME                                                COMMON-NAME                                              SUBJECT-ALT-NAME                                                                           FINGERPRINT                                             
 0        T ca.crt_0                                            My CA                                                                                                                                     
 1 K      T client.cert_0                                       example.com
/ppp profile print 
 2   name="ovpn-client" use-mpls=no use-compression=no use-encryption=required only-one=yes change-tcp-mss=yes use-upnp=default address-list="" on-up="" on-down=""
/interface ovpn-client print 
 0  R ;;; vpn client
      name="ovpn-out1" mac-address=aa:33:bb:12:cc:dd max-mtu=1500 connect-to=server.com port=1194 mode=ip user="example.com" password="" profile=ovpn-client certificate=client.cert_0 auth=sha1 cipher=aes256 add-default-route=no
 
SteelRat
just joined
Topic Author
Posts: 6
Joined: Fri Dec 30, 2016 5:54 pm

Re: Weird behaviour (slowness) of OpenVPN traffic routing in some cases

Sat May 27, 2017 1:14 pm

Wow, I have disabled FastPath (IP - Settings) and it started working fast even in normal mode. But I don't want to lose Fast Path feature.
 
SteelRat
just joined
Topic Author
Posts: 6
Joined: Fri Dec 30, 2016 5:54 pm

Re: Weird behaviour (slowness) of OpenVPN traffic routing in some cases

Sat May 27, 2017 2:09 pm

Ok, I found it's quite frequent problem (1, 2). And users just disable fasttrack completely which can slow down other cases.
I can't (don't have time to read manuals) understand in details how fasttrack influence routing, but I found how to make it work correctly with mangling. Just create additional mangle rule with mark connection action and change fasttrack rule to do not apply when this connection mark is present.

It would be perfect if somebody can explain in details why fasttrack influence routing and what is happening under the hood when you make an HTTP request which should be forwarded via VPN.
 
slav0nic
just joined
Posts: 7
Joined: Sun Oct 26, 2014 10:14 am

Re: Weird behaviour (slowness) of OpenVPN traffic routing in some cases

Fri Jun 23, 2017 7:20 pm

Have same issue with v6.40rc24 and pre versions with ovpn client + linux server
Time response from few web resources 2sec if fastpath off and 9-10s if it enabled :/
 
slav0nic
just joined
Posts: 7
Joined: Sun Oct 26, 2014 10:14 am

Re: Weird behaviour (slowness) of OpenVPN traffic routing in some cases

Wed Jun 28, 2017 9:01 pm

Asked mikrotic support, they can't reproduce problem =/
Recommendation was add rule
/ip firewall filter add place-before=1 chain=forward action=accept dst-address-list=viaVPN
and reboot modem , but doesn't help.
Latest recommendation was:
Only explanation we came to was related to packet fragments. As you know packets fragments can't go into fastpath/fasttrack as they require assembly when going through the connection tracking. So When you enable fastpath un-fragmented, smaller packets goes fastpath, but fragments still go slowpath, so after they are processed they are out-of order and that way testing speed is slower.

So as solution in your case would be to calculate all MTUs correctly and ensure that endpoints don'' send bigger packets that smallest MTU - with change-mss.

Who is online

Users browsing this forum: Bing [Bot], Google [Bot] and 67 guests