PPTP / L2TP problems in v7.16.2

RouterOS General
1

(mod edit holvoetn: split from v7.16.2 [stable] is released!)

############ New information for PASS PPTP and L2TP/IPsec servers ############

Updated information for PPTP on Dec 28, 2024. The remote 2000 km site hAP ac^3 with v7.16.2, public IP, local IP=172.16.88.0/x.

Configuration 1: Windows 10，Honor phone or Huawei PPTP clients passed the tests.

/interface pptp-server server set enabled=yes

/ppp secret add local-address=172.16.88.1 name=vpn password=vpn profile=default-encryption remote-address=172.16.88.5 service=pptp

/ip firewall filter
add action=accept chain=input comment="PPTP China" dst-port=1723 \
    in-interface=ether1 protocol=tcp

Configuration 2：Same as Config. 1. More clients were added to the server.

/ip pool
add name=PPTP_pool ranges=172.16.88.100-172.16.88.150

/ppp profile add name=PPTP_prof local-address=172.16.88.1 \
    remote-address=PPTP_pool use-encryption=yes

/ppp secret add name=vpn password=vpn profile=PPTP_prof service=pptp

/interface pptp-server server set default-profile=PPTP_prof enabled=yes 

/ip firewall filter
add action=accept chain=input comment="PPTP China" dst-port=1723 \
    in-interface=ether1 protocol=tcp

Previously Huawei pad has the PPTP connection problems, I found there were authentication issues in the router log. Since I found no visual errors in the credential settings, I cleaned the initial settings and repeated the input settings. It was found that the PPTP test was successful.

Configuration 3：Same as Config. 2 with a different segment.

/ip pool 
add name=pptp_pool ranges=172.31.255.2-172.31.255.254

/ppp profile add name=pptp_profile local-address=172.31.255.1 \
remote-address=pptp_pool use-encryption=yes

/ppp secret add name=vpn password=vpn service=pptp profile=pptp_profile

/interface pptp-server server set default-profile=pptp_profile enabled=yes

/ip firewall filter
add action=accept chain=input comment="PPTP China" dst-port=1723 \
    in-interface=ether1 protocol=tcp

Now I use the configuration 3 as my final settings for the PPTP server and local address is the as same as previous one, 172.16.88.0/24.

L2TP/IPsec settings: iPhone, iPad, Honor phone, Huawei pad, and Windows 10 passed.

/ip pool
add name=l2tp-pool ranges=172.31.254.2-172.31.254.254

/ppp profile add name=l2tp-profile local-address=172.31.254.1 \
    remote-address=l2tp-pool use-encryption=yes

/ppp secret add name=vpn password=vpn profile=l2tp-profile service=l2tp

/interface l2tp-server server set default-profile=l2tp-profile enabled=yes \
use-ipsec=required ipsec-secret=vpn

/ip firewall filter
add action=accept chain=input comment="L2TP China" dst-port=1701 \
    in-interface=ether1 protocol=udp
add action=accept chain=input comment="IPsec" dst-port=500,4500 \
    in-interface=ether1 protocol=udp

############ end of information ############

PPTP is no longer in v7.x

Although PPTP is an old protocol, in MikroTik manual it can be used in v7. For the beginners like me, we may learn basic VPN like PPTP. For other two protocols WireGuard and IPSec IKEv2, these two protocols have been verified in v7 without any problems.

The following scripts demonstration how router DOES NOT work!!!
Hap ac3 v7.16.2
public IP=114.100.x,y, local IP=192.168.55.0/24

/interface pptp-server server set enabled=yes
/ppp secret add local-address=192.168.89.1 name=vpn password=vpn profile=default-encryption remote-address=192.168.89.5 service=pptp

/ip firewall filter
add action=accept chain=input comment=“PPTP China” dst-port=1723
in-interface=ether1 protocol=tcp

/ip firewall filter
add action=accept chain=input comment=“GRE” protocol=47 in-interface=ether1

/ip firewall nat
add chain=srcnat src-address=192.168.89.0/24 out-interface=ether1 action=masquerade

When a PC connected to the internal segment 192.168.55.0/24, the Windows PPTP (server: 114.100.x.y, user=vpn, password=vpn) could log in “ac3” without any problems.

When the PC connected to the external world via iPhone , the PC was not able to login the “ac3”.

When the same PC connected the “ac3” using WireGuard or IPSec IKEv2 in v7，it could connect the “ac3” without any problems.

In v6 or v5, there were no problems in the past but v7 cannot work!!!

Please help!

