L2TP IPSec Client to Site setup

RouterOS General
1

Hello all,

So I been sitting with this one for some time now. Reading the following
https://wiki.mikrotik.com/wiki/Manual:Interface/L2TP,
https://blog.johannfenech.com/mikrotik-l2tp-ipsec-vpn-server/,
https://www.cloudbrigade.com/mikrotik-l2tp-vpn-setup/,
https://jcutrer.com/howto/networking/mikrotik/l2tp-over-ipsec-troubleshooting
and watching videos to help me set this up.

This is not a Site-to-Site L2TP IPSec VPN but a Client to Site setup.

Basic drawing

Router 1 will be the Site all Remote clients will connect to. I am currently sitting behind Router 2
Router 1 and Router 2 is Factory reset and both running firmware 6.44.5 LTS

Base setup of Router 1

# model = 750
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip pool
add name=dhcp ranges=192.168.1.2-192.168.1.5
/ip dhcp-server
add address-pool=dhcp disabled=no interface=bridge name=defconf
/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
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
/ip address
add address=192.168.1.1/24 comment=defconf interface=ether2 network=192.168.1.0
/ip dhcp-client
add comment=defconf dhcp-options=hostname,clientid disabled=no interface=ether1
/ip dhcp-server network
add address=192.168.1.0/24 comment=defconf gateway=192.168.1.1 netmask=24
/ip dns
set allow-remote-requests=yes
/ip dns static
add address=192.168.1.1 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=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN
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 nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WA
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN

The following, working from base setup above, is my attempts to make the L2TP IPSec VPN work.
Attempt 1

/interface l2tp-server server set enabled=yes use-ipsec=required ipsec-secret=Test
/ip pool add name=L2TP_pool ranges=192.168.1.10-192.168.1.15
/ppp profile add name=ipsec_vpn local-address=192.168.1.1 remote-address=L2TP_pool
/ppp secret add name=Test password=password service=l2tp profile=ipsec_vpn
/ip firewall filter add action=accept chain=input protocol=udp dst-port=500,1701,4500 in-interface=ether1 comment="Allow L2TP VPN (500,4500,1701/udp)"

Attempt 2

/ppp profile add name=ipsec_vpn local-address=192.168.1.1 dns-server=192.168.1.1
/interface l2tp-server server set enabled=yes default-profile=ipsec_vpn authentication=mschap1,mschap2,chap
/ip ipsec policy set [ find default=yes ] src-address=0.0.0.0/0 dst-address=0.0.0.0/0 protocol=all proposal=default template=yes 
/ip ipsec peer add exchange-mode=main passive=yes name=l2tpserver
/ip ipsec identity add generate-policy=port-override auth-method=pre-shared-key secret=Test peer=l2tpserver
/ip ipsec proposal set default auth-algorithms=sha1 enc-algorithms=3des pfs-group=modp1024
/ppp secret add name=Test password=password service=l2tp profile=ipsec_vpn remote-address=192.168.1.15
/ip firewall filter add chain=input action=accept protocol=udp port=500,1701,4500 comment="Allow L2TP VPN (500,4500,1701/udp)"
/ip firewall filter add chain=input action=accept protocol=ipsec-esp comment="Allow L2TP VPN (ipsec-esp)"

Attempt 3

/interface l2tp-server server set enabled=yes authentication=mschap1,mschap2,chap use-ipsec=required ipsec-secret=Test
/ip pool add name=vpn_pool ranges=192.168.1.10-192.168.1.15 comment="L2TP VPN IP Pool"
/ppp profile add name=ipsec_vpn local-address=192.168.1.1 remote-address=vpn_pool
/ppp secret add name=Test password=password service=l2tp profile=ipsec_vpn
/ip firewall filter add action=accept chain=input protocol=udp dst-port=500,1701,4500 comment="Allow L2TP VPN (500,4500,1701/udp)"
/ip firewall filter add action=accept chain=input protocol=ipsec-esp comment="Allow L2TP VPN (ipsec-esp)"

