Multiple L2TP clients on single device

saibarker · May 9, 2021, 7:00am

Hi,

Scenario
I want to run two separate L2TP clients to different servers simultaneously. L2TP-Client1 will be for management purposes only and be connected to an L2TP server whos public IP is XXX.XXX.XXX.XXX. No local hosts on the client router will be able to access the Management VPN.
L2TP-Client2 will be connected to XXX.XXX.YYY.ZZZ and this will be a site-site VPN where all local hosts will have access to the VPN.

There will be a dozen client sites in total that will require the same configuration.

My Question is
Is it possible in RouterOS to do this? If so would you be able to provide an example of a config for this?

Thanks in advanced

sindy · May 9, 2021, 7:36am

Yes, it is possible. Two L2TP clients towards different servers are OK. You can even use the automatically generated IPsec configurations if both servers accept the same Phase 1 and Phase 2 proposal, otherwise you’d have to configure the IPsec layer manually.

Regarding the different usage policies of the two tunnels, it is a matter of policy routing and firewall rules, so hard to give an example without knowing the address plan of the network. If the subnets from which you will do the management of the client devices via the management tunnel do not overlap with any subnets the LAN devices on the clients should access via the other tunnel, you just add routes to the respective subnets via their corresponding tunnels, and the rest is firewall filter rules preventing packets from LAN clients to be delivered via the management tunnel, and preventing packets that arrive through the other tunnel from being accepted by the router itself. If the subnets overlap, you’ll have to use policy routing and connection tracking to make sure that downstream and upstream packets of the same connection will use the same tunnel. Or, if the addresses assigned to the clients by the remote management server will not overlap with the LAN subnet, connection tracking may not be necessary and a simple routing rule will do.

In any case, a careful address design is a key to avoid unexpected behaviour.

saibarker · May 10, 2021, 11:42am

Hi Sindy,

Thanks for your detailed response.

This is a quick diagram of what i’m planning to achieve.

On the Management VPN, Clients will be assigned an IP from a pool in the 10.200.0.0/16 subnet.

On the Cooperate VPN, Client routers will have a unique /24 local subnet for the site’s LAN. Anything in that /24 should have access to the cooperate VPN including local hosts at other client sites which are in a different /24. For example, 192.168.15.xxx should be able to ping 192.168.8.xxx, 192.168.16.xxx and so on.

The Cooperate VPN SHOULD NOT be able to see the Management VPN and visa-versa.

Would you have a more detailed example of configuration, like routing rules and firewall rules? I’m new to Mikrotik and not 100% sure where to start config wise.

Thanks again,

sindy · May 10, 2021, 12:19pm

Given the clear separation between the management addresses (10.200.0.0/16, btw quite an overkill for a “dozen” clients) and the corporate range (192.168.0.0/16), it’s nothing extremely complex.

In particular, there is no need for policy routing, just tell me whether you’ll be managing the clients from the management L2TP server itself or whether there will be some subnet behind it.

Regarding “seeing” the other VPN, let me elaborate on how I understand the actual requirements:

from the management tunnel, it should be possible to connect only to the router itself, not to the LAN devices
from the corporate VPN, it should be the opposite: incoming connections through this tunnel should only be allowed to LAN devices, not to the router itself or to anything behind the management tunnel
LAN devices should only be able to establish connections through the corporate tunnel, not to the router itself or through the management tunnel.

Do you agree with these requirements? If not, modify them.

What about the general internet access, should the LAN devices reach internet directly via local WAN, via the corporate L2TP server, or not at all?

In any case, a simple zone firewall on each client is sufficient.

What might be useful, but would cause a need for policy routing if the LAN devices should connect to internet via the corporate tunnel, is to let the two L2TP servers connect to an fqdn rather than directly to an IP number. Consider this too.

Once you give me these input data, I can give you the configuration for the client, based on a modification of the default one (am I right to expect that the client devices will be from the hXY product line)?

Also, what is your motivation to use L2TP/IPsec in particular? Will the L2TP servers be CHRs or something non-Mikrotik?

saibarker · May 10, 2021, 11:20pm

Hi Sindy

The management network will be managed remotely by admins connecting to the VPN from their workstation/laptop or a site router. They will be given a 10.200.xxx.xxx IP out of the pool.

I agree with the requirements you elaborated on.

The clients should connect to the internet directly through the local WAN.

Client hardware will be a CCR1009 or RB4011 and the L2TP servers will be CHR. The motivation behind L2TP/ipsec is so that users can work remotely from the field or from home form their windows PC/laptop.

I would also like to ask if it would be possible for the “Caller ID” on the management network be changed a string value i.e the device serial number. Reason being is that the default config will be changed to include the Management VPN client pre-configured, so even if a client router gets factory reset than we will still have remote access to the router. The problem is how will we be able to identify the router if it is factory reset? I want to have the exact same management config in the client routers so that i’m not creating individual default-configs for every single router we ship out (this could be hundreds if not thousands of devices in the long term). We would keep a register of serial numbers that we send out, we will be able to easily identify a device connected to the management VPN by its serial number.

