Problem with L2TP/IPsec VPN client

RouterOS Beginner Basics
1

Hi,

I have a little problem with my hAP lite and a VPN connection that should be established from my router.
I have the choice between OpenVPN (only with TLS auth, which, as I understand, is not yet supported by RouterOS), PPTP, SSTP, IKEv2/IPSec and L2TP/IPsec.

I wanted to go for L2TP/IPsec.
When I create L2TP connection, everythings works fine.
As soon as I activate IPsec and configure the IPsec secret, my log shows the following:

initializing...
connecting...
initiate new phase 1 (Identity Protection)
ISAKMP-SA established

And then after 20 to 30 seconds:

terminating... - session closed
disconnected
ISAKMP-SA deleted

It then tries to reconnect, but 20-30 seconds later the connection breaks up again.
Can you help me troubleshoot?

Cheers,

Sebastian

2

IPSec can have many different parameters, maybe the other side doesn’t like default ones chosen by RouterOS. It’s most likely solvable, IPSec option in L2TP client is just a handy shortcut, you can configure IPSec manually if needed. But as can be expected, it’s not easier. Try to enable more detailed logging (/system logging add topics=ipsec) and hope that it will give you some clues.

3

When you want people to troubleshoot, you should provide material to look at.
In this case: an export of your configuration. And maybe a specification of what kind of router you are connecting to.

4

@Sob Thanks. I activated some logging, and did see something. See below.
@pe1chl I sadly have no clue what the other side uses as vpn server / router. Its a commercial VPN service (nordvpn).

Here’s my config:

/interface l2tp-client
add connect-to=xyz.nordvpn.com ipsec-secret=secret name=myvpn password=\
    mypassword profile=default use-ipsec=yes user=username

As soon as I disable IPsec, the VPN connection is stable. Enabled, it goes up and down and up and down…
So, after I enabled logging (both for ipsec and l2tp), I saw this in the logs (I just replaced the remote ip address with 111.111.111.111):

Jul/04/2017 21:03:26 l2tp,debug,packet sent control message to 111.111.111.111:1701 from 0.0.0.0:1701
Jul/04/2017 21:03:26 l2tp,debug,packet     tunnel-id=0, session-id=0, ns=0, nr=0
Jul/04/2017 21:03:26 l2tp,debug,packet     (M) Message-Type=SCCRQ
Jul/04/2017 21:03:26 l2tp,debug,packet     (M) Protocol-Version=0x01:00
Jul/04/2017 21:03:26 l2tp,debug,packet     (M) Framing-Capabilities=0x1
Jul/04/2017 21:03:26 l2tp,debug,packet     (M) Bearer-Capabilities=0x0
Jul/04/2017 21:03:26 l2tp,debug,packet     Firmware-Revision=0x1
Jul/04/2017 21:03:26 l2tp,debug,packet     (M) Host-Name="MikroTik"
Jul/04/2017 21:03:26 l2tp,debug,packet     Vendor-Name="MikroTik"
Jul/04/2017 21:03:26 l2tp,debug,packet     (M) Assigned-Tunnel-ID=1
Jul/04/2017 21:03:26 l2tp,debug,packet     (M) Receive-Window-Size=4
Jul/04/2017 21:03:30 ipsec,debug KA: 192.168.178.54[4500]->111.111.111.111[4500]
Jul/04/2017 21:03:30 ipsec,debug 1 times of 1 bytes message will be sent to 111.111.111.111[4500]
Jul/04/2017 21:03:30 ipsec,debug,packet ff
Jul/04/2017 21:03:31 ipsec,debug ===== received 92 bytes from 111.111.111.111[4500] to 192.168.178.54[4500]
... // a bunch of ipsec messages, all debug output, a lot of byte blocks, nothing that looks like an error...
Jul/04/2017 21:03:31 ipsec,debug hash validated.
Jul/04/2017 21:03:31 ipsec,debug begin.
Jul/04/2017 21:03:31 ipsec,debug seen nptype=8(hash) len=24
Jul/04/2017 21:03:31 ipsec,debug seen nptype=11(notify) len=32
Jul/04/2017 21:03:31 ipsec,debug succeed.
Jul/04/2017 21:03:31 ipsec 111.111.111.111 notify: R_U_THERE
Jul/04/2017 21:03:31 ipsec,debug 111.111.111.111 DPD R-U-There received
Jul/04/2017 21:03:31 ipsec,debug compute IV for phase2
Jul/04/2017 21:03:31 ipsec,debug phase1 last IV:
... // a bunch of other bytes, showing that something gets encrypted and decrypted, without error messages...
Jul/04/2017 21:03:31 ipsec,debug HASH computed:
Jul/04/2017 21:03:31 ipsec,debug 5936534c 303b793a 13246fd1 98a6d548 13193314
Jul/04/2017 21:03:31 ipsec,debug hash validated.
Jul/04/2017 21:03:31 ipsec,debug begin.
Jul/04/2017 21:03:31 ipsec,debug seen nptype=8(hash) len=24
Jul/04/2017 21:03:31 ipsec,debug seen nptype=11(notify) len=12
Jul/04/2017 21:03:31 ipsec,debug succeed.
Jul/04/2017 21:03:31 ipsec 111.111.111.111 notify: INVALID-HASH-INFORMATION
Jul/04/2017 21:03:31 ipsec 111.111.111.111 fatal INVALID-HASH-INFORMATION notify messsage, phase1 should be deleted.
Jul/04/2017 21:03:34 l2tp,debug tunnel 1 received no replies, disconnecting
Jul/04/2017 21:03:34 l2tp,debug tunnel 1 entering state: dead
Jul/04/2017 21:03:34 l2tp,debug session 1 entering state: dead
Jul/04/2017 21:03:34 l2tp,ppp,info myvpn: terminating... - session closed
Jul/04/2017 21:03:34 l2tp,ppp,debug myvpn: LCP lowerdown
Jul/04/2017 21:03:34 l2tp,ppp,debug myvpn: LCP down event in initial state
Jul/04/2017 21:03:34 l2tp,ppp,info myvpn: disconnected
5