The results are the same with all three attempts

  1. Connection is establish, Router 1 shows that the connection is made. Remote PCs VPN NIC gets an IP within Router 1s LOCAL range (192.168.1.0/24)
  2. Both Client and Remotes firewalls are off for testing of connection (normal Windows Firewall is used)
  3. I cannot ping any Client behind Router 1 nor can I access any Shared resources from Remote side.

Any suggestion ?

2

L2TP, despite its name, is typically used in L3 mode (IP tunnel), and so it is in your case. So the explanation and advice what to do is here (unlike with IPsec, I am sure the advice will work).

3

@sindy i just read your other Post.
Well if for example i have host A with IP 10.0.0.2 in one side of the tunnel and i want to lets say ping host B with IP of 10.0.0.3 on the other side of the tunnel, according to your Post that goes directly to the router. Generally speaking yes, but what happens in more detail is that host A since it does not have the mac Address of Host B in its arp table, it will first send an arp request on all hosts in the lan asking for the mac adress of Host B, this includes the routers ethernet port as well. No one will answer back because Host B is on the other side, BUT the router will respond and say, wait i know where Host B is, so i will forward whatever you want to Host B myself ( proxy arp ).
So, before the router is involved, as you correct say on your post, we have to mention that an arp request is first sent and then the router takes place.

4

I think that’s exactly what I wrote there:

But when the host wants to send a response, it also finds out that the IPsec client’s address 10.0.0.y is in its own subnet, so instead of sending an ARP request asking for MAC address of the default gateway (which is the Mikrotik), it sends an ARP request asking for MAC address of 10.0.0.y itself.

The L2TP (or IPSec, or PPTP, or SSTP…) client doesn’t send any ARP request as the destination IP matching the server’s LAN subnet is (hopefully!) in none of its local subnets. The device on the server’s LAN is in a different situation, as the destination address of the client fits into the LAN subnet but actually it is not there at L2, so it cannot respond to ARP, so the router has to respond on its behalf.

But like in the other topic, the easiest way out is not to use the pools from the LAN subnet to assign addresses to PPP clients. So no one expects someone else to be accessible via L2, everyone uses gateways, and there is no need to set arp=proxy-arp on VPN server’s LAN interface.

5

Okay something does not add up.
Why does none of the posts/forum that I have read mentioned ARP (enabled or disabled) ?
Why does none mention that the tunnel IP range should be in a different range ?

What I did was

/ip pool add name=L2TP_pool ranges=192.168.100.15-192.168.100.20
/ppp profile add name=L2TP_users local-address=192.168.1.1 remote-address=L2TP_pool
/ppp secret add name=Test password=password service=l2tp profile=L2TP_users
/interface l2tp-server server set enabled=yes default-profile=L2TP_users authentication=chap,mschap1,mschap2 use-ipsec=required ipsec-secret=Test
/ip firewall filter add chain=input protocol=udp dst-port=500,1701,4500 in-interface=ether1 comment="Allow L2TP VPN (500,4500,1701/udp)"

and now I can access Client side from Remote

UPDATE:
Selective access from Remote to Client side it seems…

6

Maybe because the authors of those posts didn’t get to the same situation (i.e. did not assign addresses from LAN subnet to remote clients), or they had arp=proxy-arp configured before for other reasons so they did not realize it was important for this scenario… The very first link you gave in your OP (the Mikrotik’s L2TP manual page) dedicates a whole paragraph to this issue - open it and search for “arp” on the page.

Basically the manuals typically cover in deep detail an isolated topic (that’s nothing Mikrotik-specific). The (potential) collisions/interactions with the rest of the configuration and their solutions are only added after it becomes clear that too many people fall into the same rabbit hole so it is necessary to place a warning sign next to it.


If you expect any useful reaction to this scream of surprise, you’ll have to provide more details :slight_smile:

7