v7.16.2 [stable] is released!
2

This discussion is focused on release-specific topics, such as questions about the changelog or issues related to this particular version. For general inquiries, please consider creating a separate topic to ensure they receive the appropriate attention. Wishing you a Merry Christmas!

3

PPTP is no longer in v7.x

My external public server: hAP ac^3, v7.16.2
public IP=114.100.x.y, local IP=192.168.55.0/24

/interface pptp-server server set enabled=yes
/ppp secret add local-address=192.168.55.1 name=trial password=trial profile=default-encryption remote-address=192.168.55.5 service=pptp

/ip firewall filter
add action=accept chain=input comment=“PPTP China” dst-port=1723
in-interface=ether1 protocol=tcp

(placed at the first line of firewall filter rules)

  1. My friend put a router DDWRT installed with a PPTP server located 2000 km away from my site. My Android WiFi was connected to the iPhone to the external Internet, and my Android built-in PPTP client was able to connect the PPTP server.

  2. The Android PPTP client via iPhone was modified with the public IP=114.100.x.y and tried to connect the hAP ac^3 using the same PPTP protocol. The result failed.

  3. When the Android was connected to the home hAP ac^3’s WiFi, it could connect the internal PPTP server using PPTP client IP=114.100.x.y or IP=192.168.55.1.

  4. Another hAP ac^2 v7.16.2, public IP=192.168.55.37 (internal network 192.168.55.x) installed the same PPTP server, the Android PPTP client connected to the home WiFi was able to connected using PPTP.

It shows that RouterOS can operate PPTP when the connected straight as shown in items 3 and 4.

When the PPTP client caller in Internet, RouterOS CANNOT OPERATE PPTP.

Please place PPTP client caller in Internet, and try to connect to RouterOS v7, find out what is WRONG.

4

@yhfung, please create a dedicated topic in forum general for further discussion.

5

L2TP/IPsec is longer in v7.x

Please check with MikroTik YouTube https://www.youtube.com/watch?v=lca7lDsPd8w

It showed that “Your own VPN server in 2 seconds” and could be connected to L2TP VPN using iPhone.

After having reviewed the video and carried out the same test using iPhone, the result is not same!!! The iPhone was supposed to the public Internet and carried out the mentioned L2TP/IPsec test. The test result failed and only IKE udp 500 of router under test has some traffic.

MikroTik engineers please help!!!

6

Thanks @infabo.

@yhfung, let’s go step by step for both PPTP and L2TP. I will save the lecture regarding PPTP not being secure any more and get to the technical point.

PPTP: the complete protocol consists of two parts, the session negotiation and authentication using TCP where the server listens at port 1723, and the actual transport of data which uses GRE. GRE has no notion of ports and therefore it can only traverse NAT under certain conditions, one of them being that the NAT device even bothers about GRE.

To make things more complicated, somewhere at 6.4x times, Mikrotik has identified some security flaw with GRE and “fixed” it; a side effect of that “fix” is that now the connection tracking sets the connection-state attribute of incoming GRE packets as invalid, unless you enable the PPTP helper under /ip/firewall/service-port.

So post the export of the configuration of the router you have set as a PPTP server so that we could check whether its own configuration is correct; even if it is, the clients may be able to connect from some remote networks and unable from others, because treatment of GRE in the NATing devices in those remote networks may differ.



Regarding L2TP - both session negotiation and data transport uses UDP on port 1701, officially at both server side and client side, but most implementations tolerate any client-side port. However, due to the weakness of the encryption and authentication methods of L2TP (actually, PPP) itself, IPsec in transport mode is normally used to encapsulate and encrypt the L2TP connection, which means that all the routers between the client and the server can only see traffic on UDP port 500 and ESP traffic (if both the server and the client have a public address) or on UDP ports 500 and 4500 (if at least one of the two participants is behind NAT).

To make things more complicated, the embedded Windows client doesn’t like the server to run on a private address unless you change some settings in the Windows Registry, and the protocol is not designed to support connection of multiple clients of the same server from behind the same public address if both of them use the same port at their side, which is what Windows clients do. To overcome that, you have to set the server up in a complicated way (there is a trick for that in Linux but Mikrotik never implemented it), but I assume it is not the issue you are fighting with right now. So like in the PPTP case, post the export of the configuration to see the issues. Unlike in the PPTP case, IPsec can traverse any NAT, so if something does not work even if the server is set up properly, the reason is most likely to be some active filtering on the path between the server and the client. But as you could make it work with OpenWRT, it should not be the case.

