[L2TP+IPSec] Client to Client Connectivity

Hello Everyone!


I have the following network with l2tp/ipsec

Server Router - 10.50.0.10
private address - 192.168.2.254

Client2 Router - 10.50.0.11
private address - 192.168.128.254

Client1 Router - 10.50.0.13
private address - 192.168.5.254





I have connectivity between each of the clients (and hosts behind them) and a server:
i can ping from 192.168.2.1 to 192.168.128.1 and vice versa
the same for other client 192.168.2.1 to 192.168.5.1 and vice versa

but i have no connectivity between clients: i can not ping 10.50.0.13 from 10.50.0.11 and vice versa.

I have configured routes on each router but it's not the cause.
Server

DST-ADDRESS PREF-SRC GATEWAY DISTANCE

8 A S ;;; PPP to client2 network
192.168.5.0/24 10.50.0.10 10.50.0.13 1
9 A S ;;; PPP - to client1 network
192.168.128.0/24 10.50.0.10 10.50.0.11 1
Client1

DST-ADDRESS PREF-SRC GATEWAY DISTANCE

8 A S ;;; PPP to server network
192.168.2.0/24 10.50.0.13 10.50.0.10 1
9 A S ;;; PPP - to client2 network
192.168.128.0/24 10.50.0.13 10.50.0.10 1
Client2

DST-ADDRESS PREF-SRC GATEWAY DISTANCE

8 A S ;;; PPP to server network
192.168.2.0/24 10.50.0.11 10.50.0.10 1
9 A S ;;; PPP - to client1 network
192.168.5.0/24 10.50.0.11 10.50.0.10 1
10.50.0.XX are virtual addresses for the tunnels.
I have public IP only for the server. Clients are behind the ISP NAT.

One important detail here:
at first i have configured only l2tp (without ipsec) and everything worked: there was a connectivity between all of the routers and hosts behind them
(client2 <->client1, client2<->server, client1 <->server)
also there was a NAT rule on each router:
chain=srcnat action=masquerade out-interface=all-ppp log=no log-prefix=""

as part of ipsec configuration i've disabled that rule on each router.
Maybe this caused the issue. but I was told that this rule needs to be disabled and i should use NAT traversal checkbox when configuring IPsec peers.
so now i have client2<->server, client1 <->server but NO client2<->client1 connectivity

I'm definitely missing something in configuration of IPSEC.

Thank you for your attention
Best regards!

You need an exception from a src-nat or masquerade rule for the traffic to be tunnelled using a plain IPsec, because in such setup, ipsec policies cherry-pick packets they like after the NAT handling has been done. In your case, where you use IPsec to carry only the L2TP tunnel and route the site-to-site traffic via that tunnel, this is not necessary.

However, I cannot see how the src-nating of connections between the clients, which you have disabled, should help it work, given that the routes you’ve published are correct (provided that 10.50.0.x are addresses assigned to the L2TP tunnel interfaces of the clients and the server, not their WAN addresses).

So I suspect you have configured the IPsec to steal too much traffic. Can you post your configuration exports following the guideline in my automatic signature?

Hi sindy!

Thank you for your reply!

Here are exports:
Server

# sep/01/2018 18:48:38 by RouterOS 6.34.4
# software id = S8B2-VCX2
#
/interface bridge
add comment=wifi+ethernet name=LAN
/interface wireless
set [ find default-name=wlan1 ] band=2ghz-b/g/n disabled=no mode=ap-bridge ssid=Intornet
/interface ethernet
set [ find default-name=ether5 ] comment=port5 name=AM
set [ find default-name=ether2 ] comment="port2 - master" name=LAN1
set [ find default-name=ether3 ] comment=port3 master-port=LAN1 name=LAN2
set [ find default-name=ether4 ] comment=port4 master-port=LAN1 name=LAN3
set [ find default-name=ether1 ] comment=port1 mac-address=60:67:20:E8:52:E0 name=WAN
/interface pppoe-client
add add-default-route=yes disabled=no interface=WAN max-mru=1480 max-mtu=1480 mrru=1600 name=ISP \
    use-peer-dns=yes user=ISPuser
/interface l2tp-server
add name=gl user=gl
add name=radiologist user=radiologist
add name=radiologist2 user=radiologist2
/ip neighbor discovery
set AM comment=port5
set LAN1 comment="port2 - master"
set LAN2 comment=port3
set LAN3 comment=port4
set WAN comment=port1
set LAN comment=wifi+ethernet
/interface wireless security-profiles
set [ find default=yes ] authentication-types=wpa2-psk eap-methods="" group-ciphers=tkip,aes-ccm mode=\
    dynamic-keys unicast-ciphers=tkip,aes-ccm
