Community discussions

MikroTik App
 
masterx1981
newbie
Topic Author
Posts: 25
Joined: Fri May 08, 2020 1:29 pm

hAP ac lite, RouterOS v6.45.8, vpn client problems

Fri May 08, 2020 1:47 pm

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!
 
sindy
Forum Guru
Forum Guru
Posts: 5343
Joined: Mon Dec 04, 2017 9:19 pm

Re: hAP ac lite, RouterOS v6.45.8, vpn client problems

Fri May 08, 2020 2:43 pm

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.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
masterx1981
newbie
Topic Author
Posts: 25
Joined: Fri May 08, 2020 1:29 pm

Re: hAP ac lite, RouterOS v6.45.8, vpn client problems

Fri May 08, 2020 8:23 pm

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...
 
sindy
Forum Guru
Forum Guru
Posts: 5343
Joined: Mon Dec 04, 2017 9:19 pm

Re: hAP ac lite, RouterOS v6.45.8, vpn client problems

Fri May 08, 2020 9:27 pm

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).
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
masterx1981
newbie
Topic Author
Posts: 25
Joined: Fri May 08, 2020 1:29 pm

Re: hAP ac lite, RouterOS v6.45.8, vpn client problems

Mon May 11, 2020 1:58 pm

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...
 
masterx1981
newbie
Topic Author
Posts: 25
Joined: Fri May 08, 2020 1:29 pm

Re: hAP ac lite, RouterOS v6.45.8, vpn client problems

Wed May 13, 2020 6:58 pm

So, no more tries to do?
 
sindy
Forum Guru
Forum Guru
Posts: 5343
Joined: Mon Dec 04, 2017 9:19 pm

Re: hAP ac lite, RouterOS v6.45.8, vpn client problems

Wed May 13, 2020 7:29 pm

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.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
masterx1981
newbie
Topic Author
Posts: 25
Joined: Fri May 08, 2020 1:29 pm

Re: hAP ac lite, RouterOS v6.45.8, vpn client problems

Thu May 14, 2020 11:27 am

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.
 
masterx1981
newbie
Topic Author
Posts: 25
Joined: Fri May 08, 2020 1:29 pm

Re: hAP ac lite, RouterOS v6.45.8, vpn client problems

Fri May 29, 2020 1:47 pm

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.
 
sindy
Forum Guru
Forum Guru
Posts: 5343
Joined: Mon Dec 04, 2017 9:19 pm

Re: hAP ac lite, RouterOS v6.45.8, vpn client problems

Sun May 31, 2020 3:32 pm

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.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
masterx1981
newbie
Topic Author
Posts: 25
Joined: Fri May 08, 2020 1:29 pm

Re: hAP ac lite, RouterOS v6.45.8, vpn client problems

Wed Jun 03, 2020 5:08 pm

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?
 
sindy
Forum Guru
Forum Guru
Posts: 5343
Joined: Mon Dec 04, 2017 9:19 pm

Re: hAP ac lite, RouterOS v6.45.8, vpn client problems

Wed Jun 03, 2020 6:32 pm

For the model, you can see it in the title of the post: hAP ac lite
Sorry, missed that while writing.

Any ideas?
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.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
masterx1981
newbie
Topic Author
Posts: 25
Joined: Fri May 08, 2020 1:29 pm

Re: hAP ac lite, RouterOS v6.45.8, vpn client problems

Fri Jun 05, 2020 2:04 pm

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...
 
sindy
Forum Guru
Forum Guru
Posts: 5343
Joined: Mon Dec 04, 2017 9:19 pm

Re: hAP ac lite, RouterOS v6.45.8, vpn client problems

Sat Jun 06, 2020 6:02 pm

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.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
masterx1981
newbie
Topic Author
Posts: 25
Joined: Fri May 08, 2020 1:29 pm

Re: hAP ac lite, RouterOS v6.45.8, vpn client problems

Sun Jun 07, 2020 1:08 pm

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.
 
