I am new vpn user and I have configured an L2TP server with a shared key on my laptop. I have tried numerous ways like disabling of firewall but it can’t connect. Anyone can help me.

Does it stuck on "Connecting to **IP address**"? If yes then it's not Mikrotik problem. I have same issue with L2TP. On 1803 I had this issue if I had GeForce Experience installed on Windows 10. After upgrade to 1809 L2TP does not work even without GeForce Experience. Haven't tried with 1903.

It is not clear from your post, how your network is set up. I assume, L2TP server is behind router with dst-nat to this server, and you are trying to connect from Windows client. If so, Windows registry modification is required on client computer. Read this (although article is about Windows Vista, it applies to newer Windows versions)
https://support.microsoft.com/en-us/hel ... in-windows

All in all, @CalvinSteel, please describe your overall setup at server and client side and what exactly the Windows client complains about, as it's all just guessing.

@karlisi, it is possible to run an LT2P/IPsec server on a Mikrotik behind a NATing device even without tweaking the Windows registry, the price to pay is that the clients then cannot have public IPs directly on themselves. Even that limitation can be circumvented along with the other limitation of just one client behind each public IP, but the configuration becomes quite complex in that case.

it is possible to run an LT2P/IPsec server on a Mikrotik behind a NATing device even without tweaking the Windows registry, the price to pay is that the clients then cannot have public IPs directly on themselves.

How? We have many sites with Windows clients behind src-nat and l2tp/ipsec server behind dst-nat, never able to connect without registry patch.

How? We have many sites with Windows clients behind src-nat and l2tp/ipsec server behind dst-nat, never able to connect without registry patch.

1. (optional for clarity) add a bridge interface with no member ports
2. attach the public IP of the NAT behind which the server Mikrotik lives to an interface on the Mikrotik as a /32 one (normally to the portless bridge one created above, but you can use any interface)
3. /ip firewall nat
   print chain=dstnat where !dynamic
   add chain=dstnat place-before=0 action=dst-nat protocol=udp dst-port=500,4500 in-interface=your-wan-interface \
   to-addresses=the.public.ip.mentioned.above
4. enjoy

With this "forth and back dst-nat" setup, the local address of the IPsec responder is the same like the source address from which the packets actually arrive to the initiator, the NAT-T concludes that there is no NAT at server side. Therefore, if there is no NAT at initiator side either, the peers conclude they can use ESP, which is an issue if you cannot configure forwarding of ESP to the Mikrotik at the NAT at the Mikrotik end.

If you need to be able to connect several L2TP/IPsec clients from behind the same client-side NAT, read this.

It is not clear from your post, how your network is set up. I assume, L2TP server is behind router with dst-nat to this server, and you are trying to connect from Windows client. If so, Windows registry modification is required on client computer. Read this (although article is about Windows Vista, it applies to newer Windows versions)
https://support.microsoft.com/en-us/hel ... in-windows

Thank You! I hope it will help me to connect but I already read too many guides on l2tp like
https://www.vpngate.net/en/howto_l2tp.aspx
https://www.expressvpn.com/what-is-vpn/protocols/l2tp
https://bit.ly/3cuLyuC

but still nothing. Now I read microsoft support guide and hope to get better solution.

1. (optional for clarity) add a bridge interface with no member ports
2. attach the public IP of the NAT behind which the server Mikrotik lives to an interface on the Mikrotik as a /32 one (normally to the portless bridge one created above, but you can use any interface)
3. /ip firewall nat
   print chain=dstnat where !dynamic
   add chain=dstnat place-before=0 action=dst-nat protocol=udp dst-port=500,4500 in-interface=your-wan-interface \
   to-addresses=the.public.ip.mentioned.above
4. enjoy

With this "forth and back dst-nat" setup, the local address of the IPsec responder is the same like the source address from which the packets actually arrive to the initiator, the NAT-T concludes that there is no NAT at server side. Therefore, if there is no NAT at initiator side either, the peers conclude they can use ESP, which is an issue if you cannot configure forwarding of ESP to the Mikrotik at the NAT at the Mikrotik end.

OK, I need to test this. The main concern is about the same public IP to 2 separate interfaces, WAN and L2TP fake bridge. Or I am missing something?

The main concern is about the same public IP to 2 separate interfaces, WAN and L2TP fake bridge. Or I am missing something?

I'm not sure I understand your concern. The public /32 IP will exist on the Mikrotik only once, and you can choose whether you attach it to a dedicated interface (the port-less bridge), to the WAN, or to another interface. If your Mikrotik's WAN was connected to internet directly, you wouldn't need this trick.