/ip pool
add name=dhcp_pool1 ranges=192.168.1.10-192.168.1.50
/ip dhcp-server
add address-pool=dhcp_pool1 disabled=no interface=LAN lease-time=1d name=dhcp
/ppp profile
add change-tcp-mss=yes name=remote_office use-compression=yes use-encryption=yes
/interface bridge port
add bridge=LAN interface=LAN1
add bridge=LAN interface=wlan1
/interface l2tp-server server
set authentication=mschap2 default-profile=remote_office enabled=yes
/ip address
add address=192.168.1.254/24 interface=LAN network=192.168.1.0
add address=109.86.12.192/24 disabled=yes interface=WAN network=109.86.12.0
add address=192.168.2.254/24 interface=AM network=192.168.2.0
/ip dhcp-server lease
add address=192.168.1.102 mac-address=1C:CD:E5:52:0F:18 server=dhcp
add address=192.168.1.101 client-id=1:60:67:20:e8:52:e0 mac-address=60:67:20:E8:52:E0 server=dhcp
add address=192.168.1.103 mac-address=D8:6C:02:9C:74:DE server=dhcp
/ip dhcp-server network
add address=192.168.1.0/24 gateway=192.168.1.254
/ip firewall filter
add chain=input in-interface=WAN protocol=icmp
add chain=input dst-port=1701 protocol=udp
add chain=input dst-port=500 protocol=udp
add chain=input dst-port=4500 protocol=udp
add chain=input protocol=ipsec-esp
add action=drop chain=input in-interface=WAN
# radiologist not ready
add action=drop chain=forward in-interface=radiologist out-interface=LAN
add action=drop chain=forward disabled=yes in-interface=gl out-interface=LAN
add action=drop chain=forward disabled=yes in-interface=LAN out-interface=gl
add action=drop chain=forward disabled=yes in-interface=AM out-interface=LAN
add action=drop chain=forward in-interface=radiologist2 out-interface=LAN
add action=drop chain=forward in-interface=LAN out-interface=radiologist2
# radiologist not ready
add action=drop chain=forward in-interface=LAN out-interface=radiologist
/ip firewall nat
add action=masquerade chain=srcnat out-interface=WAN
add action=masquerade chain=srcnat out-interface=ISP
/ip ipsec peer
add address=0.0.0.0/0 enc-algorithm=aes-256,aes-192,aes-128 exchange-mode=main-l2tp generate-policy=port-strict
/ip ipsec policy
set 0 disabled=yes
add dst-address=192.168.5.0/24 sa-dst-address=10.50.0.13 sa-src-address=10.50.0.10 src-address=192.168.2.0/24 \
    tunnel=yes
add dst-address=192.168.128.0/24 sa-dst-address=10.50.0.11 sa-src-address=10.50.0.10 src-address=192.168.2.0/24 \
    tunnel=yes
add dst-address=192.168.3.0/24 sa-dst-address=10.50.0.12 sa-src-address=10.50.0.10 src-address=192.168.2.0/24 \
    tunnel=yes
/ip route
add disabled=yes distance=1 gateway=109.86.12.254
add comment="PPP - To radiologist network" distance=1 dst-address=192.168.3.0/24 gateway=10.50.0.12 pref-src=\
    10.50.0.10
add comment="PPP to radilogist2 (kv office) network" distance=1 dst-address=192.168.5.0/24 gateway=10.50.0.13
add comment="PPP - to gl network" distance=1 dst-address=192.168.128.0/24 gateway=10.50.0.11
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set ssh disabled=yes
set api disabled=yes
set winbox address=192.168.1.0/24
set api-ssl disabled=yes
/ppp secret
add local-address=10.50.0.10 name=gl profile=remote_office remote-address=10.50.0.11 service=l2tp
add local-address=10.50.0.10 name=radiologist profile=remote_office remote-address=10.50.0.12 service=l2tp
add local-address=10.50.0.10 name=radiologist2 profile=remote_office remote-address=10.50.0.13 service=l2tp
/system clock
set time-zone-autodetect=no
/system leds
set 0 interface=wlan1
/system routerboard settings
set protected-routerboot=disabled
/tool traffic-monitor
add disabled=yes interface=gl name=tmon1 threshold=0 traffic=received
add disabled=yes interface=radiologist name=tmon2 threshold=0

Client1

# aug/30/2018 10:07:53 by RouterOS 6.34.4
# software id = ZUNB-FW0U
#
/interface bridge
add comment=wifi+ethernet name=LAN
/interface wireless
set [ find default-name=wlan1 ] disabled=no mode=ap-bridge ssid=AM
/interface ethernet
set [ find default-name=ether1 ] comment="port1 - master" name=LAN1
set [ find default-name=ether2 ] comment=port2 master-port=LAN1 name=LAN2
set [ find default-name=ether3 ] comment=port3 master-port=LAN1 name=LAN3
set [ find default-name=ether4 ] comment=port4 master-port=LAN1 name=LAN4
set [ find default-name=ether5 ] comment=port5 mac-address=D4:BE:D9:50:B9:7F \
    name=WAN
/interface l2tp-client
add allow=mschap2 connect-to=SERVER_PUBLIC_IP disabled=no mrru=1600 name=gl \
    user=gl
/ip neighbor discovery
set LAN1 comment="port1 - master"
set LAN2 comment=port2
set LAN3 comment=port3
set LAN4 comment=port4
set WAN comment=port5
set LAN comment=wifi+ethernet
/interface wireless security-profiles
set [ find default=yes ] authentication-types=wpa2-psk eap-methods="" \
    group-ciphers=tkip,aes-ccm mode=dynamic-keys unicast-ciphers=tkip,aes-ccm
add authentication-types=wpa2-psk eap-methods="" group-ciphers=tkip,aes-ccm \
    management-protection=allowed mode=dynamic-keys name=wifi_guest \
    supplicant-identity="" unicast-ciphers=tkip,aes-ccm
/interface wireless
add comment="guest access" disabled=no keepalive-frames=disabled mac-address=\
    02:00:00:AA:00:00 master-interface=wlan1 multicast-buffering=disabled name=\
    wlan2 security-profile=wifi_guest ssid=AM_Guest wds-cost-range=\
    0 wds-default-cost=0
/interface wireless manual-tx-power-table
set wlan2 comment="guest access"
/interface wireless nstreme
set *9 comment="guest access"
/ip neighbor discovery
set wlan2 comment="guest access"
/ip ipsec policy group
add name=remote_office
/ip pool
add name=dhcp_pool1 ranges=192.168.128.10-192.168.128.100
add name=dhcp_pool2 ranges=192.168.17.200-192.168.17.220
/ip dhcp-server
add address-pool=dhcp_pool1 disabled=no interface=LAN lease-time=1d name=dhcp1
add address-pool=dhcp_pool2 disabled=no interface=wlan2 lease-time=1h name=\
    dhcp2