masterx1981
newbie
Topic Author
Posts: 25
Joined: Fri May 08, 2020 1:29 pm

Re: hAP ac lite, RouterOS v6.45.8, vpn client problems

Mon Jun 08, 2020 12:43 pm

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)
 
masterx1981
newbie
Topic Author
Posts: 25
Joined: Fri May 08, 2020 1:29 pm

Re: hAP ac lite, RouterOS v6.45.8, vpn client problems

Mon Jun 08, 2020 1:25 pm

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...
 
masterx1981
newbie
Topic Author
Posts: 25
Joined: Fri May 08, 2020 1:29 pm

Re: hAP ac lite, RouterOS v6.45.8, vpn client problems

Mon Jun 08, 2020 5:57 pm

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.
 
sindy
Forum Guru
Forum Guru
Posts: 5343
Joined: Mon Dec 04, 2017 9:19 pm

Re: hAP ac lite, RouterOS v6.45.8, vpn client problems

Mon Jun 08, 2020 8:25 pm

/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.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
masterx1981
newbie
Topic Author
Posts: 25
Joined: Fri May 08, 2020 1:29 pm

Re: hAP ac lite, RouterOS v6.45.8, vpn client problems

Tue Jun 09, 2020 10:57 am

/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.
 
sindy
Forum Guru
Forum Guru
Posts: 5343
Joined: Mon Dec 04, 2017 9:19 pm

Re: hAP ac lite, RouterOS v6.45.8, vpn client problems

Wed Jun 10, 2020 1:36 am

Hm... couldn't google any answer regarding the relationship between setting use-compression in /ppp profile to yes and use of MPPC in particular, except that this article gave some inditia (it doesn't mention it explicitly but from the context, it deals with replacement of ppp-based VPN by OpenVPN one and refers to MPPE/MPPC handling issues). So I've asked Wireshark for help, and have seen this when the L2TP tunnel comes up:

packet dissection code

Frame 20: 62 bytes on wire (496 bits), 62 bytes captured (496 bits)
Ethernet II, Src: Routerbo_ec:8d:7a (b8:69:f4:ec:8d:7a), Dst: Routerbo_f7:63:65 (b8:69:f4:f7:63:65)
Internet Protocol Version 4, Src: 192.168.5.1, Dst: 192.168.5.103
User Datagram Protocol, Src Port: 1701, Dst Port: 1701
Layer 2 Tunneling Protocol
Point-to-Point Protocol
PPP Compression Control Protocol
    Code: Configuration Request (1)
    Identifier: 1 (0x01)
    Length: 10
    Options: (6 bytes), Microsoft PPE/PPC
        Microsoft PPE/PPC
            Type: Microsoft PPE/PPC (18)
            Length: 6
            Supported Bits: 0x01000040, H, S
                .... ...1 .... .... .... .... .... .... = H: Stateless mode ON
                .... .... .... .... .... .... 0... .... = M: 56-bit encryption OFF
                .... .... .... .... .... .... .1.. .... = S: 128-bit encryption ON
                .... .... .... .... .... .... ..0. .... = L: 40-bit encryption OFF
                .... .... .... .... .... .... ...0 .... = D: Obsolete (should ALWAYS be 0)
                .... .... .... .... .... .... .... ...0 = C: No desire to negotiate MPPC

Frame 31: 68 bytes on wire (544 bits), 68 bytes captured (544 bits)
Ethernet II, Src: Routerbo_f7:63:65 (b8:69:f4:f7:63:65), Dst: Routerbo_ec:8d:7a (b8:69:f4:ec:8d:7a)
Internet Protocol Version 4, Src: 192.168.5.103, Dst: 192.168.5.1
User Datagram Protocol, Src Port: 1701, Dst Port: 1701
Layer 2 Tunneling Protocol
Point-to-Point Protocol
PPP Link Control Protocol
    Code: Protocol Reject (8)
    Identifier: 26 (0x1a)
    Length: 16
    Rejected Protocol: Compression Control Protocol (0x80fd)
    PPP Compression Control Protocol