Mind indicating using Attempt 1s scrip where to enable the arp=proxy-arp ? So to use scrip “as is”. For testing purposes, please

If you expect any useful reaction to this scream of surprise, you’ll have to provide more details > :slight_smile:

Did not expect any worthy reaction on that Update of mine.
The issue seem to be a Firewall related one.

8

When dealing with audience which may possibly include non-native users of your mother tongue, it is highly recommended to use lower grade elementary school level language constructs.

So out of curiosity, do you deal with RequestTracker by BestPractical? Because that’s the only place where I’ve seen the word “scrip” without the “t” in the end so far :slight_smile:

So the “script” (actually, a single line command) would be:
/interface bridge set bridge arp=proxy-arp

But there’s another misconfiguration (which may be a consequence of “imperfect” automated configuration migration from pre-6.41), your LAN IP address is attached to one of member ports of a bridge rather than to the bridge itself, so do one more thing:
/ip address set [find interface=ether2] interface=bridge
Surprisingly, the DHCP server is properly bound to the bridge.
Both changes can be done using either of the two GUIs.

9

I think that’s exactly what I wrote there…

No, before that you say that: when the client sends a packet to a device in 10.0.0.0/24, the packet is delivered to the Mikrotik

client doesn’t send any ARP request as the destination IP matching the server’s LAN subnet is (hopefully!) in none of its local subnets.

So you assume that it is not in the same subnet…!

Thats exactly where i disagree…! Ofcorse and it might be on the same subnet… Also from the host’s point of view, the host does not know if there is or not another host in the same subnet with it. So yes, it will first send an ARP request and then since there will be no responce ( in case there are no other hosts in the same subnet indeed ) the router, in case the host we look for is on the other side of the VPN will respond on behalf of that host…

10

At the L2TP/PPTP/SSTP/whatever other PPP-based client side, the IP address of its end of the tunnel is a /32 one, so from the perspective of the PPP client’s network stack, it really is not in any subnet. And as it is a point-to-point tunnel, even the address of the remote end of the tunnel is only resolved to the interface, so no ARP request is necessary.

As you can see from the configuration excerpts in the OP, there are no routes via the L2TP tunnel from the “L2TP server router” to the LAN subnet of the “L2TP client router”, so I did not deal with a situation which you probably have in mind, where a PC connected to the LAN of the client router would be pinging a PC connected to the LAN of the server router.

So if this is the scenario which you have in mind, then of course the PC client must somehow deliver the packet to the L2TP client router first. But if the LAN subnet at this client end is a different one than the LAN subnet on the server end, the PC client uses normal routing to obtain the IP address of the gateway (which is the client router’s IP in the LAN subnet) and then uses an ARP request to obtain a MAC of that gateway. But for this to work, arp=proxy-arp is not necessary, as the IP which is being ARP-requested is the client router’s own one, so it is how networking normally works and there is nothing special about it.

As for the router with arp=proxy-arp responding only if there is no other response to the ARP request, I have to disagree with you, as the router has no way to notice an absence of an ARP response to a request. The ARP request goes to a broadcast MAC address so the router can see it, but the response goes to the unicast MAC of the sender for the request, so the router cannot see it if it comes.

That’s from where my doubt whether it works in IPsec case comes: with PPP, the router knows that the ARP-requested address is in some of its connected subnets other than the one through which the ARP request has arrived, so it doesn’t need to wait whether some other device within the source subnet of the request responds to it. But I don’t know whether the router also recognizes that the ARP-requested IP is reachable through one of active IPsec policies, as I’ve never tested that so far.

11

“..lower grade elementary school level language constructs.”, Really ?


So out of curiosity, do you deal with RequestTracker by BestPractical? Because that’s the only place where I’ve seen the word “scrip” without the “t” in the end so far > :slight_smile:

No, spelling mistakes. Just a FYI Scrip in British English “a small scrap, esp of paper with writing on it” . But lets not bicker about it.