/interface bridge port
add bridge=LAN interface=LAN1
add bridge=LAN interface=wlan1
/ip address
add address=192.168.128.254/24 interface=LAN network=192.168.128.0
add address=192.168.17.1/24 interface=wlan2 network=192.168.17.0
/ip dhcp-client
add default-route-distance=0 dhcp-options=hostname,clientid disabled=no \
    interface=WAN
/ip dhcp-server network
add address=192.168.17.0/24 gateway=192.168.17.1
add address=192.168.128.0/24 gateway=192.168.128.254
/ip firewall address-list
add address=192.168.0.5 list="no internet"
/ip firewall filter
add action=drop chain=forward disabled=yes out-interface=WAN src-address=\
    192.168.128.5
add chain=input dst-port=1701 protocol=udp
add chain=input dst-port=4500 protocol=udp
add chain=input dst-port=500 protocol=udp
add chain=input protocol=ipsec-esp
add action=drop chain=forward comment="drop guest wlan from local wlan" \
    dst-address=192.168.128.0/24 src-address=192.168.17.0/24
add action=drop chain=input comment="drop incoming connections" in-interface=\
    WAN
/ip firewall nat
add action=masquerade chain=srcnat out-interface=WAN
add action=masquerade chain=srcnat disabled=yes out-interface=gl
/ip ipsec peer
add address=10.50.0.10/32 enc-algorithm=aes-256,aes-192,aes-128 \
    generate-policy=port-strict policy-template-group=remote_office
/ip ipsec policy
set 0 disabled=yes
add dst-address=192.168.2.0/24 sa-dst-address=10.50.0.10 sa-src-address=\
    10.50.0.11 src-address=192.168.128.0/24 tunnel=yes
/ip route
add comment="to PACS network" distance=1 dst-address=192.168.2.0/24 gateway=\
    10.50.0.10 pref-src=10.50.0.11
add comment="to radiologist network" distance=1 dst-address=192.168.3.0/24 \
    gateway=10.50.0.10 pref-src=10.50.0.11
add comment="to radiologist2 (kv office) network" distance=1 dst-address=\
    192.168.5.0/24 gateway=10.50.0.10 pref-src=10.50.0.11
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set ssh disabled=yes
set api disabled=yes
set api-ssl disabled=yes
/system clock
set time-zone-name=Europe/kv
/system leds
set 0 interface=wlan1
/system routerboard settings
set protected-routerboot=disabled

Client2

# aug/31/2018 02:26:20 by RouterOS 6.41.3
# software id = FEB8-Z5JJ
#
# model = 951Ui-2HnD
# serial number = 8D00089CDC82
/interface bridge
add fast-forward=no name=AM
add fast-forward=no name=LAN
/interface ethernet
set [ find default-name=ether4 ] comment=port4 name=AM1
set [ find default-name=ether5 ] comment=port5 name=AM2
set [ find default-name=ether3 ] comment=port3 name=AM3
set [ find default-name=ether2 ] comment=port2 name=LAN1
set [ find default-name=ether1 ] comment=port1 name=WAN
/interface l2tp-client
add allow=mschap2 comment="l2tp to PACS" connect-to=SERVER_PUBLIC_IP disabled=no \
    mrru=1600 name=PPP_to_Pacs user=radiologist2
/interface wireless
set [ find default-name=wlan1 ] disabled=no mode=ap-bridge name=\
    AM-wlan ssid=AM-guest
/interface wireless security-profiles
set [ find default=yes ] authentication-types=wpa2-psk eap-methods="" mode=\
    dynamic-keys supplicant-identity=MikroTik
add authentication-types=wpa2-psk eap-methods="" management-protection=allowed \
    mode=dynamic-keys name=profile-guest-wifi supplicant-identity=""
add authentication-types=wpa2-psk eap-methods="" management-protection=allowed \
    mode=dynamic-keys name=AM-corp supplicant-identity=""
/interface wireless
add disabled=no keepalive-frames=disabled mac-address=CE:2D:E0:BE:6A:66 \
    master-interface=AM-wlan multicast-buffering=disabled name=\
    AM-corp security-profile=AM-corp ssid=AM \
    wds-cost-range=0 wds-default-cost=0 wps-mode=disabled
/ip ipsec policy group
add name=remote_office
/ip pool
add name=dhcp_pool1 ranges=192.168.6.10-192.168.6.35
add name=guest-wi-fi-pool ranges=192.168.17.10-192.168.17.25
add name=dhcp_pool5 ranges=192.168.6.10-192.168.6.25
/ip dhcp-server
add address-pool=dhcp_pool5 disabled=no interface=LAN lease-time=8h name=dhcp1
/interface bridge port
add bridge=LAN interface=LAN1
add bridge=AM interface=AM3
add bridge=AM interface=AM1
add bridge=AM interface=AM2
add bridge=LAN interface=AM-wlan
add bridge=AM interface=AM-corp
/ip address
add address=192.168.5.254/24 interface=AM network=192.168.5.0
add address=192.168.6.254/24 interface=LAN network=192.168.6.0
/ip dhcp-client
add dhcp-options=hostname,clientid disabled=no interface=WAN
/ip dhcp-server network
add address=192.168.6.0/24 dns-server=8.8.8.8 gateway=192.168.6.254
/ip firewall filter
add action=accept chain=input in-interface=WAN protocol=icmp
add action=accept chain=input dst-port=1701 protocol=udp src-port=""
add action=accept chain=input dst-port=500 protocol=udp
add action=accept chain=input dst-port=4500 protocol=udp
add action=accept chain=input protocol=ipsec-esp
add action=drop chain=input in-interface=WAN
add action=drop chain=forward in-interface=LAN out-interface=AM
add action=drop chain=forward in-interface=AM out-interface=LAN
/ip firewall nat
add action=masquerade chain=srcnat out-interface=WAN
add action=masquerade chain=srcnat disabled=yes out-interface=PPP_to_Pacs
/ip ipsec peer
add address=10.50.0.10/32 dh-group=modp1024 enc-algorithm=\
    aes-256,aes-192,aes-128 exchange-mode=main-l2tp generate-policy=port-strict \
    policy-template-group=remote_office
