MikroTik

Posted: **Sat Aug 25, 2018 12:00 am**

It took me today quite a long time to found a solution to the issue with establishing VPN connectivity from Windows 7/10 to MikroTik router using L2TP/IPSEC protocol, so I'm sharing solution.

Configuration description:
- 2011 router with RouterOS v6.42.7 behind NAT & with DNAT set up for being accessible on public ip
- Windows 7 & Windows 10 PCs behind NAT
- L2TP VPN with IPSEC set up

Symptoms
- VPN client on Ubuntu Linux works fine
- VPN client on Windows 2008 works fine
- VPN clients on Windows 7 / 10 does not establish phase 2 of IPSEC connection setup

Issue was related to incorrect of douple-NATed connections in Windows 7 / 10.
Solution was to change UDP encapsulation set-up in Windows via registry key as described in below KB:

https://support.microsoft.com/pl-pl/hel ... in-windows

Issue is solved now, I'm writing this post to have reference in the future, if I need to solve similar issue

I hope it will be useful for somebody

Thanks
Ser@fin

Posted: **Sun Aug 26, 2018 10:13 am**

Another way is to do a dirty trick on the Mikrotik itself and make the IPsec peer for the L2TP connections think that it is running on the public IP behind which it is actually connected. This way, the clients can see the server as running directly on a public address and thus the Windows clients connect successfully even with the default setting.

Posted: **Fri Apr 19, 2019 11:32 pm**

Hi, could someone please give more detail on the "dirty trick" mentioned above.

Posted: **Wed Apr 24, 2019 2:09 pm**

Hi, could someone please give more detail on the "dirty trick" mentioned above.

May it be myself? I've thought I've described it in detail enough, but obviously I haven't...

The overall architecture is as follows:

ascii-art code

_           other router/modem                    Mikrotik
 )            ,------------,                  ,-------------,
  )    etherE |   dst-nat  | etherI    etherW |   dst-nat   |
  )-----------O  e.e.e.e   O------------------O  i.i.i.i    |
  )   e.e.e.e | -> i.i.i.i |          i.i.i.i | -> e.e.e.e  |
_)            '------------'                  |             |
                                              |  O br-aux   |
                                              |  e.e.e.e/32 |
                                              '-------------'

The other modem has a public (external) address e.e.e.e from the ISP. It by default src-nats whatever comes from its LAN (i.e. via etherI) to this address, and you manually configure a dst-nat on it towards the private (internal) address of the Mikrotik on the LAN, i.i.i.i. The dst-nat works either selectively for UDP port 500, UDP port 4500 and ESP or as a DMZ (De-Militarized Zone, i.e. regardless protocols and ports). Except the ESP, it is the same setup you would use without any dirty trick at Mikrotik side.

The dirty trick is that you create an /interface bridge name=br-aux, assign no member ports to it, and assign to it the public address the external router has got from the ISP, e.e.e.e/32. In fact you can attach e.e.e.e/32 even directly to the WAN interface (etherW) as a secondary address, but the use of br-aux makes it look less confusing. Next, you set up an "inverse" dst-nat rule, restoring the destination address i.i.i.i of packets received from the external router back to e.e.e.e. If you expect the Mikrotik to ever act as an initiator or you expect the external initiators to be on public IPs without NAT on their side, you have to add also src-nat rules to the Mikrotik so that packets sent with e.e.e.e as source address would be src-nated to i.i.i.i before leaving through etherW so that the external router wouldn't reject them.

And finally, you tell the IPsec peer on Mikrotik to use e.e.e.e by setting it as its local-address parameter and by setting it as pref-src of the default route.

Posted: **Fri Jul 26, 2019 6:17 pm**

Thank you

Posted: **Tue Jan 26, 2021 2:34 pm**

Hi, could someone please give more detail on the "dirty trick" mentioned above.
May it be myself? I've thought I've described it in detail enough, but obviously I haven't...

The overall architecture is as follows:
ascii-art code
_           other router/modem                    Mikrotik
 )            ,------------,                  ,-------------,
  )    etherE |   dst-nat  | etherI    etherW |   dst-nat   |
  )-----------O  e.e.e.e   O------------------O  i.i.i.i    |
  )   e.e.e.e | -> i.i.i.i |          i.i.i.i | -> e.e.e.e  |
_)            '------------'                  |             |
                                              |  O br-aux   |
                                              |  e.e.e.e/32 |
                                              '-------------'
The other modem has a public (external) address e.e.e.e from the ISP. It by default src-nats whatever comes from its LAN (i.e. via etherI) to this address, and you manually configure a dst-nat on it towards the private (internal) address of the Mikrotik on the LAN, i.i.i.i. The dst-nat works either selectively for UDP port 500, UDP port 4500 and ESP or as a DMZ (De-Militarized Zone, i.e. regardless protocols and ports). Except the ESP, it is the same setup you would use without any dirty trick at Mikrotik side.

