L2TP Endpoint inside Intranet

RouterOS General
1

I am trying to set up MikroTik device (433AH) as an L2TP client inside my Intranet. My internet provider already gives me a NAT-ed LAN so I have no choice (otherwise I would put the MikroTik device as my firewall).

Here is the picture that describes it:

L2TP client inside Intranet.jpg
L2TP client inside Intranet.jpg960×540 16.3 KB

The problem is in the rightmost box of the picture. I set up an L2TP client and it works fine (I can access 192.168.2.x from 192.168.4.x). However, I cannot access 192.168.2.x from 192.168.3.x. In the configuration of this Routerboard 433AH device there is nothing that specifically prevents the L2TP client interface be accessible from its left side but allows it from the right side. All I have in my routes added is:
3 A S 192.168.2.0/24 my-l2tp-client-interface 1

Here are all my routes (used /ip route print):

DST-ADDRESS PREF-SRC GATEWAY DISTANCE

0 ADS 0.0.0.0/0 192.168.3.1 0
1 ADC 192.168.3.0/24 192.168.3.5 ether1 0
2 ADC 192.168.4.0/24 192.168.4.1 LAN 0
3 A S 192.168.2.0/24 my-l2tp-client-interface 1
4 ADC 192.168.2.1/32 192.168.2.253 my-l2tp-client-interface 0

I presume that since ether1 is the client L2TP endpoint, it should not allow access to the 192.168.2.0/24 network, but in my case, I would like to allow it. There is nothing that prevents this, so I am presuming there is something built in the RouterOS L2TP implementation that prevents this. If so, is there a way to override this and have my L2TP client endpoint inside my Intranet? How can I achieve this?

Please help,
Jordan

2

Anybody there? Pls help!

3

Do the providers on both ends give you global unicast IPv6?

That said you likely need to tell the “Dumb Router, 192.168.3.1” to send packets destined for 192.168.2.0/24 to your MikroTik at 192.168.3.5. An alternative would be to tell the clients on the 192.168.3.0/24 segment to use 192.168.3.5 to reach 192.168.2.0/24, static routes in the event you don’t control “Dumb Router.”

4

Thank you idlemind, but that is already done and they still cannot see 192.168.2.x. Specifically:

  • L2TP connection is already established and it works. The end-poins are on the picture above.
  • Clients connected to 192.168.4.x with default gateway 192.168.4.1 can ping 192.168.2.x OK. This works as expected.
  • Clients connected to 192.168.3.x with default gateway 192.168.3.5 cannot ping 192.168.2.x! Why? This is not expected considering my routes printed in my original post.
    I suspect there is something built in the L2TP client implementation in RouterOS, so that it does not allow access to the other side of the tunnel from the endpoint. Can I circumvent this and allow clients connected to 192.168.3.x with default gateway 192.168.3.5 to access 192.168.2.x via the tunnel?

Also please forget about IPv6 - I am not interested in such workaround.

BTW, I am trying this on RB433AH, RouterOS version 6.38.5, firmware version 3.24, but I believe the question is general for all RouterOS.

This is very important question because without its answer it is impossible to build a WiFi access point which is an L2TP Client End-point to both the wired and the wireless clients.

There is nothing in my route “3 A S 192.168.2.0/24 my-l2tp-client-interface 1” that ALLOWS clients from 192.168.4.x and PREVENTS clients from 192.168.3.x accessing 192.168.2.0. It should allow anyone access to 192.168.2.0!

Can someone from MikroTik take a look at this? It is not a routing table mistake. I am positive it is something RouterOS L2TP Client implementation specific.
Please help!

5

Any routes on the L2TP server for 192.168.3.0/24? You may need to tell it to use the L2TP interface for traffic destined to 192.168.3.0/24.

Also you’re using a policy based VPN. You may want to run GRE wrapped in IPSec. I find it easier to manage traffic paths this way.

6

Thanks for that thought idlemind, but :
The L2TP Server is a dynamically created interface, a nice feature of RouterOS. It is assigning the addresses from a VPN pool to each connected client. I have that pool on the same Class C net with the LAN (on the server side) and it’s NAT-ing everything. This works well for ANY client that connects. Namely, there is no mention of 192.168.4.x nor 192.168.3.x anywhere in the configuration of the L2TP server (and yet it works for 192.168.4.x and it does not for 192.168.3.x). It does not care who connects - it just masquerades the incoming connection and routes back the responses to it. So, I am concluding the problem is not in the L2TP server routes.