7

Thanks @sindy’s reply.

Now my concentration is PPTP first in v7.x. If PPTP is complete, then we will proceed to L2TP in v7.x.

In this afternoon, I installed a PPTP server in 2000 km away from my home. Please see as follows:

/interface pptp-server server set enabled=yes
/ppp secret add local-address=172.16.88.1 name=vpn password=vpn profile=default-encryption remote-address=172.16.88.5 service=pptp

/ip firewall filter
add action=accept chain=input comment=“PPTP China” dst-port=1723
in-interface=ether1 protocol=tcp

Please note the firewall filter rule was located in the first line in the table. The remote router hAP ac^3, v7.16.2, public ip=1.1.1.1(for illustration), local ip=172.16.88.0/24. I used an Android tablet with pptp settings ip=1.1.1.1, user=vpn, password=vpn. The test result failed.

MikroTik Engineers or others may provide answers to fix the problems.

8

Why do you use public 1.1.1.1 address in your devices for anything different than DNS server?

EDIT:

VPN to/from China … +1000 to setup problems.

9

This is used for illustration only. You may use others for your case.

10

So you have to be precise and do not throw in such info into the thread as helpers focus on that very problematic fact.
If you want to do an example then use any usable/proper address in such a situation.

11

Please provide the output of
/ip firewall filter print chain=input
/ip firewall service-port print

12

Thanks @sindy.

Please see as following:

[admin@MikroTik] > /ip firewall filter print chain=input
Flags: X - disabled, I - invalid; D - dynamic
0 ;;; PPTP China
chain=input action=accept protocol=tcp
in-interface=ether1 dst-port=1723

1 ;;; defconf: accept established,related,untracked
chain=input action=accept
connection-state=established,related,untracked

2 ;;; defconf: drop invalid
chain=input action=drop connection-state=invalid

19 ;;; defconf: drop all not coming from LAN
chain=input action=drop in-interface-list=!LAN

[admin@MikroTik] > /ip firewall service-port print
Flags: X - DISABLED, I - INVALID
Columns: NAME, PORTS

NAME PORTS

0 X ftp 21
1 tftp 69
2 X irc 6667
3 X h323
4 X sip 5060
5061
5 pptp
6 X rtsp 554
7 udplite
8 dccp
9 sctp
[admin@MikroTik] >

13

OK, so the PPTP helper is enabled, which should be sufficient to make the firewall accept GRE.

So the next step is to run /tool sniffer quick interface=ether1 port=1723 on the server and try to connect from the PPTP client. If you do that, can you see packets in both directions?

14

Yes, you are right.

[admin@MikroTik] > /tool sniffer quick interface=ether1 port=1723
Columns: INTERFACE, TIME, NUM, DIR, SRC-MAC, DST-MAC, SRC-ADDRESS, DST-ADDRESS, PROTOCOL, SIZE, CPU
INTERFACE  TIME    NUM  DIR  SRC-MAC            DST-MAC            SRC-ADDRESS                  DST-ADDRESS                  PROTOCOL  SIZE  CPU
ether1     22.197    1  <-                                         114.xx.xx.xx:48195          203.xx.xx.xx:1723 (pptp)      ip:tcp      74    3
ether1     22.197    2  ->                                         203.xx.xx.xx:1723 (pptp)    114.xx.xx.xx:48195            ip:tcp      74    3
ether1     22.715    3  <-                                         114.xx.xx.xx:48195          203.xx.xx.xx:1723 (pptp)      ip:tcp      66    3
ether1     22.717    4  <-                                         114.xx.xx.xx:48195          203.xx.xx.xx:1723 (pptp)      ip:tcp     222    3
ether1     22.717    5  ->                                         203.xx.xx.xx:1723 (pptp)    114.xx.xx.xx:48195            ip:tcp      66    3
ether1     22.719    6  ->                                         203.xx.xx.xx:1723 (pptp)    114.xx.xx.xx:48195            ip:tcp     222    3

What is the next task to done?

15

The next step would be to run /tool sniffer quick interface=ether1 ip-address=114.xx.xx.xx and make a connection attempt again, to see whether any GRE packets arrive from the address of the client.

It may also make sense to save the sniffed data into a file and use Wireshark to inspect the initial authentication conversation and see whether the authentication actually succeeded.

16

Yes, there are GRE packets to and from the client.