/ip ipsec policy
set 0 disabled=yes
add dst-address=192.168.2.0/24 sa-dst-address=10.50.0.10 sa-src-address=\
    10.50.0.13 src-address=192.168.5.0/24 tunnel=yes
add dst-address=192.168.128.0/24 sa-dst-address=10.50.0.11 sa-src-address=\
    10.50.0.13 src-address=192.168.5.0/24 tunnel=yes
/ip route
add comment="to PACS network" distance=1 dst-address=192.168.2.0/24 gateway=\
    10.50.0.10
add comment="to radiologist network" distance=1 dst-address=192.168.3.0/24 \
    gateway=10.50.0.10 pref-src=10.50.0.13
add comment="to gl network" distance=1 dst-address=192.168.128.0/24 \
    gateway=10.50.0.10
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set ssh disabled=yes
set api disabled=yes
set api-ssl disabled=yes
/system clock
set time-zone-autodetect=no

Yes, you’ve set it up a bit upside down as compared to what is used normally: instead of using an IPsec tunnel to deliver L2TP packets as the L2TP/IPsec is standardized, you’ve used an L2TP tunnel to deliver IPsec packets. So you have chosen the worst from both worlds.

Now, your IPsec policies only properly cover the traffic between each client and the central server, not the traffic between the clients.

The clients only have the server as a peer, so the policy’s sa-dst-address can only be the server’s one. So in your client configuration, the policy with dst-address=192.168.128.0/24 sa-dst-address=10.50.0.11 sa-src-address=10.50.0.13 src-address=192.168.5.0/24 tunnel=yes will never come up because there is no /ip ipsec peer with address=10.50.0.11 in that configuration. Normally, packets matching that policy’s traffic selector should be delivered using the regular routes, i.e. via the L2TP tunnel without encryption, because the policy is not active so it should be ignoring them, but you’re lucky and it doesn’t work for some reason.

So you have several possibilities:

  • make it the usual L2TP/IPSec way, i.e. to set up IPsec connections between the routers only to carry the L2TP packets and use the existing normal routes for everything except the L2TP transport packets,
  • leave out the L2TP completely and set the IPsec and policies properly, which involves up to as many policies as destination networks on each client, and as many policies as clients on the server (which gives you larger MTU of the payload)
  • fix the current setup which basically means to do the same as above except that you lose some MTU to the L2TP overhead

Which way you want to continue?

Thank you, sindy!

My final purpose is to have secure connection between remote networks. Actually, I’m not expert in networking so my idea was that i setup L2TP tunnels as transport means and IPSec should encrypt the traffic.

I have only 1 Public address for the server and no possibilities to obtain public addresses for the clients.
Also another difficulty in this case that is really problematic to be on-site of 2 clients so I have to choose an option that will allow me to do as much work as possible remotely without engaging other people.( I mean it would be ideal to setup client routers without dropping internet connection on their sides or have the ability to reconnect quickly without much assistance from local personnel.)

But main purpose, nevertheless - I want to make it properly and securely.
As I understand the option 1 in your reply fits this the most? Am I right?
Which of those would you advise in this case?

Well, if networking is not your major and you got this far with IPsec, chapeau.


That’s quite common, and plain IPsec can also deal with it. That’s from where came the advice of the other guy that you should activate NAT traversal support in IPsec configuration, as he apparently also didn’t even dream that you could be transporting IPsec over L2TP (so no NAT traversal necessary as it has been already handled by the L2TP layer in that case).


Well, I understand your current status to be that you can access the client sites from the server one using the L2TP tunnels even if you disable the IPsec peer on the central site, am I right? If so, all the rest can be done remotely, with a little help of Safe Mode. If you switch it on, a snapshot of the configuration is taken, and if you later lock yourself out of the router by some configuration change, which means that the management session stops working, the router detects that in less than a minute and restores the snapshot. When you get past the critical point and the management connection still works, you can switch safe mode off and then eventually switch it on again for another batch of potentially dangerous changes. It is in fact useful to build a habit of doing everything in safe mode, but you have to switch it off and on again from time to time so that you wouldn’t lose too many of your changes if you lock yourself out.


The bad news here is that you have already made a serious mistake - as I understand it, the client devices are already at their respective sites, so they are currently accessible using plain L2TP, which means that they are accessible not only to you but to anyone who is able to break its authentication which is too weak for today’s network jungle. And it uses no encryption whatsoever so even without breaking into your routers, anyone along the path between the routers can sniff the plaintext contents of the data unless the applications which talk together use their own encryption (like TLS).


Option 1 (encrypt L2TP connections using IPsec) means exactly that, adding encryption to the already working setup, the price to pay is that you have two tunneling protocols stacked on top of each other, so less space for the passenger data in each transport packet.

Option 2 keeps only IPsec tunneling in place, which means you save the overhead of the L2TP and have more space in the transport packets for the payload.

In more complex network with dynamic routing protocols, or where you need L2 transparency, you have no other choice but Option 1 (where the transport packets of L2TP or some other tunneling protocol are encrypted using IPsec) despite its drawbacks, but in your case with no chance for redundant paths between two routers, I would myself prefer Option 2. But the choice is yours and Option 1 may be faster to set up. Different parts of your existing configuration may be reused for each of the two options.


