Hello,
I came across a question and couldn’t find an answer in the forum:
Is there a way to use multiple IPSec Profiles for different L2TP Secrets? How would you implement this?
Thank you all.
IIRC you cannot add l2tp servers, it only can be enabled or disabled. In other words: only one l2tp server → only one dynamic ipsec peer → only one ipsec profile.
As @Kentzo has pointed out, there is only a single L2TP server that listens at all addresses, but this is not the limitation in this case.
The IPsec connection has to get established first, before the L2TP exchange begins, so there is no way how the PPP user credentials could be used to choose an IPsec profile. Hence the only way to use different IPsec profiles for peers with the same exchange-mode is to use different addresses. It would be enough to use a different port for each of them if you’ve only got a single IP address at the responder side, but not all initiators can be told to connect to a different port than 500.
To distinguish between the peers on a single address using ports, you’d have to link the peers to individual auxiliary IP addresses internally and use dst-nat rules to map the destination ports to the internal addresses, and set to-ports to 500 as the IPsec stack won’t listen on other ports than 500 and 4500. Plus I’m not sure whether the IPsec stack will accept the migration of the connection from the original port to port 4500 upon NAT detection if the traffic to port 4500 arrives to another local address than the initial one to port 500.
In any case, you’ll have to configure IPsec manually, i.e. use-ipsec will have to be set to no in the /interface l2tp-server server settings.
Thank you both for the clarification.
I have never tried configuring IPsec manually to work together with the L2TP server. I was always under impression that RouterOS does some magic behind the scenes that’s otherwise unavailable to the current user.
The whole magic consists in creating the IPsec configuration (peer & identity) dynamically from the configuration data of the L2TP and hidden templates for both, using the default profile, and then creating a policy using the template in the default policy group (to which the policy-group parameter of the generated identity links), which refers to the default proposal, whenever a client connects and requests a policy.
The templates for peer and identity are the only thing hidden from the user; the resulting objects are shown normally, marked with D for “dynamically created”
There is no special interworking between the IPsec stack and the L2TP stack during runtime. So if you disable the automatic creation by setting use-ipsec to no, and create the peer&identity manually, you get exactly the same runtime behavior. And doing so allows you to use your own profile, policy template group, and proposal, or even change from IKE (v1) to IKEv2 if you don’t mind that the latter doesn’t conform to the L2TP/IPsec standard.
Hi i’ve found this forum because i’ve a similar issue.
i’m wondering if anyone can help me please.
i’ve created an ipsec tunnel from a headquarter office and sever other locations.
using ikev2 and a profile that uses sha512 aes-256 and modp-2048
i also have created a l2tp/ipsec for the people who work remotedly.
the issue is that, as you guys have mentioned, it dinamically creates a peer and an identity; and these uses the profile for the ipsec tunnel that I descripted above, it doesn’t select the one that I’ve created for the l2tp remote access.
the problem is that the remote access fails if it uses sha512, it only works with sha1 so i created another profile only for the l2tp server. But I have to delete the dinamically created ones but everytime the mikrotik reboots it creates a new one that again chooses the first profile and the l2tp access breaks.
what can I do?
You can post the text export of your actual configuration. There are numerous descriptions here on the forum that explain how to create it and how to properly obfuscate it before posting it so that the internal consistency of the information is preserved.
But you may not need to do that if the following is enough to help: L2TP indeed uses the /ip ipsec profile row named default and the /ip ipsec policy template belonging to group default if you tell it to create the peer, identity, and policies dynamically, and this indeed cannot be changed, but you can create your own profile and policy template group for your IKEv2 setup.
You can even create multiple identities for IKEv2 for the same peer if you can set the initiator ID and link them to different policy template groups. I had to do this e.g. to adjust the behavior to Windows and iOS IKEv2 clients.
Here it is, please let me know if I’ve obfuscated something that I shouldn’t.
jan/31/2025 xx:xx:xx by RouterOS 6.49.8
software id = ####-####
model = RB750Gr3
serial number =
/interface bridge
add name=lan-ofice
/interface ethernet
set [ find default-name=ether1 ] name=ether1-wan
set [ find default-name=ether2 ] name=ether2-PC1
set [ find default-name=ether3 ] name=ether3-SERVER
set [ find default-name=ether4 ] name=ether4-POS
set [ find default-name=ether5 ] name=ether5-AP
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip ipsec peer
add address=PUBLIC-IP exchange-mode=ike2 name=store1
/ip ipsec profile
set [ find default=yes ] dh-group=modp2048 enc-algorithm=aes-256
hash-algorithm=sha512 name=ipsec1
add dh-group=modp2048 enc-algorithm=aes-256 name=remote
/ip ipsec peer
add name=l2tp-in-server passive=yes profile=remote
/ip ipsec proposal
set [ find default=yes ] disabled=yes
add enc-algorithms=aes-128-cbc lifetime=1d name=proposal1-IPSEC pfs-group=none
add auth-algorithms=sha512,sha256,sha1 name=proposal-remote pfs-group=none
/ip pool
add comment=“lan-pool” name=pool1_local ranges=
xx.xx.xx.50-xx.xx.xx.100
add comment=“remote-pool” name=
pool2-remote_access ranges=XX.XX.XX.100-xx.XX.xx.150
add comment=“WIFI-pool” name=“pool3-guests-WIFI” ranges=
xxx.xxx.x.101-xxx.xxx.x.150
/ip dhcp-server
add address-pool=pool1_local disabled=no interface=lan-ofice lease-time=
1h name=dhcp_bridge
/ppp profile
add dns-server=1.1.1.1,8.8.8.8 local-address=xxx.xxx.x.1 name=
“remote-profile” remote-address=pool2-remote_access
/interface bridge port
add bridge=lan-ofice interface=ether2-PC1
add bridge=lan-ofice interface=ether3-SERVER
add bridge=lan-ofice interface=ether4-POS
add bridge=lan-ofice interface=ether5-AP
/interface l2tp-server server
set authentication=mschap2 default-profile=“remote-profile” enabled=yes
ipsec-secret=xxxxxxxxx use-ipsec=yes
/ip address
add address=publicIP-headoffice/24 comment=“wan modem” interface=ether1-wan
network=publicIP-gateway
add address=IP-localred-headoffice/24 comment=bridge interface=lan-ofice network=
xxx.xxx.x.0
add address=xxx.xxx.X.2 comment=“for PC1 ether2” interface=ether2-PC1
network=xxx.xxx.x.0
add address=xxx.xxx.x.3 comment=“server ether3” interface=ether3-SERVER
network=XXX.xxx.x.0
add address=xxx.xxx.x.4 comment=“POS ether4” interface=ether4-POS network=
xxx.xxx.x.0
add address=xxx.xxx.x.5 comment=“AP TP LINK ether5” interface=
ether5-AP network=xxx.xxx.x.0
/ip dhcp-server network
add address=xxx.xxx.x.0/24 dns-server=1.1.1.1,8.8.8.8 gateway=xxx.xxx.x.1
/ip dns
set allow-remote-requests=yes servers=1.1.1.1,8.8.8.8
/ip dns static
add address=xxx.xxx.x.97 name=SERVIDOR
/ip firewall address-list
add address=194.50.16.198 list=blocked_ips
add address=194.50.16.1 list=blocked_ips
add address=103.102.230.5 list=blocked_ips
add address=185.147.124.54 list=blocked_ips
add address=xxx.xxx.x.100 list=ssh-allowed
add address=xxx.xxx.x.100 list=api-allowed
add address=xxx.xxx.x.1 list=api-allowed
add address=xxx.xxx.x.3 list=api-allowed
add address=xxx.xxx.x.1 list=ssh-allowed
add address=xxx.xxx.x.3 list=ssh-allowed
/ip firewall filter
add action=drop chain=input src-address=194.50.16.198
add action=drop chain=input src-address=194.50.16.1
add action=drop chain=input src-address=103.102.230.5
add action=drop chain=input src-address=185.147.124.54
add action=accept chain=input dst-port=x protocol=tcp src-address=
xxx.xxx.x.100
add action=accept chain=input dst-port=x protocol=tcp src-address-list=
ssh-allowed
add action=accept chain=input dst-port=xx protocol=tcp src-address-list=
api-allowed
add action=drop chain=input dst-port=xx protocol=tcp
add action=drop chain=input dst-port=x protocol=tcp
/ip firewall nat
add action=accept chain=srcnat dst-address-list=xxx.xxx.x.0/24 (local headoffice
src-address-list=xxx.xxx.x.0/24 (local headoffice)
add action=accept chain=srcnat dst-address=xxx.xxx.xx.0/24 (local store1) out-interface=
ether1-wan src-address=xxx.xxx.x.0/24 (local headoffice)
add action=masquerade chain=srcnat out-interface=ether1-wan
/ip ipsec identity
add peer=store1 secret=xxxxx
add generate-policy=port-strict peer=l2tp-in-server remote-id=ignore secret=
xxx
/ip ipsec policy
set 0 comment=“don’t delete, policy for l2tp” proposal=“proposal remote”
add dst-address=xxx.xxx.xx.0/24 (local store1) peer=store1 proposal=proposal1-IPSEC src-address=
Xxx.xxx.x.0/24 (local headoffice) tunnel=yes
/ip route
add distance=1 gateway=public gateway headoffcice
add distance=1 dst-address=xxx.xxx.xx.0/24 (local store1) gateway=lan-ofice
/ip service
set telnet disabled=yes
/ppp secret
add name=user1 password=xxxx profile=“remote-profile” service=
l2tp
add name=user2 password=xxx profile=“remote-profile” service=
l2tp
add name=user3 password=xxx profile=“remote-profile”
service=l2tp
/system clock
set time-zone-name=xxx
Regarding the posting - it is considered useful to place the code between [code] and [/code] tags that can be obtained by pressing the [</>] button above the editing form. The obfuscation did not hide any internal relationship as the configuration is quite simple.
As I suspected, your IKEv2 peer named store1 uses the /ip ipsec profile item named default, i.e. the same one which the L2TP stack uses to dynamically create a peer if asked to do so.
In addition to that, you do ask L2TP to create the peer dynamically, but at the same time you have a static IKE(v1) peer named l2tp-in-server. It refers to another /ip ipsec profile item than the default one, but only one of the IKE(v1) peers is actually used by incoming connections at a time; I don’t know which one “wins” but /ip ipsec peer print will answer that question, as RouterOS shows a warning if a peer is shadowed by another one.
Someone told me to untick the use ipsec in the l2tp server options, or to put it on “no”.
I thought if I did that I would have turned off ipsec enterely for the l2tp remote access, but I was told that if I added the peer and identity manually I wouldn’t be turning off ipsec.
I’m have another issue now, maybe you can help if you don’t mind.
From the remote PCs I can ping every device in the headoffice but I cannot ping any devices on the store1, I do can ping them from any devices in the headoffice.
So something must be wrong with the routes or the firewall rules, is there a way to solve that?
The purpose of the remote PCs is to access the server and to access PCs on the stores to troubleshoot them if anything happens
To allow to analyse this, the obfuscation has indeed been too aggressive. It is not clear how the pools are related to the subnets (there is actually no point in obfuscating private IP addresses). The most likely reason is that the traffic selector of the ipsec policy that links the HQ to the store does not cover the addresses that are assigned to the L2TP clients, but the actual reason may be different, we’ll see once you post an export that contains more information. I’m all for a systematic replacement of each actual unique port number (like 12345) by a unique string (like “ssh-port-number”) using the find-and-replace feature of a text editor, but the key requiremet is that the relationship between items (here, firewall rules) remains clear after the obfuscation. So leaving private addresses alone and substituting only the first three (or even two) bytes of public addresses by text strings is a better approach to obfuscation.