So as a server, the RouterOS offers the MPPE (128 bit) but not MPPC, but as a client, it rejects even the MPPE although use-encryption is set to yes (at both client and server ends) and even though use-ipsec is set to no (assuming that use-ipsec=yes would justify the rejection of MPPE).

If you set use-encryption to no (at both ends), the picture changes a bit, as in that case, the server offers zlib compression using CCP, but the client rejects it as well.

So I went as far as to set use-compression=required at both ends, but the result was that the connection did not establish at all. So I've checked the log at client side, and it says:

jun/10 00:26:24 l2tp,ppp,debug,packet l2tp-out1: rcvd CCP ConfReq id=0x1
jun/10 00:26:24 l2tp,ppp,debug,packet <mppe 1000040>
jun/10 00:26:24 l2tp,ppp,debug l2tp-out1: received unsupported protocol 0x80fd
jun/10 00:26:24 l2tp,ppp,debug,packet l2tp-out1: sent LCP ProtRej id=0x3f
jun/10 00:26:24 l2tp,ppp,debug,packet 80 fd 01 01 00 0a 12 06 01 00 00 40


Which is kind of funny, because it first properly parses the CCP (0x80fd) and then states that it is not supported and rejects it (and as there is use-encryption=required at server side, the rejection makes the server tear the whole session down).

So all in all, it doesn't look much optimistic for your application scenario.

You may try to log what the client side says when connecting to Microsoft server (/system logging add topics=ppp), but I'm afraid there will be little difference.

For the record, my client was 6.46.6.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
masterx1981
newbie
Topic Author
Posts: 25
Joined: Fri May 08, 2020 1:29 pm

Re: hAP ac lite, RouterOS v6.45.8, vpn client problems

Wed Jun 10, 2020 1:11 pm

For the encryption, not much a problem as i've switched to L2TP/IPSEC (as in any case mppe isn't a so safe encryption), for the compression, for now i'll use it in this way... Maybe one day mikrotik developers see this thread and fix it.
For who use plain L2TP client i think that can be a problem... But who use L2TP without IPSEC?

Using the Mikrotik PPTP Server MPPE seem supported, as i've tested on client to disconnect if it wasn't getting the maximum level (i think mppe 128).
I not know if also with Mikritk PPTP client there is the same problem (and can be quite bad)
 
sindy
Forum Guru
Forum Guru
Posts: 5343
Joined: Mon Dec 04, 2017 9:19 pm

Re: hAP ac lite, RouterOS v6.45.8, vpn client problems

Wed Jun 10, 2020 9:38 pm

I've only mentioned the encryption because CCP uses a single common bitmap to indicate the parameters of both Microsoft protocols, the encryption one and the compression one. I agree with you that there is no point in using the weak MPPE if the whole L2TP communication is encrypted using IPsec. Thus it surprises me that by default, L2TP interfaces refer to the default-encryption row of /ppp profile which has use-encryption=yes.

As for "maybe one day", nothing will happen unless you send a claim to support@mikrotik.com, describing the fact that RouterOS acting as a client parses properly the CPP payload and then rejects it as unknown, but I'd recommend to send the packet capture and the log taken when connecting to the Microsoft server, which I suppose proposes use of MPPC by setting the corresponding bit to 1.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
sindy
Forum Guru
Forum Guru
Posts: 5343
Joined: Mon Dec 04, 2017 9:19 pm

Re: hAP ac lite, RouterOS v6.45.8, vpn client problems

Sat Jun 13, 2020 10:38 am

Even funnier - the CCP rejection happens on mipsbe architecture (hAP ac lite), but not on arm architecture (hAP ac²). So it is definitely a bug. Hence it still makes sense to see whether the Microsoft L2TP server offers MPPC along with MPPE and whether the RouterOS acting as client accepts that offer on architectures where this bug is absent. If you want to give it a go and have no arm device at hand, feel free to create a test account for me on your Microsoft server and send me the IP address and credentials via Private Message.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
masterx1981
newbie
Topic Author
Posts: 25
Joined: Fri May 08, 2020 1:29 pm

