Security for manual l2tp/ipsec

RouterOS General
1

Hi,

I just configured my first lt2p/ipsec with manual ipsec creation. There was a reason of stability issue due to ikev1 from ISP side, and I wanted to go with ikev2.

Below is my configuration.

There is a SERVER with 2 public addresses and a CLIENT with 1 public address

A => Public IP of ISP 1 of SERVER

B=> Public IP of ISP 2 of SERVER

C => Public IP of CLIENT

D & E => Private IP assigned from the l2pt

Server Side

/ip ipsec profile
add dh-group=modp1024 dpd-interval=2m dpd-maximum-failures=5 enc-algorithm=aes-256 hash-algorithm=sha256 name=offices nat-traversal=no

/ip ipsec peer
add address=46.C.C.C/32 exchange-mode=ike2 local-address=93.B.B.B name=main_from_cyta_backup passive=yes profile=offices send-initial-contact=no
add address=46.C.C.C/32 exchange-mode=ike2 local-address=93.A.A.A name=main_from_cyta_main passive=yes profile=offices send-initial-contact=no

/ip ipsec proposal
add auth-algorithms=sha256 enc-algorithms=aes-256-cbc name=offices pfs-group=none

/ip ipsec identityadd comment=M1_cyta_MAIN generate-policy=port-strict peer=main_from_cyta_main remote-id=ignore
add comment=M1_cyta_BACKUP generate-policy=port-strict peer=main_from_cyta_backup remote-id=ignore

/ip ipsec policy
add dst-address=46.C.C.C/32 dst-port=1701 level=unique peer=main_from_cyta_main proposal=offices protocol=udp src-address=93.A.A.A/32 src-port=1701
add dst-port=1701 level=unique peer=backup_from_cyta_main proposal=offices protocol=udp src-port=1701
add dst-address=46.C.C.C/32 dst-port=1701 level=unique peer=main_from_cyta_backup proposal=offices protocol=udp src-address=93.B.B.B/32 src-port=1701
add dst-port=1701 level=unique peer=backup_from_cyta_backup proposal=offices protocol=udp src-port=1701

/ppp secret
add name=USERNAME_1 profile=Profile_M1_CYTA_main remote-address=172.16.D.D service=l2tp
add name=USERNAME_2 profile=Profile_M1_CYTA_backup remote-address=172.16.E.E service=l2tp

Client Side

/ip ipsec profile
add dh-group=modp1024 dpd-interval=2m dpd-maximum-failures=5 enc-algorithm=aes-256 hash-algorithm=sha256 name=CL_hq nat-traversal=no
/ip ipsec peer
add address=93.A.A.A/32 exchange-mode=ike2 local-address=46.C.C.C name=CL_hq_backup profile=CL_hq
add address=93.B.B.B/32 exchange-mode=ike2 local-address=46.C.C.C name=CL_hq_main profile=CL_hq
/ip ipsec proposal
add auth-algorithms=sha256 enc-algorithms=aes-256-cbc name=CL_hq pfs-group=none
/ip ipsec identity
add peer=CL_hq_main remote-id=ignore
add peer=CL_hq_backup remote-id=ignore
/ip ipsec policy
add dst-address=93.A.A.A/32 dst-port=1701 level=unique peer=CL_hq_main proposal=CL_hq protocol=udp src-address=46.C.C.C/32 src-port=1701
add dst-address=93.B.B.B/32 dst-port=1701 level=unique peer=CL_hq_backup proposal=CL_hq protocol=udp src-address=46.C.C.C/32 src-port=1701

/interface l2tp-client
add connect-to=93.B.B.B disabled=no name=to_CY_backup profile=CL_l2tp user=USERNAME_2
add connect-to=93.A.A.A disabled=no name=to_CY_main profile=CL_l2tp user=USERNAME_1

Basically what I did is copy the configuration from the automatically generated configuration from l2tp with enabled IPsec encryption, and convert it to ikev2 equivalent.