Ok the config looks OK. Did you change any other IPsec setting, like the Proposal ?
Sometimes this problem occurs when you use different settings than SHA1 and AES-128/3DES.
There appears to be some incompatibility in handling SHA256 and AES-256 so make sure those are not selected.

6

I’m no IPSec expert, but it’s going for phase 2, so fiddling with proposal settings (the one named “default” in IP->IPSec->Proposals) might help. Default in RouterOS is sha1 and aes cbc. NordVPN in their tutorials advertises L2TP/IPSec even for Windows XP, so if they require something else, it’s probably going to be something weaker rather than stronger. Possibly md5 or 3des, you can try that. Go step by step, don’t change too many items at the same time.

Good thing is that you have plan B and can always try something different, e.g. SSTP should be very easy. Or you can experiment with IKEv2, it’s modern, also quite new in RouterOS, so you can get that nice pioneer-like feeling it you make it work. :slight_smile:

7

I don’t see IKEv2 when I want to do /interface add ikev2-client or something similar?

8

It lives in IP->IPSec, it’s slightly advanced stuff and I won’t tell you much about it, because it’s still on my TODO list of things to learn. I’ve tried something already, but I’m still at the beginning.

9

I tried, but sadly to no avail. I went through a lot of combinations, but it didn’t affect anything.
Also, in the IPsec log I see some lines “NO PROPOSAL CHOSEN”, so I am thinking it might even not have applied the changes I made to the vpn connection.

10

Oh yes, that means that you have made a selection in your proposal configuration that does not match any of the selections at the other end.
The best way to get it resolved is to ask the other end what IPsec options they are using. You will get two lists of hashing and encryption options, for phase1 and phase2.
Like:
phase1 hashing MD5 or SHA1 encryption 3DES or AES-128
phase2 hashing MD5 or SHA1 or SHA256 encruption 3DES or AES-128 or AES-256

With that info you can configure it correctly. Without that info you are basically shooting in the dark until you hit it.

11

Thanks. I requested detailed information from the VPN service provider.

12

Okay… they got back to me, but now I am a bit confused.

They said, in order to connect to their service using L2TP/IPsec I should do the following:

/ip ipsec peer add address=serveraddress auth-method=pre-shared-key secret=key exchange-mode=main-l2tp hash-algorithm=sha1 enc-algorithm=3des dh-group=modp1024 xauth-login=username xauth-password=password

Now, when I activate this peer, it seems to open up an IPsec connection (tunnel?) to the remote server, but I have a feeling its not used for l2tp.

Now, I am not sure what I have to do (if I have to do anything) to make sure the L2TP VPN connection also goes through the IPsec tunnel between my hAP lite and the VPN server, and not simply connects in an unencrypted way alongside / in parallel to that tunnel.

Here, again for reference, the current config.

/interface bridge
add admin-mac=AA:BB:CC:DD:EE:FF auto-mac=no fast-forward=no name=bridge
/interface ethernet
set [ find default-name=ether2 ] master-port=ether1
set [ find default-name=ether3 ] master-port=ether1
/interface l2tp-client
add allow-fast-path=yes comment="NordVPN connection" connect-to=\
    ru5.nordvpn.com disabled=no ipsec-secret=nordvpn name=nordvpn-l2tp \
    password=MYPASWORD profile=default user=MYUSER
/interface bridge filter
add action=mark-packet chain=input comment=\
    "mark outbound packets from ether4 for the firewall mangle rule" \
    dst-address=!192.168.178.0/24 in-interface=ether4 mac-protocol=ip \
    new-packet-mark=route-to-vpn
/interface bridge nat
add action=redirect chain=dstnat comment="make sure packets from eth4 go throu\
    gh IP firewall to make them routable" dst-address=!192.168.178.0/24 \
    in-interface=ether4 mac-protocol=ip