A note regarding your firewall configuration - it may be a matter of personal opinion, but I strongly prefer to build the firewall as “deny everything except what you know you need to permit” (this is what you currently have in the input chain) rather than “permit everything except what you know you need to deny” (which is what you currently have in the forward chain). The difference is that if you forget to permit something in the deny-all-but-exceptions variant, your legal users will let you know quickly, whilst if you forget to deny something in the permit-all-but-exceptions variant, your illegal users will let you know never (well, some of them do, asking for a ransom). Here is a supercharged introduction to firewall.

Thank you, sindy for your detailed explanation. It is much appreciated!


Well, I understand your current status to be that you can access the client sites from the server one using the L2TP tunnels even if you disable the IPsec peer on the central site, am I right?

Yes, you’re absolutely right.


The bad news here is that you have already made a serious mistake - as I understand it, the client devices are already at their respective sites, so they are currently accessible using plain L2TP, which means that they are accessible not only to you but to anyone who is able to break its authentication which is too weak for today’s network jungle. And it uses no encryption whatsoever so even without breaking into your routers, anyone along the path between the routers can sniff the plaintext contents of the data unless the applications which talk together use their own encryption (like TLS).

Yes, I understand this. That’s why I’ve started all this with IPsec.

Thank you for the Safe mode. I didn’t know about it. I’ll google how to use it properly.



Option 1 (encrypt L2TP connections using IPsec) means exactly that, adding encryption to the already working setup, the price to pay is that you have two tunneling protocols stacked on top of each other, so less space for the passenger data in each transport packet.

Is this guide ok for implementing option 1 (Basic L2TP/IpSec setup chapter)?
https://wiki.mikrotik.com/wiki/Manual:Interface/L2TP


Option 2 keeps only IPsec tunneling in place, which means you save the overhead of the L2TP and have more space in the transport packets for the payload.

Does the chapter Road Warrior setup with Mode Conf fit my situation? Will I have connectivity between clients in that case?
https://wiki.mikrotik.com/wiki/Manual:IP/IPsec



Thank you for your advice with firewall- i’ll work on that for sure.

What I had in mind is that after such an extended period of exposing some attack surface to the internet, you cannot be 100% sure that someone hasn’t made use of it in the meantime. So to be totally sure, you would have to netinstall all the routers involved.


Yes, except that as you enjoy the luxury of having a Mikrotik at both ends, I would strongly recommend to use IKEv2, which requires to set up the IPsec layer manually at both the client and the server.


Mode Config doesn’t fit here as you need a LAN to LAN connection for which Mode Config is not the most suitable tool, and you don’t need to assign the tunnel address to the client from server side as you have a limited number of static clients (although they are behind NAT). So basically you only need the server to dynamically create policies at its side to reflect those requested by clients, because the sa-dst-address are unknown to the server in advance, until the client connects. And for security reasons (stolen device) you also need to use one of the authentication modes where the clients have individual secrets or certificates; if you don’t happen to have an external RADIUS server at hand on the server site, this boils down to auth-mode=pre-shared-key-xauth.

The connectivity between the clients is ensured by means of the policies. So one possibility is to set up the policies like 192.168.my.subnet to 192.168.whatever, which means a single policy at each client (actually, two, will explain later) and one policy per each client at the server. Another possibility is to set as many policies at each client as the remote subnets the client needs to get to; this means, in your actual case with one central site and three remote ones, three policies per client (unless there is a pair of clients doesn’t need to talk to each other).

The above is equal to having a single route to 192.168.0.0/16 vs. having several individual routes to 192.168.remote.subnetX/mask where you wouldn’t use IPsec.

With normal routes, the exception for local traffic is automatic, as there is always a “connected” route to local LAN subnet, which constitutes an exception from the 192.168.whatever destination; with IPsec policies, you have to place such exception into the policy list manually:

/ip ipsec policy add src-address=192.168.my.subnet/24 dst-address=192.168.my.subnet/24 action=none
/ip ipsec policy add src-address=192.168.my.subnet/24 dst-address=192.168.0.0/16 action=encrypt sa-src-address=0.0.0.0 sa-dst-address=the.server.public.ip level=unique

And unlike with routes where the prefix length od the dst-address automatically defines the search order, so declaration order is irrelevant, the policies’ traffic selectors consist of several fields so the search order strictly follows the declaration order and it is your responsibility to arrange the policies properly.

One more bad news: to be able to use IKEv2 (which is believed to be more secure than its predecessor IKE) to establish the IPsec tunnels, you’ll have to upgrade all your devices to 6.43.2.

Seems i’m kinda lost :slight_smile:

As I understand what i need to do for option 1 (L2TP/IPSEC) is the following:

  1. Revert all my manual IPSec confugurations on all routers. So there is only default (from factory) ipsec config.
  2. Perform IPSEC configuration as described here https://wiki.mikrotik.com/wiki/Manual:Interface/L2TP
    IpSec Config
    On server side:
/ip ipsec proposal
set [ find default=yes ] enc-algorithms=3des,aes-128,aes-192,aes-256
/ip ipsec peer
add generate-policy=port-strict hash-algorithm=sha1 nat-traversal=yes secret=test123456

RouterOS as client:

/ip ipsec proposal
set [ find default=yes ] enc-algorithms=aes-128
/ip ipsec peer
add address=SERVER_PUBLIC_IP_ADDR hash-algorithm=sha1 nat-traversal=yes secret=test123456
  1. Add ipsec policies on each client:

3.1
/ip ipsec policy add src-address=192.168.128.0/24 dst-address=192.168.128.0/24 action=none
/ip ipsec policy add src-address=192.168.128.0/24 dst-address=192.168.0.0/16 action=encrypt sa-src-address=0.0.0.0 sa-dst-address=the.server.public.ip level=unique

3.2
/ip ipsec policy add src-address=192.168.5.0/24 dst-address=192.168.5.0/24 action=none
/ip ipsec policy add src-address=192.168.5.0/24 dst-address=192.168.0.0/16 action=encrypt sa-src-address=0.0.0.0 sa-dst-address=the.server.public.ip level=unique

  1. Rules like that can be disabled
    chain=srcnat action=masquerade out-interface=all-ppp log=no log-prefix=“”

  2. Routes can be left as is