It works and I use the L2TP for establishing BGP that I want successfully, but I would like that know if there is anything else I should add for security. For example if there is any additional automatic config from Mikrotik when I use IPsec enable option in L2TP tunnel.

For example, am I correct to assume that I don’t want under any circumstances the l2tp to establish while the IPsec tunnel is down? I am not sure how to check that.

2

The L2TP tunnel lives on top of the IPsec, so no need to worry that it’ll establish without IPsec. If you want to be sure about it, you can modify the L2TP accepting rule in the server firewall to only allow only when IPsec was established and it would look something like that:


/ip firewall filter
add action=accept chain=input dst-port=1701 ipsec-policy=in,ipsec protocol=udp
3

Thank you for your input, it is appreciated!

To be honest, I am mostly worried about having automatic IPsec encryption disabled on L2TP in order to implement with manual ipsec tunnel.

image
image714×467 14.4 KB

image
image390×275 7.77 KB

If I understand correct, if the IPsec Policy that connects the two Public IPs on port 1701 is invalid for any reason, the L2TP will follow routing table instead of ipsec policy and will try establish outside of IPsec.

Also if I understand correct, even if I block it on Server side to not let L2TP establish outside of IPsec tunnel, there are some parts that are visible (authentication?) during the connection request. From my understanding I should also prevent from client side the ability to request L2TP, so that only it is successful when IPsec Policy is Active.

Is there any wrong in my thought process? Am I missing something?

Thank you.

4

I don’t think L2TP/IPsec could ever be initiated without an established IPsec, especially if the encryption in the PPP profile is set to “required”, so again - no need to worry. If the policy was invalid, the IPsec tunnel wouldn’t come up due to miscommunication in Phase 2 and the L2TP client wouldn’t send anything

5

I just checked, plain L2TP without IPsec enabled and without any specific IPsec Policy setup and it connected. Encryption was enabled from profile.

image
image814×676 22.4 KB

I can see that L2TP and IPsec are two different things that usually combined and can be enabled to be automated in RouterOS. As described in the initial post, my case is different. I disabled IPsec and created manually an IPsec tunnel to be used for the L2TP connection.

As long as the IPsec policy is active, the Policy Routing preceeds in priority of routing table and L2TP gets established through the IPsec.

What if accidentally the Policy gets disabled? eg from script or a bug after a RouterOS upgrade?

The answer is that the L2TP will establish outside of IPsec. Normally with IPsec option enabled at L2TP, this would be automatically prevented from RouterOS, but this is not my case.

So, to reiterate, my worrying is how do I ensure that, in my specific case, the L2TP client sends request only through IPsec and prevent from trying to establish connection outside of IPsec.

Edit: I can now see that if on L2TP SERVER I set Use IPsec=required instead of yes, the L2TP server won’t accept the connection of L2TP outside of IPsec. Is that enough to ensure that I don’t have sensitive info in the wild (eg user/password of L2TP)?

6

This has nothing to do with eachother. L2TP can run without IPsec and “PPP profile encryption” is referring to Microsoft Point-to-Point Encryption (MPPE) which is a protocol running inside of PPP.

When you enable that AND IPsec you have two layers of encryption, probably hurting performance.

The firewall filter shown above will allow L2TP with IPsec, but it is better to reverse it (drop L2TP traffic without IPsec) and put that rule before the “accept established/related” rule in the input firewall. And indeed there is the option to set IPsec=required in the server, which also prevents this problem.

7

To the first point you could use CHAP which doesn’t expose either plaintext or crackable passwords, or add a firewall rule to drop UDP port 1701 in the output chain if it hasipsec-policy=out,none(note I haven’t tested this).

To the second point that prevents the server from receiving unencrypted L2TP, you can achieve the same by adding the firewall rule mentioned previously when configuring IPsec manually.

8

Since you have already gone through the trouble to create static IPsec configuration and have already messed around with its settings, you can consider confugring IKEv2/IPsec with certficates if you’re concerned about security, and that should have better performance than L2TP/IPsec. A bit more finicky to set up but much more secure and better performing/better speeds