/interface bridge port
add bridge=bridge interface=ether1
add bridge=bridge interface=wlan1
add bridge=bridge interface=ether4
/ip dhcp-client
add dhcp-options=hostname,clientid disabled=no interface=bridge
/ip dns
set allow-remote-requests=yes
/ip dns static
add address=192.168.88.1 name=router
/ip firewall mangle
add action=mark-routing chain=prerouting comment=\
    "mark packets flagged by bridge filter for actual routing through VPN" \
    new-routing-mark=vpn packet-mark=route-to-vpn passthrough=no
/ip firewall nat
add action=masquerade chain=srcnat comment="masquerade all traffic that goes t\
    hrough VPN, so that responses are returned correctly" out-interface=\
    nordvpn-l2tp
/ip ipsec peer
add address=31.192.111.175/32 comment="IPsec peer for NordVPN connection" \
    enc-algorithm=3des exchange-mode=main-l2tp secret=nordvpn
/ip route
add comment=\
    "route packets marked by mangle for vpn through the vpn interface" \
    distance=1 gateway=nordvpn-l2tp routing-mark=vpn
13

When you use this manual IPsec peer configuration, you have to remove the IPsec settings from your L2TP configuration.
IPsec settings in the L2TP configuration are only a quick way to build an IPsec peer with default settings, and now you want that more specific one.

W.r.t. not using the IPsec tunnel: that indeed is a real risk with MikroTik. Specifying IPsec for any service does only mean
that an IPsec peer association and policy is defined for that traffic. When that association fails to establish, or even when
there is traffic on the higher layer before the IPsec association is established, the traffic passes around the IPsec tunnel
in the clear and you will never notice. I mentioned it before on this forum, when I noticed that L2TP connections between
MikroTik routers were sometimes in the clear after a restart or network failure.

To prevent that, you can insert a firewall rule that blocks the unencrypted form of the traffic while not affecting (or allowing)
the encrypted variant. This will block the L2TP traffic until there is a valid and working IPsec association.

Try something like this:

/ip firewall filter
add action=reject chain=output comment="L2TP no IPsec active" \
    ipsec-policy=out,none protocol=udp dst-port=1701 reject-with=icmp-network-unreachable

With this rule, you block unencrypted L2TP outgoing traffic.

14

The IPsec settings on the L2TP interface are disabled now.

But now I have the same problem as before: IPsec seems to work (telling from the log), but the L2TP connection says:

tunnel 7 received no replies, disconnecting
tunnel 7 entering state: dead
session 1 entering state: dead
myvpn: terminating... - session closed

So as it seems, it is not possible for one of the sides to keep up a stable L2TP connection when IPsec is around it.

To verify that:
When I disable the IPsec peer, and then enable the VPN interface, it connects, and my devices outbound traffic is routed through the vpn.
When I enable the IPsec peer, the L2TP connection keeps staying alive, but its still outside of the IPsec tunnel.
When I disable the VPN interface, and re-enable it (now with activated IPsec), the L2TP logs show the problem above.

15

Did you remove the IPsec setting from L2TP and only have that IPsec Peer configured that they sent you?

16

Yes. I deleted the IPsec secret in my L2TP interface and unchecked the Use IPsec checkbox (I am more the UI clicky type of user :slight_smile: ).

17

Ok, I am not completely certain that blocking the output will work in this case, it could be that the IPsec peering is only triggered by traffic on L2TP that is now being blocked.
(in my case I use the MikroTik as the server and have a similar rule like shown above but on input, reversed of course, that works OK)

Do you see different behaviour with and without that output reject rule? (you can disable/enable things in the webfig by clicking the small box with a D or E in it, or
using the checkmark/X on the winbox GUI)

18

Peer alone is not enough, you also need some policy to catch the right traffic, otherwise there’s nothing to encrypt. You can add one manually, see this page for inspiration:

https://mivilisnet.wordpress.com/2017/01/26/mikrotik-device-as-a-l2tpipsec-client/

Look for “Mikrotik devices with RouterOS v5.26 and earlier” part, because there wasn’t magic checkbox in L2TP client in those yet. There’s also generate-policy option for peers, but I’m not sure if it can help, I’m trying some simple tests and so far I haven’t had any luck with it. But to be honest, this is my first time plaing with RouterOS L2TP/IPSec client, so maybe it’s not even supposed to work (I just remember using it on server once or twice). But manually defined policy worked for me.

I’m starting to remember why long in the past I decided that IPSec is nice technology for all-static site to site tunnels and the rest is evil. :wink:

19

Ahh yes you are right, I forgot to check that. When there is the option generate-policy=port-strict in the IPsec Peer it should generate the policy automatically.

20

I need to do more tests for that.
My question is, how can I determine for sure whether the L2TP goes through the tunnel or alongside it (to check if the filter rule works or not)?

I did that now. Thanks.


I also added a rule that rejects packets my device on port 4 sends to the outside world that do not go through the VPN. That way I can be sure that the device only connects through the VPN to the internet and not directly through my normal ISPs uplink.