I even created an analogous situation on my Mac OS X and it does exactly what I expect (replaced the RB433AH / L2TP client with a Mac Pro which has 2 Ethernet ports and BTW, Mac OS has built-in L2TP client implementation). The client network is accessible from both ports (the one where the L2TP client end-point is, as well as the other one). This PROVES that the problem is RouterOS specific.

Could anyone from MiktoTik take a look at this?

7

I just spun up CHRs in GNS3 and it works just fine with L2TP. I didn’t add IPSec on but that shouldn’t affect the traffic in any way. If you post your configs in more detail we can see if we can figure out what is different. An alternative would be to spin up CHRs in a virtual environment, KVM, VMWare, GNS3, etc… and replicate your config. As far as your question goes. It seems fully possible and does in fact work. Nothing that MIkroTik is doing by default would disallow the traffic like you are seeing.

A good start would be looking at the firewall filters on your equivalent of rtr-c.
MikroTik-Forums_1.png
3 VPCS instances, A1 at the head end (server), B1 in the middle on the client side and C1 behind the MikroTik acting as the client.
MikroTik-Forums_6-pings.png

[admin@rtr-a] > ppp secret print detail 
Flags: X - disabled 
 0   name="tun" service=l2tp caller-id="" password="123" profile=default local-address=172.16.1.1 
     remote-address=172.16.1.2 routes="10.1.3.0/24 172.16.1.2 1,10.1.4.0/24 172.16.1.2 1" limit-bytes-in=0 
     limit-bytes-out=0 last-logged-out=apr/03/2017 07:11:47




[admin@rtr-c] > interface l2tp-client print 
Flags: X - disabled, R - running 
 0  R name="l2tp-out1" max-mtu=1450 max-mru=1450 mrru=disabled connect-to=192.168.1.2 user="tun" password="123" 
      profile=default-encryption keepalive-timeout=60 use-ipsec=no ipsec-secret="" allow-fast-path=no 
      add-default-route=no dial-on-demand=no allow=pap,chap,mschap1,mschap2
8

Wow idlemind, you went out of your way to help - thank you.

I see yours works, but mine does not. Let’s look at the differences:

  1. L2TP Server: you have routes back to the L2TP client, I achieve the same with masquerading (LAN and VPN pool in the same segment). I don’t see anything that makes a difference.
    2 L2TP Client: you have “use-ipsec=no” and I am using IPSEC. Could you turn on IPSEC and try again? Why? - I suspect that in the L2TP client implementation in RouterOS they are preventing clear-text access to the VPN endpoint in order to prevent accidental encrypted tunnel that ends up “spilling the beans” on the internet.

If you could, please turn on IPSEC and try. We are getting closer.

Thanks,
J.

9 
[admin@rtr-a] > interface l2tp-server server print     
            enabled: yes
            max-mtu: 1450
            max-mru: 1450
               mrru: disabled
     authentication: pap,chap,mschap1,mschap2
  keepalive-timeout: 30
       max-sessions: unlimited
    default-profile: default-encryption
          use-ipsec: yes
       ipsec-secret: Encryption123!
    allow-fast-path: no
[admin@rtr-a] > ip ipsec installed-sa print 
Flags: A - AH, E - ESP 
 0 E spi=0x7B7B1 src-address=192.168.2.2:4500 dst-address=192.168.1.2:4500 state=mature auth-algorithm=sha1 enc-algorithm=aes-cbc enc-key-size=256 auth-key="27aa78904b61a7c2244c7a6f485c84ff0bb2f12a" 
     enc-key="9661d44f9044f6bd0580b145c5b1b38bfa444318e8ddc5bde9a5282f1707909d" addtime=apr/03/2017 13:51:16 expires-in=29m3s add-lifetime=24m/30m current-bytes=801 replay=128 

 1 E spi=0x213A8AC src-address=192.168.1.2:4500 dst-address=192.168.2.2:4500 state=mature auth-algorithm=sha1 enc-algorithm=aes-cbc enc-key-size=256 auth-key="da4b3312380ec8f0041c4024cd2428b48dbf33ed" 
     enc-key="cec45b3a947e7430b7ee23244a46c3f1f25a88a44795408ead486a0e8df6f501" addtime=apr/03/2017 13:51:16 expires-in=29m3s add-lifetime=24m/30m current-bytes=518 replay=128