Re: hAP ac lite, RouterOS v6.45.8, vpn client problems

Mon Jun 15, 2020 10:52 am

Even funnier - the CCP rejection happens on mipsbe architecture (hAP ac lite), but not on arm architecture (hAP ac²). So it is definitely a bug. Hence it still makes sense to see whether the Microsoft L2TP server offers MPPC along with MPPE and whether the RouterOS acting as client accepts that offer on architectures where this bug is absent. If you want to give it a go and have no arm device at hand, feel free to create a test account for me on your Microsoft server and send me the IP address and credentials via Private Message.
I have handy an hap ac2, i can try tomorrow. When i've tested with the fasttrack problem the ping that bypassed the fasttrak reached the router in the same time of the hap ac lite, but i'm not sure that i've had the compression flag active
 
masterx1981
newbie
Topic Author
Posts: 25
Joined: Fri May 08, 2020 1:29 pm

Re: hAP ac lite, RouterOS v6.45.8, vpn client problems

Wed Jun 17, 2020 12:28 pm

Sorry for the question, but with the packet filter function of the mikrotik, hot i can see l2tp control frames? One time that the ipsec tunnel is made i see only ESP traffic.
 
sindy
Forum Guru
Forum Guru
Posts: 5343
Joined: Mon Dec 04, 2017 9:19 pm

Re: hAP ac lite, RouterOS v6.45.8, vpn client problems

Wed Jun 17, 2020 1:42 pm

Sorry for the question, ...
No need to say sorry, it is really not a simple setup.

You have to use firewall mangle rules to send a TZSP-encapsulated copy of the "plaintext" L2TP packets in question to some local destination IP before the IPsec policy encrypts them; to have both directions in the same file, do the same with the received packets although in some RouterOS versions the sniffer can see both the encrypted and decrypted versions of the incoming packets. The destination IP may be one of a PC running a capture in Wireshark, or you may run the Mikrotik embedded sniffer and sniff the TZSP packets into a file, filtering by the IP address you've chosen as destination for the TZSP packets and the corresponding interface; even in this case, it is essential that the destination IP responds to ARP so that the TZSP packets would be actually sent (and thus could be sniffed).

/ip firewall mangle add chain=input protocol=udp src-port=1701 action=sniff-tzsp sniff-target=some.local.ip.address place-before=[find chain=input !dynamic]
/ip firewall mangle add chain=output protocol=udp dst-port=1701 action=sniff-tzsp sniff-target=some.local.ip.address place-before=[find chain=output !dynamic]


For me it was simpler as I was testing between two Mikrotiks so I could disable IPsec.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
masterx1981
newbie
Topic Author
Posts: 25
Joined: Fri May 08, 2020 1:29 pm

Re: hAP ac lite, RouterOS v6.45.8, vpn client problems

Fri Jun 26, 2020 1:56 pm

Hi!
I still have problem with logging the l2tp unencrypted data...
This is my mangle table:
Flags: X - disabled, I - invalid, D - dynamic 
 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=input action=sniff-tzsp sniff-target=192.168.105.150 protocol=udp 
      src-port=1701 

 4    chain=output action=sniff-tzsp sniff-target=192.168.105.150 protocol=udp 
      dst-port=1701 

 5    chain=prerouting action=mark-routing new-routing-mark=VPN passthrough=yes 
      dst-address=192.168.1.0/24 log=no log-prefix="" 

 6    chain=prerouting action=mark-routing new-routing-mark=VPN passthrough=yes 
      in-interface=l2tp-out1 log=no log-prefix="" 
AFAIK the tzsp protol generates by default traffic on udp port 37008. But if logged by both the mikrtik and the destination target, i get some udp packets, with source port 0 and destination port 0, that aren't decoded by wireshark.
 