Our management VPN will have every single router we send out. This particular cooperate VPN will only have roughly a dozen sites connected to it. We want to manage many different cooperate networks.

Thanks again for your help.

saibarker · May 13, 2021, 8:57am

Bump

sindy · May 13, 2021, 6:47pm

You’re not forgotten, but this is my voluntary activity and I have more than enough else to do these days. And you’ve said you are a beginner so reddit-style brief hints don’t help much.

So below is a config to be set on a router with no configuration at all. Which is not the same as a router with a factory default configuration. As factory default configuration differs between SOHO models and enterprise/ISP ones, an RB4011 and a CCR1008 in particular come with different factory default configurations. You have to merge the settings below with what you find in the router when you start setting it up manually; once you fine-tune the configuration, you can use it during netinstall or you can place it to a file which survives a reboot (this should not require any special measures at RB4011 nor CCR1008), named e.g. my-generic-config.rsc, and then run /system reset-configuration no-defaults=yes keep-users=yes run-after-reset=my-generic-config.rsc.

Do not connect the router to internet before setting up the configuration, especially the firewall rules. Once you configure it completely, you can enable the only rule in firewall filter which is highlighted in red below, test that you are able to open a new management connection even with that rule enabled, and if you can, you can connect ether1 to an internet uplink. The assumption is that the uplink assigns an address to the device using DHCP, along with a gateway IP and DNS server(s).

After you check that the device can be accessed via the management tunnel, you can disable the firewall rule highlighted in blue, thus disabling management access from LAN ports.

/interface list
add name=WAN
add name=LAN
add name=MGMT
add name=CORP

/interface bridge
add name=bridge

/interface bridge port
add bridge=bridge interface=ether2
add bridge=bridge interface=ether3
…some more similar lines here depending on the actual ports available on your router…

/ip firewall filter
add chain=input connection-state=established,related,untracked action=accept
add chain=input connection-state=invalid action=drop
add chain=input protocol=icmp action=accept
add chain=input in-interface-list=LAN protocol=tcp dst-port=53 action=accept
add chain=input in-interface-list=LAN protocol=udp dst-port=53 action=accept
add chain=input protocol=tcp dst-port=22,443,8291 in-interface-list=MGMT action=accept
add chain=input in-interface-list=LAN dst-port=22,443,8291 in-interface-list=LAN action=accept
add chain=input action=drop disabled=yes
add chain=forward connection-state=established,related,untracked action=accept
add chain=forward connection-state=invalid action=drop
add chain=forward in-interface-list=LAN out-interface-list=WAN action=accept
add chain=forward in-interface-list=LAN out-interface-list=CORP action=accept
add chain=forward action=drop

/ip firewall nat
add action=masquerade out-interface-list=WAN

/interface l2tp-client
add name=management connect-to=management.server.tld disabled=no ipsec-secret=averysecretpassphrase use-ipsec=yes user=not-set-yet password=notsoimportant
add name=corporate connect-to=corporate.server.tld disabled=no ipsec-secret=anotherverysecretone use-ipsec=yes user=not-set-yet password=maybeabitsimpler

/interface list member
add list=WAN interface=ether1
add list=LAN interface=bridge
add list=MGMT interface=management
add list=CORP interface=corporate

/ip dns
set allow-remote-requests=yes

/ip dhcp-client
add interface=ether1 disabled=no

/ip address
add address=192.168.15.1/24 interface=bridge

/ip pool add
name=lan1 ranges=192.168.15.20-192.168.15.254

/ip dhcp-server network add address=192.168.15.0/24 gateway=192.168.15.1 dns-server=192.168.15.1

/ip dhcp-server add name=lan interface=bridge address-pool=lan1 disabled=no

/ip route
add dst-address=10.200.0.0/16 gateway=management
add dst-address=192.168.0.0/16 gateway=corporate

/system script
add name=set-username source=“/interface l2tp-client set [find] user=[/system routerboard get serial-number] ; /system scheduler disable set-username”

/system scheduler
add interval=1m name=set-username on-event=set-username start-date=jan/01/2021 start-time=00:00:00

With use-ipsec=yes, the L2TP client configuration above will create the IPsec configurations for the L2TP connections dynamically, using the default profile and default proposal. So it makes sense to modify the default profile and default proposal to contain the most advanced encryption and authentication algorithms supported in hardware on the devices you are going to use, and align the server side settings with these algorithms. You can configure the IPsec part completely manually, but that’s another can of worms.

As you seem to intend to use this as a template solution to be repeated with several enterprise clients, rest assured that one day you’ll meet a client that will use 10.200.0.0/16 in their internal network. At that moment, you’ll have to deal with VRF (virtual routing and forwarding) functionality, allowing the hosts in LAN to use a dedicated routing table different from the one used by the Mikrotik device itself for its own traffic.