The dirty trick is that you create an /interface bridge name=br-aux, assign no member ports to it, and assign to it the public address the external router has got from the ISP, e.e.e.e/32. In fact you can attach e.e.e.e/32 even directly to the WAN interface (etherW) as a secondary address, but the use of br-aux makes it look less confusing. Next, you set up an "inverse" dst-nat rule, restoring the destination address i.i.i.i of packets received from the external router back to e.e.e.e. If you expect the Mikrotik to ever act as an initiator or you expect the external initiators to be on public IPs without NAT on their side, you have to add also src-nat rules to the Mikrotik so that packets sent with e.e.e.e as source address would be src-nated to i.i.i.i before leaving through etherW so that the external router wouldn't reject them.

And finally, you tell the IPsec peer on Mikrotik to use e.e.e.e by setting it as its local-address parameter and by setting it as pref-src of the default route.

Hi! I was looking at the Dirty Nat Trick that I can use to set up my L2TP/IPSec when my VPN (MikroTIk Server) is behind NAT (ISP Router) I have not yet quite being able to make it work as I am stuck in when to apply the 'Inverse' NAT rule for incoming packets i.i.i.i. to be restored as 'Public IP Address' or e.e.e.e. I already set up the IP Address e.e.e.e/32 associated with the br-aux interface however when I want to create the Bridge NAT Rule on chain I select: dstnat but from there I am in blank, Also when I click the option (IP) under chain, it appears greyed out, I am not sure how to set up the Inverse NAT rule, I am new in Networking and so far I know the idea behind this dirty trick! It is a clever idea tbh! Thank you!

Posted: **Mon Aug 23, 2021 10:07 pm**

I don't recommend having this dirty trick - makes me lots of troubles trying to connect via SSH

Posted: **Mon Aug 23, 2021 10:41 pm**

It is enough to restrict the dst-nat rule to act only on protocol=udp dst-port=500,4500 so that it would affect only the IPsec incoming connections.

Plus I don't get why it should cause issues with SSH access even if the dst-nat rule is not limited to particular protocol and port, can you elaborate?

Posted: **Mon Aug 23, 2021 10:50 pm**

when I want to create the Bridge NAT Rule on chain I select: dstnat but from there I am in blank, Also when I click the option (IP) under chain, it appears greyed out, I am not sure how to set up the Inverse NAT rule

@Nickerin, sorry for a very late response, the forum stopped notifying me about this topic. I use a bridge interface for e.e.e.e/32 because it is the simplest way to create an anchor point for an IP address without any side effects, but the dst-nat rule must be in /ip firewall nat, not in /interface bridge nat.

Posted: **Tue Aug 24, 2021 6:06 am**

I’ve found the following solution for the L2TP/IPSec server behind NAT:
http://woshub.com/l2tp-ipsec-vpn-server-behind/

Posted: **Tue Aug 24, 2021 11:59 am**

@Martín, your finding is mentioned already in the OP, except that it refers to Microsoft's own KB rather than some 3rd party one.

The reason why I suggest the "forth and back NAT" approach is that it is enough to do it once at the VPN server side, whereas the registry has to be tweaked on every single client. Not a big deal for three clients, but think about tens. OK, if you have hundreds of Windows clients, you probably manage their settings centrally using a domain controller, but to do that, you need to have them online first.

Posted: **Tue Aug 24, 2021 2:28 pm**

You are right @sindy. I didn’t verify the OP link.

The issue is related only to windows. Both MikroTik, Linux and macOS (and iOS) don’t have this issue. Would this dirty trick affect connections from OS’s other than Windows 7/10?

on the other hand I agree that if it’s causing SSH issues is because another configuration (maybe not the right dst-nat rule?)

Posted: **Tue Aug 24, 2021 2:48 pm**

The dirty trick can only affect connections from clients with public addresses directly on themselves if ESP cannot be properly forwarded at the device standing between the Mikrotik server and the internet, because the NAT detection of IPsec doesn't discover any NAT and hence the SA gets established using bare ESP and no keepalive traffic gets generated.

MikroTik

Windows 7/10 & L2TP connection issue

Windows 7/10 & L2TP connection issue

Re: Windows 7/10 & L2TP connection issue

Re: Windows 7/10 & L2TP connection issue

Re: Windows 7/10 & L2TP connection issue

ascii-art code

Re: Windows 7/10 & L2TP connection issue

Re: Windows 7/10 & L2TP connection issue

ascii-art code

Re: Windows 7/10 & L2TP connection issue

Re: Windows 7/10 & L2TP connection issue

Re: Windows 7/10 & L2TP connection issue

Re: Windows 7/10 & L2TP connection issue

Re: Windows 7/10 & L2TP connection issue

Re: Windows 7/10 & L2TP connection issue

Re: Windows 7/10 & L2TP connection issue