So the “script” (actually, a single line command) would be:
/interface bridge set bridge arp=proxy-arp

But there’s another misconfiguration (which may be a consequence of “imperfect” automated configuration migration from pre-6.41), your LAN IP address is attached to one of member ports of a bridge rather than to the bridge itself, so do one more thing:
/ip address set [find interface=ether2] interface=bridge
Surprisingly, the DHCP server is properly bound to the bridge.
Both changes can be done using either of the two GUIs.

Did the following

/interface bridge set bridge arp=proxy-arp
/ip address set [find interface=ether2] interface=bridge
/interface l2tp-server server set enabled=yes use-ipsec=required ipsec-secret=Test
/ip pool add name=L2TP_pool ranges=192.168.1.10-192.168.1.15
/ppp profile add name=ipsec_vpn local-address=192.168.1.1 remote-address=L2TP_pool
/ppp secret add name=Test password=password service=l2tp profile=ipsec_vpn
/ip firewall filter add action=accept chain=input protocol=udp dst-port=500,1701,4500 in-interface=ether1 comment="Allow L2TP VPN (500,4500,1701/udp)"

Seems to work.
Now the question that comes to mind for “best practice” .
Should /interface bridge set bridge arp=proxy-arp be used OR should the Remote side get a different IP range as the Client side LOCAL LAN range ?

12

As for the router with arp=proxy-arp responding only if there is no other response to the ARP request, I have to disagree with you, as the router has no way to notice an absence of an ARP response to a request

As i said erlier, when an arp request is sent, IF no other host responds to that ARP request AND IF that host is known from the router, then the router responds to that arp request with its own mac address. I never said that the router will respond because no one else did. It will respond because it knows the host we seek.
If you still disagree you should read an example of proxy arp like the one here : https://wiki.mikrotik.com/wiki/Manual:IP/ARP#Proxy_ARP

13

Not exactly. Router with proxy ARP enabled will respond to request if it has route to destination (except default one and connected subnet where both source and destination addresses are). And it will respond even when other host responds, simply because it won’t know about response from other host, because that is sent directly to MAC address from where the request came.

14

I don’t think there is any best common practice in the jungle. To my understanding, the whole idea of assigning addresses from LAN subnet to remote PPP clients comes from the fact that at least during some epoch in the past, Windows firewalls looked more favorably to incoming traffic whose source IP matched into the subnet of the interface through which it was coming than to incoming traffic from elsewhere; whether it is still the case as of today is out of my knowledge. For sure, the arp proxy mechanism does NOT forward messages sent to the broadcast address of the LAN subnet to PPP clients, so all those SSDP etc. packets do not reach the PPP clients even if arp proxy is activated.

The arp proxy mechanism is available and is nothing Mikrotik-specific, so if the above motivation, or any similar one, is relevant to you, feel free to use it. If you don’t have any reason to give out addresses from LAN subnet to PPP clients, save your future self the associated headache by not doing so.


Those being taught, not those being actually used by pupils :slight_smile:

There was a nice article on this somewhere on LinkedIn, explaining that native English speakers don’t realize that some people in the audience may be unable to understand but in order not to “lose face” (which is a big deal in some cultures), they pretend to do, so the speaker gets no real feedback about what they understood and what they did not, and it leads to all sorts of trouble later on.

My problem with your sentence was not the word “scrip” itself, although that’s what you seem to have concluded, but rather with the whole sentence “Mind indicating using Attempt 1s scrip where to enable the arp=proxy-arp”

Only after reading it multiple times now I’ve understood that it actually says “Would you mind to indicate, based on the script configuration export named Attempt1 in the OP, where to…”

My years-long experience says that any attempt to be brief in written communication always causes more typing in the grand total :slight_smile:

15

@Zacharias,

the bold part in what you wrote below

means to me exactly the same as the bold part in what you “never said”:

In another words, I mean the same what @Sob wrote - the “if no other host responds” part is beyond the router’s knowledge, hence it is not relevant for its decision whether to answer or not.