sindy
Forum Guru
Forum Guru
Posts: 5343
Joined: Mon Dec 04, 2017 9:19 pm

Re: hAP ac lite, RouterOS v6.45.8, vpn client problems

Fri Jun 26, 2020 3:37 pm

But if logged by both the mikrtik and the destination target, i get some udp packets, with source port 0 and destination port 0, that aren't decoded by wireshark.
Yes, that's a known (at least to me) issue which @msatter has bumped into when debugging something else. The workaround is described here (start reading from the EDIT paragraph). I forgot about it since. I don't know whether @msatter has actually reported that to Mikrotik back then - as said, he was actually after another issue, and this packet malformation was just a minor stone on the path. So even the SOLVED on that topic is not related to the topic subject :)
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
masterx1981
newbie
Topic Author
Posts: 25
Joined: Fri May 08, 2020 1:29 pm

Re: hAP ac lite, RouterOS v6.45.8, vpn client problems

Fri Jun 26, 2020 4:16 pm

If i well understood, the problem in that topic relates to the wrong protocol passed (0x0 instead of 0x800). In my case, it's decoded coorrectly as an ipv4 packet, upd protocol.
Frame 73: 137 bytes on wire (1096 bits), 137 bytes captured (1096 bits)
    Encapsulation type: Ethernet (1)
    Arrival Time: Jun 26, 2020 12:33:26.959778000 ora legale Europa occidentale
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1593167606.959778000 seconds
    [Time delta from previous captured frame: 0.451612000 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 3.686798000 seconds]
    Frame Number: 73
    Frame Length: 137 bytes (1096 bits)
    Capture Length: 137 bytes (1096 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:udp:someip]
    [Coloring Rule Name: UDP]
    [Coloring Rule String: udp]
Ethernet II, Src: Routerbo_06:db:1e (c4:ad:34:06:db:1e), Dst: ASUSTekC_6f:84:da (a8:5e:45:6f:84:da)
    Destination: ASUSTekC_6f:84:da (a8:5e:45:6f:84:da)
    Source: Routerbo_06:db:1e (c4:ad:34:06:db:1e)
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.105.1, Dst: 192.168.105.150
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 123
    Identification: 0xa9e9 (43497)
    Flags: 0x0000
    Fragment offset: 0
    Time to live: 255
    Protocol: UDP (17)
    Header checksum: 0xbd9f [validation disabled]
    [Header checksum status: Unverified]
    Source: 192.168.105.1
    Destination: 192.168.105.150
User Datagram Protocol, Src Port: 0, Dst Port: 0
    Source Port: 0
    Destination Port: 0
    Length: 103
    [Checksum: [missing]]
    [Checksum Status: Not present]
    [Stream index: 0]
    [Timestamps]
And wireshark not recognize the encapsulated data in the udp (TZSP) packet
 
sindy
Forum Guru
Forum Guru
Posts: 5343
Joined: Mon Dec 04, 2017 9:19 pm

Re: hAP ac lite, RouterOS v6.45.8, vpn client problems

Fri Jun 26, 2020 4:35 pm

Hm, it seems this feature is really "widely used", given how many distinct problems it exhibits. What happens if you right-click such a packet in the list, choose Decode-as..., and explain to Wireshark that packets with UDP source port 0 should be decoded as TZSP ones?
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
masterx1981
newbie
Topic Author
Posts: 25
Joined: Fri May 08, 2020 1:29 pm

Re: hAP ac lite, RouterOS v6.45.8, vpn client problems

Fri Jun 26, 2020 4:56 pm

Wireshark not decode it, i've also disabled the wireguard decoder as it's the default for that type of packet
 
sindy
Forum Guru
Forum Guru
Posts: 5343
Joined: Mon Dec 04, 2017 9:19 pm

Re: hAP ac lite, RouterOS v6.45.8, vpn client problems

