Hi!
I’ve setup a PPTP connection to a microsoft VPN server, the connection is ok, pings goes well (also with 10KB len, fragmented), but if i start an RDP session, or if i transfer a file it’s really slow (while cpu of the microtik remains at 1/2% load), and 99% of the times the rdp fails or hang. If on the same pc i launch a software VPN connection, the link is fast and good.
I’ve tried to do a wireshark of the traffic from pc to the mikrotik while generating traffic to the VPN destination network, and i’ve seen a lot of retransmissions and TCP timeouts, also with small packet len (100bytes including header), that must rule out an MTU problem.
So, what can cause this type of problem?
Thanks!
You can sniff into a file on the WAN of the Mikrotik itself to see how the traffic inside the GRE tunnel is doing. And since you connect to a Microsoft server, I’d recommend to enable MLPPP handling on the Mikrotik client, it might help.
I’ve noticed than when the server line has less load, the mikrotik VPN works better. The server is in a location that has a not-so-good line, but using ddwrt devices and windows clients never had any problem.
Thanks for the suggestion to enable the MLPPP, but i have only one internet access where the server is located…
That doesn’t matter - never mind how odd it seems, MLPPP works over a single link too, and it overcomes the MTU issues as it fragments the packets using its internal mechanism rather than the standard IP fragmentation (the rationale is that PPP can tunnel also MPLS and Ethernet frames which do not support fragmentation).
If iwell understood, for enable MLPPP over single link, on mikortik side it’s sufficent to set the MRRU at some value (i’ve used 1614).
By now, nothing changed.
If i replace the mikrotik with a DDWRT with similar settings (same mtu,. etc) all is working ok. And the ddwt is on a WRT54GL that have a lot less resources available than the mikrotik…
So, no more tries to do?
I gave you two suggestions - to use MLPPP and to sniff on the Mikrotik’s WAN to see how the packets in the GRE tunnel look like. You’ve only responded to one of them. The idea is that you sniff on LAN port and the WAN one simultaneously, so you can see whether all packets which are received from LAN are actually sent out via GRE.
Also, I don’t know whether you eventually use some packet priotitization (QoS), which may result in packets from the VPN client running on the PC being prioritized on the uplink, whilst those sent by Mikrotik itself are not. There is a lot of possible reasons for the behaviour, but you gave too few information about the environment and traffic observations.
Hi! Thanks, i will try to sniff both packets sent and packets out to the destination wan ip.
There is no qos politics or other things. If i replace the mikrotik device with a DDWRT device configured with the PPTP client like the mikrotik, all works as it should. On both MTU and other parameters are set the same.
Sniffing the packets haven’t solved nothing.
So, i’ve tried with some difficulties to switch from pptp to l2tp, but the problem is the same. Slow as hell.
A simple ping with 1300bytes sent via mikrotik vpn client takes near twice the time that via a software vpn. The rdp connection are instable, etc.
So, what’s next?
I need to replace dozens of ddwrt devices and i was hoping to use mikrotiks, but with this problems i need to give up the idea. It’s nice that with an old wrt54g and ddwrt software, with half the processing power than this device, i never had such problems.
Sniffing is not a solution, sniffing is a tool to analyse what is going on. You’ve provided no result of the sniffing, just a conclusion based on a wrong assumpion.
This type of configuration, where Mikrotik acts as a PPTP client, regularly works for other people (me included), so it is very likely something related to your particular configuration, but you didn’t bother to post it.
Nor have you stated the model of the Mikrotik, whether you have excluded cabling problems etc.
I obviously know that sniffing doesn’t “solve nothing”, but has not evidenced anything abnormal.
For the model, you can see it in the title of the post: hAP ac lite
Now i’ve tried also the same config on a HAP ac2 RBD52G (much more powerfull), same result.
I’ve tried also to switch to L2TP. Always poor results.
This case is quite specific, the connectivity on the other side is really bad, but when i switch to windows VPN, it became useable, while over the mikrotik tunnel isn’t useable. It works also quite well using a WRT54G running DD-WRT.
And this is the config, generated by web interface (normally i work on cisco’s os, by now i’ve not played with microtik syntax)
Local network 192.168.88.0/24
Remote network: 192.168.1.0/24
On the other side there is windows server OS using builtin VPN server. Both devices behind NAT (working with NAT-T)
[admin@MikroTik] > /export hide
# jun/03/2020 15:58:04 by RouterOS 6.43.10
# software id = M5C7-470P
#
# model = RBD52G-5HacD2HnD
# serial number = A6470ADB3269
/interface bridge
add admin-mac=C4:AD:34:06:DB:1E auto-mac=no comment=defconf name=bridge
/interface ethernet
set [ find default-name=ether1 ] advertise=\
10M-half,10M-full,100M-half,100M-full mac-address=C4:AD:34:06:DB:1D name=\
Internet speed=100Mbps
set [ find default-name=ether2 ] advertise=\
10M-half,10M-full,100M-half,100M-full mac-address=C4:AD:34:06:DB:1E speed=\
100Mbps
set [ find default-name=ether3 ] advertise=\
10M-half,10M-full,100M-half,100M-full mac-address=C4:AD:34:06:DB:1F speed=\
100Mbps
set [ find default-name=ether4 ] advertise=\
10M-half,10M-full,100M-half,100M-full mac-address=C4:AD:34:06:DB:20 speed=\
100Mbps
set [ find default-name=ether5 ] advertise=\
10M-half,10M-full,100M-half,100M-full mac-address=C4:AD:34:06:DB:21 speed=\
100Mbps
/interface l2tp-client
add connect-to=xxx.xxx.xxx.xxx dial-on-demand=yes disabled=no keepalive-timeout=\
disabled max-mru=1460 max-mtu=1460 name=l2tp-out1 use-ipsec=yes user=noone
/interface wireless
set [ find default-name=wlan1 ] name=wlan3 ssid=MikroTik
set [ find default-name=wlan2 ] name=wlan4 ssid=MikroTik
/interface pptp-client
add allow=mschap1,mschap2 connect-to=xxx.xxx.xxx.xxx keepalive-timeout=30 mrru=\
1500 name=pptp-out1 user=noone
/interface ethernet switch port
set 0 default-vlan-id=0
set 1 default-vlan-id=0
set 2 default-vlan-id=0
set 3 default-vlan-id=0
set 4 default-vlan-id=0
set 5 default-vlan-id=0
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
add authentication-types=wpa2-psk management-protection=allowed mode=\
dynamic-keys name=WiFi supplicant-identity=MikroTik
/ip hotspot profile
set [ find default=yes ] html-directory=flash/hotspot
/ip ipsec peer profile
set [ find default=yes ] dh-group=modp1024 dpd-interval=disable-dpd \
enc-algorithm=aes-256,aes-128,3des
/ip ipsec proposal
set [ find default=yes ] auth-algorithms=sha256,sha1 enc-algorithms=\
aes-256-cbc,aes-192-cbc,aes-128-cbc,3des pfs-group=none
/ip pool
add name=default-dhcp ranges=192.168.88.10-192.168.88.254
/ip dhcp-server
add address-pool=default-dhcp disabled=no interface=bridge name=defconf
/ppp profile
set *0 change-tcp-mss=default
/interface bridge port
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=ether5
add bridge=bridge comment=defconf interface=*1
add bridge=bridge comment=defconf interface=*2
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=Internet list=WAN
/ip address
add address=192.168.88.1/24 comment=defconf interface=bridge network=\
192.168.88.0
/ip dhcp-client
add comment=defconf dhcp-options=hostname,clientid disabled=no interface=\
Internet
/ip dhcp-server network
add address=192.168.88.0/24 comment=defconf gateway=192.168.88.1
/ip dns
set allow-remote-requests=yes servers=8.8.8.8,8.8.4.4
/ip dns static
add address=192.168.88.1 comment=defconf name=router.lan
/ip firewall filter
add action=accept chain=input comment=\
"defconf: accept established,related,untracked" connection-state=\
established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment=\
"defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
in-interface-list=WAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" \
ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
connection-state=established,related
add action=accept chain=forward comment=\
"defconf: accept established,related, untracked" connection-state=\
established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=\
invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" \
connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
/ip firewall mangle
add action=mark-routing chain=prerouting new-routing-mark=VPN passthrough=yes \
src-address=192.168.88.0/24
/ip firewall nat
add action=masquerade chain=srcnat out-interface=l2tp-out1
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=\
out,none out-interface-list=WAN
/ip route
add distance=1 dst-address=192.168.1.0/24 gateway=l2tp-out1 routing-mark=VPN
/ip traffic-flow
set cache-entries=16k
/system clock
set time-zone-name=Europe/Rome
/system leds
add interface=Internet leds="" type=interface-activity
add interface=ether2 leds="" type=interface-activity
add interface=ether3 leds="" type=interface-activity
add interface=ether4 leds="" type=interface-activity
add interface=ether5 leds="" type=interface-activity
/system logging
add topics=ipsec
/system ntp client
set enabled=yes primary-ntp=193.204.114.232 secondary-ntp=193.204.114.233
/system resource irq rps
set Internet disabled=no
set ether2 disabled=no
set ether3 disabled=no
set ether4 disabled=no
set ether5 disabled=no
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN
/tool sniffer
set file-name=test filter-interface=Internet filter-ip-address=\
xxx.xxx.xxx.xxx/32
Any ideas?
Sorry, missed that while writing.
Yes. Most packets belonging to fasttracked connections bypass mangle rules and other firewall processing. So the connections initiated by clients in your 192.168.88.0/24 are set up via the VPN tunnel, but as soon as the response comes and they get fasttracked, most of the outgoing packets take the default route in routing table main, so they never make it to the destination. The connections do work, albeit very slowly, because some 1 or 5 or 10 per cent of packets belonging to fasttracked connections are not fasttracked.
One possible way to selectively exclude only the VPN traffic from fasttracking is described here.
It’s always better to post the configuration right at the beginning. You didn’t suspect firewall rules and/or policy routing to be related, so you haven’t even mentioned that you use policy routing.
Sorry for not have posted before the config but was quite standard, i’ve started with default config and enabled only what needed.
But, if it’s the fasttrack action, why as i’ve setup some l2tp/pptp servers with mikrotik and never had this problem?
Always using L2TP, I’ve tried to disable totally the fasttrack (only as test), the connection is more stable (less lost pings, as expected) but the performance is still poor. A ping with 65000bytes (actually a bit more as windows ping add the header), so fragmented, with mikrotik take around 900ms, with windows vpn (always l2tp) is around 160ms…
Such a huge difference is weird. The sniffing should show the delays in the individual steps of packet handling.
The ICMP echo request packet arrives through the LAN interface at time T1; the VPN transport packet carrying it (an IPsec encrypted L2TP one or a GRE one if you use PPTP) is sent at time T2; the VPN transport packet carrying the ICMP echo response comes at time T3, and the decapsulated ICMP echo response comes at time T4. This should tell you where the delay comes from. You’ll need Wireshark to analyze the sniff, as the sniffing filter needs to be quite wide (no restriction on interface or protocol, several IP addresses) to capture both the payload (ICMP request/response) and the VPN transport packets.
Tomorrow i will try some more sniffing. I was already using wireshark as viewer with previous tests.
Quite strange that using mikrotik as server (used them in 3 occasions), never noticed this slowness. Only now as client.
And here is the dump:
70 2.906474 192.168.88.254 192.168.1.1 IPv4 1514 Fragmented IP protocol (proto=ICMP 1, off=0, ID=d9f5) [Reassembled in #156]
....
155 2.911652 192.168.88.254 192.168.1.1 IPv4 1514 Fragmented IP protocol (proto=ICMP 1, off=62160, ID=d9f5) [Reassembled in #156]
156 2.911740 192.168.88.254 192.168.1.1 ICMP 1402 Echo (ping) request id=0x0002, seq=34347/11142, ttl=128 (reply in 387)
157 2.911752 192.168.88.254 192.168.1.1 IPv4 1402 Fragmented IP protocol (proto=ICMP 1, off=63640, ID=d9f5)
158 2.911908 192.168.1.34 192.168.1.1 IPv4 1410 Fragmented IP protocol (proto=ICMP 1, off=0, ID=d9f5)
159 2.912378 192.168.254.12 xxx.xxx.xxx.xxx ESP 1502 ESP (SPI=0x5ce3432c)
...
225 2.925795 192.168.254.12 xxx.xxx.xxx.xxx ESP 1502 ESP (SPI=0x5ce3432c)
226 2.925841 192.168.1.34 192.168.1.1 IPv4 1410 Fragmented IP protocol (proto=ICMP 1, off=46784, ID=d9f5)
240 3.066544 xxx.xxx.xxx.xxx 192.168.254.12 ESP 1502 ESP (SPI=0x087e06ba)
241 3.067061 192.168.1.1 192.168.1.34 IPv4 1410 Fragmented IP protocol (proto=ICMP 1, off=0, ID=0c9b) [Reassembled in #339]
...
338 3.826649 xxx.xxx.xxx.xxx 192.168.254.12 ESP 462 ESP (SPI=0x087e06ba)
339 3.826947 192.168.1.1 192.168.1.34 ICMP 370 Echo (ping) reply id=0x0002, seq=34347/11142, ttl=127
340 3.827088 192.168.1.1 192.168.88.254 IPv4 1410 Fragmented IP protocol (proto=ICMP 1, off=0, ID=0c9b) [Reassembled in #387]
...
386 3.828052 192.168.1.1 192.168.88.254 IPv4 1410 Fragmented IP protocol (proto=ICMP 1, off=63296, ID=0c9b) [Reassembled in #387]
387 3.828064 192.168.1.1 192.168.88.254 ICMP 370 Echo (ping) reply id=0x0002, seq=34347/11142, ttl=126 (request in 156)
192.168.88.254 is the ip of the workstation
192.168.88.1 is the ip of the gateway
192.168.1.1 is the remote ip of the server
192.168.1.34 is the ip that the router got from the vpn server
192.168.254.12 is the wan ip of the mikrotik
xxx.xxx.xxx.xxx is the public ip of the vpn server
Seem that sending the packets is quite fast, the main slowness is receiving them (~ 800ms).
All seem good, only waaaay slow.
If i switch on the windows vpn, the same ping (in -t) goes from near ~900ms to near ~160ms (and the same if i switch off the software vpn)
Whooaaaa
Found the difference!
The windows VPN (and the ddwrt) was set with software compression. When i’ve removed the compression from windows vpn client, the windows vpn ping gone from ~160ms to ~900ms like the mikrotik vpn.
There is a way on the microtik to use the mppc compression?
As the link on the other side is really slow, i prefer a little overhead doing the compression calculations…
Tried to use the “Use Compression” flag on the profile, but the ping is still slow…
Regarding the mangle, i’ve got it work adding to the fasttrack default rule to exclude the routing marked traffic “VPN” (! VPN)
The same marking “VPN” is used in the route from my network to the remote network on the l2tp client interface.
Then i’ve created 2 mangles:
One marking routing from local network to remote network ip addresses, with marking “VPN” (used by the route)
The other marking always with “VPN” the traffic coming from the l2tp client interface (almostly used for exclude the vpn traffic from the fasttrack action)
In this way no vpn traffic is got by the fasttrak
The connection is stable, all work as it should, but quite slower due to the missing compression. If i find a way to to the mppc compression would be perfect.
/ppp profile add copy-from=default-encryption use-compression=yes name=encryption-with-compression
/interface l2tp-client set your-interface-name profile=encryption-with-compression
Disconnect, reconnect, test.
That compression setting seem to not have any effect… Also enabling it in the profile, the ping times are always in the ~900ms range.