3 A S ;;; to Server network
192.168.2.0/24 10.50.0.13 10.50.0.10 1
7 A S ;;; to Client1 network
192.168.128.0/24 10.50.0.13 10.50.0.10 1



Did I get it correct or messed up everything?

Yes.


Seems the manual isn’t updated carefully… in part of it, generate-policy=port-strict or port-override is already mentioned, but in the example, yes has remained. I have no clue what is correct in 6.34.1, so expect surprises. You want either yes or port-strict, whichever is permitted in your version. Also, add send-initial-contact=no to the peer parameters at the server.


Almost correct. The problem is that the WAN IP of the client may change over time, so you have to cheat and choose some static address on the machine. It will be NATed anyway so it doesn’t matter if you NAT it one more time locally. So you have to add local-address=192.168.x.1 (if that’s the own address of that Mikrotik in its LAN subnet) to peer’s configuration. It would be a non-issue if you would be using a tunnel mode of the SA but tunnel mode costs some extra packet space.

Add send-initial-contact=no to the peer parameters at the client.


The above would be true for Option 2.

For Option 1, i.e. to transport only the L2TP packets, you need to set the policies like this:
/ip ipsec policy add src-address=192.168.x.1 dst-address=SERVER_PUBLIC_IP_ADDR protocol=udp dst-port=1701 tunnel=no
The src-address is the same local IP of the client Mikrotik like used as local-address on the peer.
With tunnel=no, src-address and sa-src-address are the same so only src-address is configured; same for dst.


Not “like that” - this one has to be disabled, but the usual masquerade rule
action=masquerade chain=srcnat out-interface=WAN
must stay.


Correct.

Do it in steps.

  • Be sure you use encrypted connection to the remote site (ssh, WinBox or https - no telnet, no plain http). You’ll be setting the ipsec pre-shared key over the net and you don’t want it to be sniffed on the path between the devices.
  • First configure only the peers, and after a short while, /ip ipsec remote peer print should show you the peer in state established - one at each client, three at the server if you do all clients at the same time. As no policy will be active yet, the L2TP connection will still run without encryption.
  • Then, add the policy at the client, with dst-port=33333 instead of 1701, to see whether it becomes active, a mirror policy with a D (dynamic) sign will appear at the server, and at both, you’ll see a pair of /ip ipsec installed-sa.
  • If all of the above happens, you may disable the policy, modify its dst-port value to 1701, and re-enable it. Your management connection should survive, but now it should now run encrypted. I cannot exclude that it may fail or start behaving weird due to change of MTU on the path, but don’t panic and just open a new one if that happens.
  • if you cannot connect to the client for more than a minute, simply disable the peer at the server. The IPsec connections will go down and so will the policy (after 30 minutes at worst) and you’ll be able to connect to the client again via the unencrypted tunnel.
  • Once you succeed in this with all three clients, your next step will be to add ipsec-policy=in,ipsec to the /ip firewall filter rule chain=input … dst-port=1701 on the server. This is to prevent unencrypted L2TP connections from establishing in future, only packets which emerge from an SA are accepted.