Fri Jun 26, 2020 5:00 pm

Can you send me one such packet (File->Export Specified Packets...)?
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
masterx1981
newbie
Topic Author
Posts: 25
Joined: Fri May 08, 2020 1:29 pm

Re: hAP ac lite, RouterOS v6.45.8, vpn client problems

Fri Jun 26, 2020 5:17 pm

Hope to not have exported any password :lol: :lol:
You do not have the required permissions to view the files attached to this post.
 
sindy
Forum Guru
Forum Guru
Posts: 5343
Joined: Mon Dec 04, 2017 9:19 pm

Re: hAP ac lite, RouterOS v6.45.8, vpn client problems

Fri Jun 26, 2020 5:58 pm

Hm, so you need to use the more complicated method - hex dump, modify the port in the hex dump, and re-import the packet:
Frame 1: 137 bytes on wire (1096 bits), 137 bytes captured (1096 bits) on interface unknown, id 0
Ethernet II, Src: Routerbo_06:db:1e (c4:ad:34:06:db:1e), Dst: ASUSTekC_6f:84:da (a8:5e:45:6f:84:da)
Internet Protocol Version 4, Src: 192.168.105.1, Dst: 192.168.105.150
User Datagram Protocol, Src Port: 37008, Dst Port: 37008
TZSP: Ethernet 
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: 192.168.254.10, Dst: some.ip.add.ress
User Datagram Protocol, Src Port: 1701, Dst Port: 1701
Layer 2 Tunneling Protocol
    Packet Type: Control Message Tunnel Id=3 Session Id=0
    Length: 48
    Tunnel ID: 3
    Session ID: 0
    Ns: 43
    Nr: 32
    Control Message AVP
    Assigned Session AVP
    Call Serial Number AVP
    Bearer Type AVP
Scripting is your friend in this case; unfortunately, I haven't found how to convince tshark to print raw frame data in hex.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
sindy
Forum Guru
Forum Guru
Posts: 5343
Joined: Mon Dec 04, 2017 9:19 pm

Re: hAP ac lite, RouterOS v6.45.8, vpn client problems

Fri Jun 26, 2020 6:29 pm

The maximum I could find would be this:
  • disable TZSP dissection and exit wireshark to save this preference; this should make the UDP dissector dissect the UDP payload as "data"
  • run "C:\Program Files\Wireshark\tshark" -r the-complete.pcap -T fields -e data > some-file.txt
  • split each line into space-separated pairs of hex digits, including a space after the last one (before end of line), and add "00000 " (including the space) to the beginning of each line in the resulting file, using some text editor
  • "import from hex" the resulting text file to Wireshark as encapsulation type ethernet with an UDP pseudo-header with source and destination ports 37008
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
masterx1981
newbie
Topic Author
Posts: 25
Joined: Fri May 08, 2020 1:29 pm

Re: hAP ac lite, RouterOS v6.45.8, vpn client problems

Fri Jun 26, 2020 7:22 pm

Whaaaattt...
Ok, replaced all the instances of 69 96 00 00 00 00 with 69 96 90 90 90 90 and we are ready :lol:

From MS L2TP server to mikrotik HAP AC2:
PPP Compression Control Protocol
    Code: Configuration Request (1)
    Identifier: 4 (0x04)
    Length: 10
    Options: (6 bytes), Microsoft PPE/PPC
        Microsoft PPE/PPC
            Type: Microsoft PPE/PPC (18)
            Length: 6
            Supported Bits: 0x01000001, H, C
                .... ...1 .... .... .... .... .... .... = H: Stateless mode ON
                .... .... .... .... .... .... 0... .... = M: 56-bit encryption OFF
                .... .... .... .... .... .... .0.. .... = S: 128-bit encryption OFF
                .... .... .... .... .... .... ..0. .... = L: 40-bit encryption OFF
                .... .... .... .... .... .... ...0 .... = D: Obsolete (should ALWAYS be 0)
                .... .... .... .... .... .... .... ...1 = C: Desire to negotiate MPPC