The kernel accepts packets for any local IP regardless the interface they came in through, and the IPsec stack responds from the same address to which the initial request of the IKE session has arrived. Connection tracking and the dst-nat rule ensure that the initial request which came in to the private IP of the WAN will be seen as coming to the public IP by the IPsec stack and that the external NAT box will see the responses of the IPsec stack sent from the public IP as coming from the private IP of Mikrotik's WAN. Only for connections initiated locally the source address is chosen depending on the out-interface chosen by routing or, if set, the pref-src of the route. So if your NAT box between the Mikrotik and the internet supports ESP forwarding, you need to make sure that if the first ESP packet is eventually sent by the Mikrotik (I don't remember the L2TP initial exchange), it will be sent from the private IP attached to the WAN or src-nated to it, so that the external NAT box would see it coming from its LAN subnet. And you need to care about this latter point only if there is a chance that clients running on public IPs will connect. As said earlier, if the external NAT box cannot forward ESP, the complex setup for multiple clients behind the same public IP forces a "client-side" NAT into the path and thus eliminates ESP from the scenario even if the client is actually running on a public IP.

Ah, I see, I should explain better. l2tp server is running on other Mikrotik device behind Mikrotik router.
In this setup VPN can't connect without Windows registry modification.

All the setup I've described is relevant to the "inner Mikrotik" (the one running the L2TP/IPsec server farther away from the internet uplink) - the "outer Mikrotik" is considered a 3rd party NAT box here.

But as the 3rd party NAT box is actually a Mikrotik, it does support ESP forwarding through NAT, so you can use another dst-nat rule on the outer Mikrotik to forward not only UDP ports 500 and 4500 but also ESP from the WAN to the inner Mikrotik. Of course this means you cannot use IPsec on the outer Mikrotik (or, more precisely, you can with limitations and if you take very specific measures).

As for the "conflict" between the same public IP being up on both Mikrotiks, the inner one doesn't know that the same address is up on the outer one and vice versa, so there is no conflict. The outer Mikrotik dst-nats its own WAN public IP to the private WAN IP of the inner one, and the inner Mikrotik dst-nats it back to the same public IP, but in its local context the word "back" has no relevance.

I assume you have good reasons to take all this burden (registry tweaking or implementing my trick) rather than running the L2TP/IPsec directly on the outer Mikrotik.

I assume you have good reasons to take all this burden (registry tweaking or implementing my trick) rather than running the L2TP/IPsec directly on the outer Mikrotik.

Don't want to enable proxy-arp on LAN interface, to access devices on internal network.

Don't want to enable proxy-arp on LAN interface, to access devices on internal network.

Well, doing so is only necessary if you assign IP addresses from the LAN subnet to the PPP (L2TP and other) clients, as in that case the clients in LAN subnet send ARP requests for the PPP clients' IPs rather than using the gateway. So if you use two adjacent subnets which can be covered by a common 1-bit-shorter mask (such as 192.168.0.0/24 and 192.168.1.0/24 which together fit into 192.168.0.0/23), you can use one of them for LAN clients and the other one for PPP clients so that you didn't need the proxy-arp, but you can refer to both using a common dst-address and src-address matchers in the firewall where you want to give the same treatment to both groups (but hey, we have the /ip firewall address-list to group together non-adjacent subnets and ranges).

@calvinsteel, sorry for hijacking the topic, I hope we'll be able to help you with the original issue once you provide more information.

Thanks, I will test it.

And yes, this should go to separate topic

This is the solution:

https://www.youtube.com/watch?v=_c3a4Kr ... e=youtu.be

This is the solution:

Maybe you should write that this is in spanish?
Also no need for posting the same multiple places.

Don't mean to hijack the thread but it seems to make sense to keep discussion regarding a specific issue in one place rather than multiple threads.....

I have the same issue, but only with some devices. I have two Fujitsu laptops and a Fujitsu tablet, as well as a galaxy note 9 which all connect to out l2tp with pre-shared key just fine. It doesn't matter if they are batted behind a router or directly connected... Or even using internet connection sharing from my Note to my tablet ot laptop. All are completely current on windows updates. Meanwhile I have two users, one with an hp laptop and another with a surface device, also with latest updates, and they won't connect. I disabled the firewall completely to see if that was the issue... No joy. I've tried their devices on my ics from my Note 9...no joy... While the note 9 itself of my Fujitsu devices all connect without a hitch. I've used my devices and connected just fine on their connections, they can't connect on mine. Ive verified that all of the VPN settings in windows match my devices, and this has been a problem for several months. I've tried numerous suggestions from various threads. No joy there either.

At this point I'm stumped. It seems to me that something with the network adapters themselves... Although I don't know what since we've tried both wireless and ethernet on all devices.

I have the same issue, but only with some devices.

What's "the same" in particular? Is your L2TP/IPsec server running on Mikrotik which doesn't have a public IP on itself and it is connected to the internet via some external NAT device with port forwarding?

If yes, I suggest the trick I've suggested above, making the server side to seem to run on a public IP even though it actually doesn't (and if needed, i.e. if ESP cannot be forwarded on the server-side NAT, there is one more trick to make the client side seem to run on a private IP even though it actually runs on a public one). Or you may set the registry the way suggested in that lengthy video above, it doesn't matter much that it is not in English. That would mean that this setting has been already done on the devices which work.

If not, it needs debugging (using packet sniffing and/or logging on the Mikrotik) to find out what is actually wrong. In some other topics here on the forum, a removal and re-creation of the VPN connection on the Windows side was recommended and turned out to really help if I remember right, but better google that topic up, maybe more was necessary to do than just remove and re-create the single VPN connection.