Dial-In L2TP/IPsec not connecting when co-existing with site to site IPsec

RouterOS General
1

I having trouble setting up dial-in L2TP for remote workers on a Mikrotik router that already has a working site-to-site IPsec tunnel between two networks. I suspect that the IPsec settings for the site to site tunnel are interfering with the IPsec portion of the dial-in connection. The remote client is a windows 10 computer, attempting to establish an L2TP connection using IPsec with a pre-shared key. The error received on the win10 box is "The network connection between your computer and the VPN server could not be completed because the remote server is not responding. Ipsec logs on the Mikrotik router during the connection attempt look like this:

07:24:32 echo: ipsec,debug ipsec_: 8abbe30f 3de04eff 99dabefb 31aa53ca 97124414
07:24:32 echo: ipsec,debug ipsec_: hash validated.
07:24:32 echo: ipsec,debug ipsec_: begin.
07:24:32 echo: ipsec,debug ipsec_: seen nptype=8(hash) len=24
07:24:32 echo: ipsec,debug ipsec_: seen nptype=12(delete) len=16
07:24:32 echo: ipsec,debug ipsec_: succeed.
07:24:32 echo: ipsec,debug ipsec_: 24.178.206.251 delete payload for protocol ESP
07:24:32 echo: ipsec ipsec_: purged IPsec-SA proto_id=ESP spi=0xc69bc522
07:24:32 echo: ipsec ipsec_: purged IPsec-SA proto_id=ESP spi=0x2969f24
07:24:32 echo: ipsec,debug ipsec_: an undead schedule has been deleted.
07:24:32 echo: ipsec,debug ipsec_: an undead schedule has been deleted.
07:24:32 echo: ipsec,debug ipsec_: purged SAs.

Here is the configuration export for ppp:
[admin@mt.amg.local] /ppp> export verbose hide-sensitive

mar/08/2018 07:00:50 by RouterOS 6.41.2

/ppp profile
set *0 address-list=“” !bridge !bridge-horizon !bridge-path-cost
!bridge-port-priority change-tcp-mss=yes !dns-server !idle-timeout
!incoming-filter !insert-queue-before !interface-list !local-address name=
default on-down=“” on-up=“” only-one=default !outgoing-filter !parent-queue
!queue-type !rate-limit !remote-address !session-timeout use-compression=
default use-encryption=default use-mpls=default use-upnp=default
!wins-server
add address-list=“” !bridge !bridge-horizon !bridge-path-cost
!bridge-port-priority change-tcp-mss=yes dns-server=172.19.158.254,8.8.8.8
!idle-timeout !incoming-filter !insert-queue-before !interface-list
local-address=172.19.158.1 name=VPN-in on-down=“” on-up=“” only-one=default
!outgoing-filter !parent-queue !queue-type !rate-limit remote-address=
dhcp_pool2 session-timeout=12h use-compression=default use-encryption=
required use-mpls=no use-upnp=default !wins-server
set *FFFFFFFE address-list=“” !bridge !bridge-horizon !bridge-path-cost
!bridge-port-priority change-tcp-mss=yes !dns-server !idle-timeout
!incoming-filter !insert-queue-before !interface-list !local-address name=
default-encryption on-down=“” on-up=“” only-one=default !outgoing-filter
!parent-queue !queue-type !rate-limit !remote-address !session-timeout
use-compression=default use-encryption=yes use-mpls=default use-upnp=
default !wins-server

Here is the L2TP configuration export:
admin@mt.amg.local] /interface l2tp-server> export verbose hide-sensitive
/interface l2tp-server server
set allow-fast-path=no authentication=pap,chap,mschap1,mschap2 caller-id-type=
ip-address default-profile=VPN-in enabled=yes keepalive-timeout=30 max-mru=
1450 max-mtu=1450 max-sessions=unlimited mrru=disabled
one-session-per-host=no use-ipsec=yes

Here is the IPsec configuration export:
[admin@mt.amg.local] /ip ipsec> export verbose hide-sensitive
/ip ipsec mode-config
set [ find default=yes ] name=request-only
/ip ipsec policy group
set [ find default=yes ] name=default
/ip ipsec proposal
set [ find default=yes ] auth-algorithms=sha1 disabled=no enc-algorithms=
aes-128-cbc lifetime=1h name=default pfs-group=modp1024
add auth-algorithms=sha1 disabled=no enc-algorithms=3des lifetime=30m name=L2TP
pfs-group=none
/ip ipsec peer
add address=216.115.92.133/32 auth-method=pre-shared-key dh-group=modp1024
disabled=no dpd-interval=2m dpd-maximum-failures=5 enc-algorithm=aes-128
exchange-mode=main generate-policy=no hash-algorithm=sha1 lifetime=8h
nat-traversal=no policy-template-group=default proposal-check=obey
send-initial-contact=yes
/ip ipsec policy
set 0 disabled=no dst-address=::/0 group=default proposal=L2TP protocol=all
src-address=::/0 template=yes
add action=encrypt disabled=no dst-address=192.168.5.96/27 dst-port=any
ipsec-protocols=esp level=require proposal=default protocol=all
sa-dst-address=216.115.92.133 sa-src-address=10.10.32.38 src-address=
172.19.158.0/26 src-port=any tunnel=yes
/ip ipsec user settings
set xauth-use-radius=no
[admin@mt.amg.local] /ip ipsec>

Any suggestions on what I can do to get the L2TP connection working, while not breaking the existing IPsec site to site VPN?

2

Your configuration suggests that the 'Tik itself does not have a public address on it:

/ip ipsec policy
...
add action=encrypt ... sa-src-address=10.10.32.38 ...

If this is really the case and you have some port forwarding set between the public address and your 'Tik to make the site-to-site VPN work, then the Windows client gets confused by mismatch between the (public) address towards which it has initiated the connection and the private address which it can see inside the session establishment packets. To make things worse, it reports that in a totally obfuscating manner. Reportedly there is some registry setting which allows Windows to accept such connections but I’m not sure it is still true for Win10.

The remedy I’ve used recently is an ugly hack consisting in configuring the public address on the 'Tik itself, e.g. on an “/interface bridge” without any member ports, and setting a dstnat firewall rule which dst-nats the port-forwarded UDP packets to ports 500 and 4500 from anywhere but the public IP of the remote 'Tik back to the public address:

/ip firewall nat add chain=dstnat protocol=udp port=500,4500 src-address=!remote.tik.ip.addr action=dst-nat to-addresses=public.ip.of.this.tik

The result should be that the IPsec subsystem receives packets with that address as destination and therefore it also establishes the L2TP/IPsec connection from that address. It may be more complex than this, at least I’ve originally done that using a more complex setup, but I think this should actually be enough - if not, I’ll suggest you the additional configuration I’ve done previously.

The exception for the public IP of the remote 'Tik is there to make sure that the site-2-site IPsec wouldn’t start believing that there is really no NAT and therefore use plain ESP protocol as transport, as ESP cannot pass through the NAT which actually is there. So if the remote 'Tik is also behind NAT and you don’t need to do the same hack there, the exception rule is not neessary.

3

Thx Sindy for the excellent troubleshootly and suggestions!

Yes, the isp provisions static public ip addresses by NATing 1:1 with the private ip address assigned the the client router WAN port. I hadn’t thought about the fact that the public IP being connected TO was not actually on the WAN interface. I will try the work around you suggested.

Thx again!

4

This hack work wonderfully!
Thanks Sindy

5

So please mark the response as solving the topic issue, to help others with similar problem spot it.