[admin@MikroTik] > /tool sniffer quick interface=ether1 ip-address=114.xx.xx.xx
Columns: INTERFACE, TIME, NUM, DIR, SRC-MAC, DST-MAC, SRC-ADDRESS, DST-ADDRESS, PROTOCOL, SIZE, CPU
INTERFACE  TIME    NUM  DIR  SRC-MAC            DST-MAC            SRC-ADDRESS                  DST-ADDRESS                  PROTOCOL  SIZE  CPU
ether1     15.173   11  <-                                                                                                  ip:gre      74    3
ether1     15.174   12  ->                                                                                                  ip:gre      73    0
ether1     15.174   13  ->                                                                                                  ip:gre      68    0
ether1     15.186   14  <-                                                                                          (pptp)  ip:tcp      66    1
ether1     16.075   15  ->                                                                                                  ip:gre      73    0

How can I download a pcap file for Wireshark in the remote 2000 km router?

17

OK, so what type of machine is the client? Can you also run Wireshark or tcpdump or any other kind of sniffer on it to see whether the GRE makes it back to it?

Also, what is the client behavior, does it show a connection attempt and then reports a failure or it says it is connected but no data actually pass through?


What method do you currently use to manage it?

18

I have three PPTP clients, namely Huawei pad, Honor phone and Windows 10. The tests were carried out using Huawei pad and got failure results. When I changed it to Honor phone and Windows 10, both tests were successful. I made another PPTP test using Huawei pad to my friend’s DDWRT PPTP server with successful result.

The PPTP tests showed that the hAP ac^3 with v7.16.2 could only work with two PPTP clients but one failed. It seems the timing of the PPTP in hAP ac^3 is not adjusted to the right specification. MikroTik engineers may help to improve it.

Since I am a user of MikroTik for 14 years, I have only the basics of ReuterOS. It is supposed to MikroTik engineers’ jobs.

The machine is Huawei pad. I have Wireshark but I do not how to capture the required data. When the PPTP client started the connection, there was no log displayed but it only showed the connection failed.

I used WireGuard to one of my friend’s router, then I switched to WinBox to hAP ac^3.

The next step is L2TP/IPsec.

19

In the meantime, I have set up a PPTP server on one of my CHRs running 7.16.2 on a public address, and with a Windows 10 client just 500 km away behind a NAT the experience is same like yours, it just works. But before I configured the NAT at the client side properly, it didn’t work, and both the client and the server were so stubbornly retrying that I find it hard to believe that the reason could be timing issues.

You are right that it is the job of the Mikrotik developers to fix issues, but to make them even start thinking about it, you would have to provide them with a strong evidence (= pcap files from both ends ans supout.rif from the Tik), proving that each party receives everything the other party sends and nevertheless the connection does not establish. The DDWRT is most likely not on the same ISP like your Tik, so there is enough space for doubt. If you could provide the supout and pcaps both from a working Mikrotik running 6.49.13 and from a non-working Mikrotik running 7.16.2 on the same public address, it would be an unambiguous proof. But even if you manage to prove your point, I assume the priority will be very low as the security of PPTP is really far below today’s requirements. So think of it, and if it is worth it and you can collect the evidence, file a support ticket on Mikrotik ServiceDesk, providing all the evidence files as attachments to the ticket.


Just let the Wireshark capture on the correct interface with a capture filter host pptp.ser.ver.ip. But if you cannot run Wireshark directly on the Huawei pad, running a sniffer on the router through which the Huawei pad is connected to the internet should be sufficient - as you use Mikrotik for longer than me, I assume your shelves are full of retired boxes that are nevertheless sufficient as sniffing boxes for this kind of test.

BTW, am I right to assume that all the three devices you used for the test were connected the same way, via the same local WiFi?


You can either sniff directly into a file on the hAP ac3 or save the sniffer buffer into a file after finishing sniffing, and then you can download the file using Winbox.


OK, let’s try that one, same procedure - sniff on the hAP ac3 for ports UDP 500 and 4500 and see what that shows.
/tool sniffer quick protocol=udp port=500,4500 - start like this and once you are sure which address is the one from behind which the client connects, add it to the filter conditions to eliminate the noise from the scanbots.

And show me the result of /ip firewall filter print chain=input once you set the firewall up for L2TP/IPsec.

20

The L2TP/IPsec tests were also satisfied. I am sorry for not showing experimentation results. The I2TP/IPsec RouterOS scripts were showed in the first thread. Besides the the three machine passed the L2TP/IPsec tests, two additional machines iPhone and iPad passed it.

I thank sindy for you kind kelp and your advice. I shall re-look again your reply and some how to think the questions. I wish have a very good and happy new year.