mikrotik answer:
PPP Link Control Protocol
    Code: Protocol Reject (8)
    Identifier: 14 (0x0e)
    Length: 16
    Rejected Protocol: Compression Control Protocol (0x80fd)
    PPP Compression Control Protocol
        Code: Configuration Request (1)
        Identifier: 4 (0x04)
        Length: 10
        Options: (6 bytes), Microsoft PPE/PPC
            Microsoft PPE/PPC
                Type: Microsoft PPE/PPC (18)
                Length: 6
                Supported Bits: 0x01000001, H, C
                    .... ...1 .... .... .... .... .... .... = H: Stateless mode ON
                    .... .... .... .... .... .... 0... .... = M: 56-bit encryption OFF
                    .... .... .... .... .... .... .0.. .... = S: 128-bit encryption OFF
                    .... .... .... .... .... .... ..0. .... = L: 40-bit encryption OFF
                    .... .... .... .... .... .... ...0 .... = D: Obsolete (should ALWAYS be 0)
                    .... .... .... .... .... .... .... ...1 = C: Desire to negotiate MPPC
If i've well understood, the mikrotik rejected the compression, In the profile i've set "use compression" to yes...

I was expecting that the router was asking to use compression, but i not know the L2TP flow, so i was wrong...
 
sindy
Forum Guru
Forum Guru
Posts: 5343
Joined: Mon Dec 04, 2017 9:19 pm

Re: hAP ac lite, RouterOS v6.45.8, vpn client problems

Fri Jun 26, 2020 8:50 pm

You may try to permit encryption in the profile, in that case the response to the CCP may be different, but I doubt it would accept MPPC anyway.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
masterx1981
newbie
Topic Author
Posts: 25
Joined: Fri May 08, 2020 1:29 pm

Re: hAP ac lite, RouterOS v6.45.8, vpn client problems

Sat Jun 27, 2020 10:55 am

So, spotted 2 bugs in one try :lol:
The positive thing is that they have fixed the bad protocol identifier (0x0 instead of 0x800).
One question, mikrotik have so many bugs? I've used them in the past as simple ipsec tunnels and as vpn servers without much troubles.
There isn't a list of the current bugs of the routeros software?
 
sindy
Forum Guru
Forum Guru
Posts: 5343
Joined: Mon Dec 04, 2017 9:19 pm

Re: hAP ac lite, RouterOS v6.45.8, vpn client problems

Sat Jun 27, 2020 12:05 pm

There isn't a list of the current bugs of the routeros software?
If there is one, it is a top secret hidden on a secret place in a secret country, and nobody knows who knows where exactly :)

Bugs can only be fixed if someone reports them, and if that someone is important enough (i.e. buying enough hardware or licenses to matter for the cash flow) that it was worth it to assign developers' time to resolving of that bug. Good (in fact, any) software developers are a scarce resource nowadays, and there are so many important bugs that need an urgent fix that fixing of those which only bother five people in the world is simply getting postponed to never. Vendors with more expensive products also have bugs, but as they sell them for higher price, they can afford more developers so they can fix more of the bugs and sooner.

Having said that, the fact that RouterOS does support MPPE but doesn't support MPPC is likely to be a design choice rather than a bug. The fact that you cannot establish an MPPE "encrypted" connection between an arm device acting as a server and a mipsbe device acting as a client is a clear bug, and so are the wrongly populated fields of the TZSP packets.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
masterx1981
newbie
Topic Author
Posts: 25
Joined: Fri May 08, 2020 1:29 pm

Re: hAP ac lite, RouterOS v6.45.8, vpn client problems

Sat Jun 27, 2020 1:01 pm

Yeah, worked also on cisco devices, and also ios have bugs, spotted few... and the updates aren't free, you need to have a contract.

Who is online

Users browsing this forum: ammarmohammed1 and 59 guests