[admin@rtr-c] > interface l2tp-client print detail 
Flags: X - disabled, R - running 
 0  R name="l2tp-out1" max-mtu=1450 max-mru=1450 mrru=disabled connect-to=192.168.1.2 user="tun" password="123" profile=default-encryption keepalive-timeout=60 use-ipsec=yes ipsec-secret="Encryption123!" allow-fast-path=no 
      add-default-route=no dial-on-demand=no allow=pap,chap,mschap1,mschap2 
[admin@rtr-c] > ip ipsec installed-sa print 
Flags: A - AH, E - ESP 
 0 E spi=0x213A8AC src-address=192.168.1.2:4500 dst-address=10.1.3.2:4500 state=mature auth-algorithm=sha1 enc-algorithm=aes-cbc enc-key-size=256 auth-key="da4b3312380ec8f0041c4024cd2428b48dbf33ed" 
     enc-key="cec45b3a947e7430b7ee23244a46c3f1f25a88a44795408ead486a0e8df6f501" addtime=apr/03/2017 13:51:17 expires-in=29m11s add-lifetime=24m/30m current-bytes=518 replay=128 

 1 E spi=0x7B7B1 src-address=10.1.3.2:4500 dst-address=192.168.1.2:4500 state=mature auth-algorithm=sha1 enc-algorithm=aes-cbc enc-key-size=256 auth-key="27aa78904b61a7c2244c7a6f485c84ff0bb2f12a" 
     enc-key="9661d44f9044f6bd0580b145c5b1b38bfa444318e8ddc5bde9a5282f1707909d" addtime=apr/03/2017 13:51:17 expires-in=29m11s add-lifetime=24m/30m current-bytes=801 replay=128

All pings still work fine. I added the routes dynamically within the PPP secret. Although my preferred method for doing this would be GRE wrapped in IPSec with a routing protocol.

[admin@rtr-a] > ppp secret print detail 
Flags: X - disabled 
 0   name="tun" service=l2tp caller-id="" password="123" profile=default local-address=172.16.1.1 remote-address=172.16.1.2 routes="10.1.3.0/24 172.16.1.2 1,10.1.4.0/24 172.16.1.2 1" limit-bytes-in=0 limit-bytes-out=0 
     last-logged-out=apr/03/2017 07:11:47

It is likely time for you to export your firewall rules.

10

Ok, here it is ( I edited the actual addresses A.B.C.D, passwords and server names):

L2TP Server (ignore the pppoe to 10.1.1.1 - that’s how it gets internet from the provider). Note that neither “192.168.4” nor “192.168.3” appear anywhere in the configuration of this router, so the problem cannot be here:

[admin@rtr-a] > /ip route print
Flags: X - disabled, A - active, D - dynamic, 
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, 
B - blackhole, U - unreachable, P - prohibit 
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 ADS  0.0.0.0/0                          10.1.1.1                  0
 1 ADC  10.1.1.1/32        A.B.C.D         pppoe-out1                0
 2 ADC  192.168.2.0/24     192.168.2.1     ether1                    0
 3 ADC  192.168.2.253/32   192.168.2.1     <l2tp-me>                 0
[admin@rtr-a] > /interface l2tp-server server print
            enabled: yes
            max-mtu: 1460
            max-mru: 1460
               mrru: disabled
     authentication: pap,chap,mschap1,mschap2
  keepalive-timeout: 30
       max-sessions: unlimited
    default-profile: default-encryption
          use-ipsec: yes
       ipsec-secret: TheSecret
    allow-fast-path: no
[admin@rtr-a] > /ppp secret print detail 
Flags: X - disabled 
 0   name="me" service=any caller-id="" password="ThePassword" 
     profile=default routes="" limit-bytes-in=0 limit-bytes-out=0 
     last-logged-out=apr/03/2017 10:29:46 
[admin@rtr-a] > /ip dhcp print detail
Flags: X - disabled, I - invalid 
 0   name="dhcp1" interface=ether1 lease-time=10m address-pool=dhcp_pool1 
     bootp-support=static authoritative=after-2sec-delay lease-script="" 
[admin@rtr-a] > /ip pool print
 # NAME                                         RANGES                         
 0 dhcp_pool1                                   192.168.2.2-192.168.2.127  
 1 vpn-pool                                     192.168.2.128-192.168.2.254
[admin@rtr-a] /ip firewall> /ip firewall filter print
Flags: X - disabled, I - invalid, D - dynamic 
 0    chain=input action=accept protocol=udp port=1701,500,4500 log=no 
      log-prefix="" 

 1    chain=input action=accept protocol=ipsec-esp log=no log-prefix="" 