With the configuration above:

  • you are using IKE(v1) exchange mode main; the ultimate goal should be to switch over to IKEv2 which requires an upgrade of all devices
  • you are not using the strongest available encryption and authentication (I would use sha-256 and aes-256 everywhere, in peer settings as well as the proposals, and at least modp3072 as pfs-group in /ip ipsec proposal and as dh-group in /ip ipsec peer. This can be done already before you start, always at both ends (client & server).
  • you have a single common IPsec secret for all clients; the L2TP credentials are only useful for client distinction, not for security. So if someone gets hold of one of the client routers, you cannot cut him off without cutting off the remaining client routers. To change that, you would have to set auth-mode of the peers to pre-shared-key-xauth, and do the following:
  • in clients’ peer configurations, set passive=no and some xauth-login and xauth-password values
    • in server’s peer configuration, set passive=yes and add each client’s xauth-login and xauth-password as name and password in /ip ipsec user
      This is on top of the L2TP credentials. Ideally, the IPsec pre-shared secret as well as the IPsec xauth-passwords should be radomly generated 128-byte strings, i.e. 256 hexadecimal symbol strings with 0x at the beginning. The usernames for L2TP and IPsec may be the same, the passwords for L2TP are probably redundant but I don’t know whether it is possible not to use them at all.

Hi sindy!

First of all thank you for babysitting with me! I can not imagine how much time it would take to setup all this without your help.

So after 2 evenings trying here are my results:


First configure only the peers, and after a short while, /ip ipsec remote peer print should show you the peer in state established - one at each client, three at the server if you do all clients at the same time. As no policy will be active yet, the L2TP connection will still run without encryption.

Succeeded with peers.
I'm able to see remote peers: 2 on the server and 1 for each client. they have status "established"


Then, add the policy at the client, with dst-port=33333 instead of 1701, to see whether it becomes active, a mirror policy with a D (dynamic) sign will appear at the server, and at both, you'll see a pair of /ip ipsec installed-sa.

On one client (6.41.3 Router OS) all happens like you say. Policy becomes active and mirror policy appears on the server. SAs installed.

On other one (6.34.1 Router OS) i can not see whether it's active or not. And no mirror policy generated on server. No installed SAs. So here is the end of story for this client.

ip ipsec policy print 
Flags: T - template, X - disabled, D - dynamic, I - inactive, * - default 
 0 T * group=default src-address=::/0 dst-address=::/0 protocol=all proposal=default template=yes 

 1     src-address=192.168.128.254/32 src-port=any dst-address=SERVER_PUBLIC_IPaddr/32 dst-port=33333 protocol=udp 
       action=encrypt level=require ipsec-protocols=esp tunnel=no sa-src-address=192.168.128.254 
       sa-dst-address=SERVER_PUBLIC_IPaddr proposal=default priority=0

a lot of messages like this in logs of client's server
22:30:25 ipsec,error phase1 negotiation failed due to time up 192.168.128.254[500]
<=>SERVER_PUBLIC_IPaddr[500] 868bacdc9dab1caa:0000000000000000

Remote peer - server still present.


If all of the above happens, you may disable the policy, modify its dst-port value to 1701, and re-enable it. Your management connection should survive, but now it should now run encrypted. I cannot exclude that it may fail or start behaving weird due to change of MTU on the path, but don't panic and just open a new one if that happens.
if you cannot connect to the client for more than a minute, simply disable the peer at the server. The IPsec connections will go down and so will the policy (after 30 minutes at worst) and you'll be able to connect to the client again via the unencrypted tunnel.

After I change dst-port in policy connection gets lost. I'm unable to reconnect and just peer disabling on server helps. After 30min I'm able to connect again to client via winbox.
Even after reenabling peer policy at this client does not become active

Flags: T - template, X - disabled, D - dynamic, I - invalid, A - active, 
* - default 
 0 T * group=default src-address=::/0 dst-address=::/0 protocol=all 
       proposal=default template=yes 

 1     src-address=192.168.5.254/32 src-port=any dst-address=SERVER_PUBLIC_IPaddr/32 
       dst-port=1701 protocol=udp action=encrypt level=require 
       ipsec-protocols=esp tunnel=no proposal=default ph2-count=0

Of course this relates to that client which was able to connect at previous step using 33333 dst port.

Here are my ipsec exports:

Server

/ip ipsec proposal
set [ find default=yes ] auth-algorithms=sha256 enc-algorithms=aes-256-cbc pfs-group=modp3072
/ip ipsec peer
add address=0.0.0.0/0 auth-method=pre-shared-key-xauth dh-group=modp3072 enc-algorithm=aes-256 generate-policy=\
    port-strict hash-algorithm=sha256 passive=yes send-initial-contact=no
/ip ipsec user
add name=User1
add name=User2

----

  ip ipsec policy print 
Flags: T - template, X - disabled, D - dynamic, I - inactive, * - default 
 0 T * group=default src-address=::/0 dst-address=::/0 protocol=all proposal=default template=yes 

 1  D  src-address=SERVER_PUBLIC_IPaddr/32 src-port=33333 dst-address=Client1_detected_IPaddr/32 dst-port=any protocol=udp 
       action=encrypt level=require ipsec-protocols=esp tunnel=no sa-src-address=SERVER_PUBLIC_IPaddr 
       sa-dst-address=Client1_detected_IPaddr priority=2 

 2  D  src-address=SERVER_PUBLIC_IPaddr/32 src-port=1701 dst-address=Client1_detected_IPaddr/32 dst-port=any protocol=udp 
       action=encrypt level=require ipsec-protocols=esp tunnel=no sa-src-address=SERVER_PUBLIC_IPaddr 
       sa-dst-address=Client1_detected_IPaddr priority=2

Client1 (the one which passing step with dst-port 33333) -6.41.3

/ip ipsec proposal
set [ find default=yes ] auth-algorithms=sha256 enc-algorithms=aes-256-cbc \
    pfs-group=modp3072
/ip ipsec peer
add address=SERVER_PUBLIC_IPaddr/32 auth-method=pre-shared-key-xauth dh-group=modp3072 \
    enc-algorithm=aes-256 hash-algorithm=sha256 local-address=192.168.5.254 \
    send-initial-contact=no xauth-login=User1
/ip ipsec policy
add dst-address=SERVER_PUBLIC_IPaddr/32 dst-port=1701 protocol=udp src-address=\
    192.168.5.254/32

Client 2 ( the one on which just peer stage finishes successfully) -6.34.1

/ip ipsec proposal
set [ find default=yes ] auth-algorithms=sha256 enc-algorithms=aes-256-cbc pfs-group=modp3072
/ip ipsec peer
add address=SERVER_PUBLIC_IPaddr/32 auth-method=pre-shared-key-xauth dh-group=modp3072 enc-algorithm=aes-256 \
    hash-algorithm=sha256 local-address=192.168.128.254 send-initial-contact=no
/ip ipsec policy
add dst-address=SERVER_PUBLIC_IPaddr/32 dst-port=33333 protocol=udp sa-dst-address=SERVER_PUBLIC_IPaddr sa-src-address=\
    192.168.128.254 src-address=192.168.128.254/32



Not "like that" - this one has to be disabled, but the usual masquerade rule
action=masquerade chain=srcnat out-interface=WAN
must stay.

Disabled all-ppp rules.
The one you've mentioned is present

Also one detail to mention ( I don't know is this necessary information in this case or not)
Server connects to Internet as PPPoE client so I have NAT rule on it:
add action=masquerade chain=srcnat out-interface=ISP

where ISP is

/interface pppoe-client> print 
Flags: X - disabled, R - running 
 0  R name="ISP" max-mtu=1480 max-mru=1480 mrru=1600 interface=WAN user="user" password="passwd" 
      profile=default keepalive-timeout=60 service-name="" ac-name="" add-default-route=yes 
      default-route-distance=0 dial-on-demand=no use-peer-dns=yes allow=pap,chap,mschap1,mschap2

Hm, it’s most likely related to the cheating. The policy matches on the private src-address (192.168.5.254), but the /interface l2tp-client is sending the L2TP packets with a source address of the interface through which the default route goes, which is the WAN one (PPPoE in this case but that’s not important).

So do the following:
/ip firewall nat print where chain=srcnat
/ip firewall nat add place-before=0 dst-address=SERVER_PUBLIC_IPaddr/32 protocol=udp dst-port=1701 action=src-nat to-addresses=192.168.5.254

This should make the L2TP transport packets (but not the IPsec transport packets into which the former ones get encapsulated) be src-nat’ed to the address which the policy will match.

But before you do the above, change the policy’s dst-port back to 33333, enable it and look whether there are ports (:4500) on the src-address and dst-address shown by /ip ipsec installed-sa print, or whether there is just the IP address with no :port following it. If the ports are there, add the NAT rule as above, change the dst-port in the policy to 1701 and activate it again, it should work this time.

But before you do the above, change the policy’s dst-port back to 33333, enable it and look whether there are ports (:4500) on the src-address and dst-address shown by /ip ipsec installed-sa print, or whether there is just the IP address with no :port following it. If the ports are there, add the NAT rule as above, change the dst-port in the policy to 1701 and activate it again, it should work this time.

Ports were there.

Added rule (it asked for chain so put “srcnat”)

After disabling policy, changing dst port to 1701 and enabling connection was lost.
So seems like I need to disable peer again on the server to connect to that client.

Hm, if only I knew whether it is related to your old RouterOS version or to some conceptual mistake.

While waiting for those 30 minutes, can you see the /ip ipsec installed-sa print to count packets and bytes in either direction? Or just post the output here after replacing the public IP of the server, the keys are temporary so no risk in pasting them.

Here is the output from server.

0 E spi=0xCCDB3C7 src-address=Client1_detected_IPaddr:4500 dst-address=SERVER_PUBLIC_IPaddr:4500 state=mature auth-algorithm=sha256 
     enc-algorithm=aes-cbc auth-key="61de260702cbcbe2fbb52e6ca4a2a64e579437e9f23079b4ffa7707e77c3f576" 
     enc-key="dc53f229b347fc78192fbea1227632dced32a1a2a2e972b5338bb8b8b36e4bf8" add-lifetime=24m/30m replay=128 

 1 E spi=0xBC0461A src-address=Client1_detected_IPaddr:4500 dst-address=SERVER_PUBLIC_IPaddr:4500 state=mature auth-algorithm=sha256 
     enc-algorithm=aes-cbc auth-key="8a5b6a642272f8eea1627c6a0cc570b627ae44e3ca2d4948632bc27f9ebe5523" 
     enc-key="88c08d89d126be6605a98de87e088aec715348698b2afb0c44c9d122b1424b4a" add-lifetime=24m/30m replay=128

Show me the current /ip firewall nat export, /ip ipsec export , and /ip address export from the client… (mind the public IP of the server). As there was no packet shown in either direction of the installed-sa, it seems that the client is not sending which is strange.

Here are exports

# oct/09/2016 13:53:13 by RouterOS 6.41.3
# software id = FEB8-Z5JJ
#
# model = 951Ui-2HnD
# serial number = 8D00089CDC82
/ip firewall nat
add action=src-nat chain=srcnat dst-address=SERVER_PUBLIC_IPaddr dst-port=1701 \
    protocol=udp to-addresses=192.168.5.254
add action=masquerade chain=srcnat out-interface=WAN
add action=masquerade chain=srcnat disabled=yes out-interface=PPP_to_Pacs


/ip ipsec proposal
set [ find default=yes ] auth-algorithms=sha256 enc-algorithms=aes-256-cbc \
    pfs-group=modp3072
/ip ipsec peer
add address=SERVER_PUBLIC_IPaddr/32 auth-method=pre-shared-key-xauth dh-group=\
    modp3072 enc-algorithm=aes-256 hash-algorithm=sha256 local-address=\
    192.168.5.254 secret="secret" send-initial-contact=no \
    xauth-login=User1 xauth-password=passwd
/ip ipsec policy
add dst-address=SERVER_PUBLIC_IPaddr/32 dst-port=1701 protocol=udp src-address=\
    192.168.5.254/32

	
	/ip address
add address=192.168.5.254/24 interface=AM network=192.168.5.0
add address=192.168.6.254/24 interface=LAN network=192.168.6.0

I’ve found this warning on wiki page (https://wiki.mikrotik.com/wiki/Manual:IP/IPsec):

Warning: Ipsec is very sensitive to time changes. If both ends of the IpSec tunnel are not synchronizing time equally(for example, different NTP servers not updating time with the same timestamp), tunnels will break and will have to be established again.

Could this be the cause of fails? I’ve noticed that i have different time on all three routers involved (due to numerous restore configs procedures)

Leaving aside certificate validity as we don’t use certificates here, abrupt jumps in time may cause ipsec connections to drop and re-establish, but an established installed-sa not transporting data is unlikely to be related to difference in absolute time between the peers.

There is nothing in your export which would explain why it doesn’t work the expected way. I’ll have to spend some time fiddling with it in the lab before I’ll be able to tell you whether it needs a small adjustment or whether there is some conceptual gap in it.

Thank you sindy!

Will wait.

I hope that it’s not related to different (and outdated) Router OS versions. But it would be strange as It was possible to implement IPSec on exactly the same software ( wrongly, sure, but still more or less working).


But as I understand you, I will need to update them anyway.
Should I expect complete configuration loss while upgrading from 6.34 to current version?
Should configuration persist while upgrading from 6.41?

You should upgrade in any case as many security vulnerabilities have been patched since 6.34.

The change from 6.34 to 6.43 is quite a big jump, and there was a change of bridge handling between 6.40.x and 6.41, so I would upgrade to 6.40.9 in the first step, and then to 6.43.2, always saving a backup and an export fo a file on flash (I don’t know you device models so it may differ) and downloading them to your PC before upgrading. And of course you should start from the client which can be accessed with least headache. Chances for something to go wrong are low but not zero. Don’t forget to upgrade also the firmware after each RouterOS upgrade.