16

Well the shared resources are Mapped on the Remote side so will see how it gos with ARP enabled for a period of time.
Not in the mood to create/change any firewall rules on the Mikrotik to allow traffic from one Range to another.
Having a hard time configuring the darn thing as is. Only have about a months hands on experience with the thing.


Those being taught, not those being actually used by pupils > :slight_smile:
There was a nice article on this somewhere on LinkedIn, explaining that native English speakers don’t realize that some people in the audience may be unable to understand but in order not to “lose face” (which is a big deal in some cultures), they pretend to do, so the speaker gets no real feedback about what they understood and what they did not, and it leads to all sorts of trouble later on.
My problem with your sentence was not the word “scrip” itself, although that’s what you seem to have concluded, but rather with the whole sentence “Mind indicating using Attempt 1s scrip where to enable the arp=proxy-arp”
Only after reading it multiple times now I’ve understood that it actually says “Would you mind to indicate, > based on the > script > configuration export named Attempt1 in the OP> , where to…”

My years-long experience says that any attempt to be brief in written communication always causes more typing in the grand total > :slight_smile:

The only thing that I concluded was that I found it amusing the way you expressed yourself with the “… lower grade…” remark.
I am not a native English speaking person :slight_smile: and yes some things does get lost in translation and open for interpretation when one try to convey things using text. But this can be said using any language native or not.

17

If you read again what you posted above, my words are : AND IF that host is known from the router
So instead of being negative again and again, i clearly say that this will happen IF IF IF IF the router knows where that host is !
If no other host responds is said because if obviously there is a host who responds then the router has nothing to do! So, on the other hand if the router responds it means obviously that no other host did, because it is not in the LAN, AND the router knows where that host is!
And the sad part is that you totally ignore it because it suites better to you. It is obvious you just dont like it when someone disagrees with you!

I hope you took a look at the example in the wiki… or maybe not because you are too good and you know better… :laughing:

18

So what’s your native language if I may ask? Let’s put it this way, I think I can recognize people from my own language group quite reliably by the typical mistakes they make in written English, but you don’t seem to fit into that pattern :slight_smile:

19

@Zacharias, I don’t mind if someone disagrees with me (if nothing else, it is helpful to develop yourself to have people who disagree with you), and I also have no problem to admit (in written :slight_smile: ) that I was wrong - you can find cases like this also here on the forum. Also, I did read the part of the manual you’ve linked to.

But wasn’t formal logic invented in Greece?

If arp=proxy-arp on an interface, the router responds to ARP requests coming in through that interface if the requested IP address is in one of “connected subnets” on the router’s other interfaces than the one through which the ARP request came in. And that’s all, the response of the router doesn’t depend on anything else. And that’s what is stated in the manual as well.

What I keep disagreeing with you about is that what you wrote suggests that the router uses some information regarding the position and availability of the host in behalf of which it responds the ARP request, and it is not the case.

So back to formal logic, you wrote:

IF no other host responds to that ARP request AND IF that host is known from the router, then the router responds

So let’s reduce it the following way:

IF (a is true) AND IF (b is true) THEN router responds.

This is different from just

IF (b is true) THEN router responds.

Do you agree with me on this formal level?

If you do: what I keep saying is that the “IF (a is true) AND” part is actually irrelevant.

20

Or in different way, let’s say you have router with default 192.168.88.1/24 on LAN. Then you have “client” 192.168.88.10/24 and “server” 192.168.88.20/24 connected to same LAN. But for some reason you add different route to server on router (/ip route add dst-address=192.168.88.20 gateway=) and enable proxy ARP on LAN interface. It doesn’t make much sense for real life use, when you have that address in LAN, but it’s possible. When client sends ARP request “tell me, who has 192.168.88.20?”, what do you think will happen? Client will get responses from both server and router. That’s the part we disagree with you about - if you enable proxy ARP, router doesn’t care whether something else responded or not.