[admin@rtr-a] /ip firewall> /ip firewall nat print
Flags: X - disabled, I - invalid, D - dynamic 
 0    chain=srcnat action=masquerade src-address=192.168.2.0/24 log=no 
      log-prefix=""

L2TP Client (ignore the incoming GRE+IPSEC firewall rules as that router is an L2TP server unrelated to this problem):

[admin@rtr-c] > /ip route print
Flags: X - disabled, A - active, D - dynamic, 
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, 
B - blackhole, U - unreachable, P - prohibit 
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 ADS  0.0.0.0/0                          192.168.3.1               0
 1 ADC  192.168.3.0/24     192.168.3.5     ether1                    0
 2 ADC  192.168.4.0/24     192.168.4.1     LAN                       0
 3 A S  192.168.2.0/24                     l2tp-out-a                1
 4 ADC  192.168.2.1/32     192.168.2.253   l2tp-out-a                0
[admin@rtr-c] > /interface l2tp-client print detail 
Flags: X - disabled, R - running 
 0  R name="l2tp-out-a" max-mtu=1460 max-mru=1460 mrru=disabled 
      connect-to=A.B.C.D user="me" password="ThePassword" 
      profile=default keepalive-timeout=disabled use-ipsec=yes 
      ipsec-secret="TheSecret" allow-fast-path=no 
      add-default-route=no dial-on-demand=yes allow=pap,chap,mschap1,mschap2 
[admin@rtr-c] > /ip firewall filter print
Flags: X - disabled, I - invalid, D - dynamic 
 0    chain=input protocol=udp port=1701,500,4500 

 1    chain=input protocol=ipsec-esp 

[admin@rtr-c] > /ip firewall nat print
Flags: X - disabled, I - invalid, D - dynamic 
 0    chain=srcnat action=masquerade src-address=192.168.4.0/24 log=no
11

/ip firewall nat print
Flags: X - disabled, I - invalid, D - dynamic
0 chain=srcnat action=masquerade src-address=192.168.4.0/24 log=no

Try adding a rule for src-address 192.168.3.0/24

… or … just be sensible and switch to a routed site to site VPN and quit mucking around with NAT rules and other policy based hogwash. An alternative would be to present an argument for why you insist on staying with a policy based VPN. Your configuration has to add rules into NAT tables for specific networks just like you’d have to account for them in a routed network. The exception being you could configure a routing protocol and use GRE + IPSec and be done w/it all. So if you want a configuration that contains the least amount of information about specific networks in it that is the route I’d go.

12 
 2 ADC  192.168.2.0/24     192.168.2.1     ether1                    0
 3 ADC  192.168.2.253/32   192.168.2.1     <l2tp-me>                 0

Also, those 2 need to be bridged or proxy-arp has to be on. You have 2 legs into the same network. I’m surprised RouterOS even lets you do that. Either way this is hogwash.

Is there a need for 192.168.2.0/24 to be shared into both locations because of an application requirement? If so look at something like EoIP w/VRRP for that segment.

13

Thank you again idlemind. I am responding to both of your last messages:

The server side is fine. RouterOS “lets me” do this (actually the routes are dynamic, so RouterOS did it on its own) because the route is more specific (see “/32”) and for the rest of the traffic it should go to the less specific route (“/24”). Let’s not worry about the server side. To prove that the server is OK, without a change on it, I achieved what I want by replacing the L2TP Client RB433AH with a Mac Pro, as described in a previous message above.

Why I stick with the policy based VPN?

  • The L2TP server does not have to know the IP addresses of the clients at all. As long as they know the username, password and shared secret, they can get in.
  • This setup is good for mobile users (Mac OS X laptops which already have a built-in L2TP client implementation, and ONLY L2TP and nothing else). They have no problems.
  • This setup is already in use.
    I agree there are many different solutions, but I am asking about this one.

Finally, I made the change you suggested, which I had tried before, but to no avail. Here it is (routes remain, only the firewall rules changed):

[admin@rtr-c] > /ip firewall filter print
Flags: X - disabled, I - invalid, D - dynamic 
 0    chain=input protocol=udp port=1701,500,4500 

 1    chain=input protocol=ipsec-esp 

 2    chain=forward action=accept src-address=192.168.3.0/24 
      dst-address=192.168.2.0/24 in-interface=ether1 
      out-interface=l2tp-out-a log=no 

 3    chain=forward action=accept src-address=192.168.2.0/24 
      dst-address=192.168.3.0/24 in-interface=l2tp-out-a 
      out-interface=ether1 log=no