TLDR: The remote client was not connected to WAN through the configured MikroTik. Thus, the VPN from MikroTik to MikroTik was not working for that client.
Greetings,
I am trying to set up an L2TP vpn site to site encrypted with IPsec. At the moment there are two sites, but it is expected for more sites to be later added to the VPN. Both sites have a MikroTik router. The remote subnet plays the role of the L2TP server with a static public IP. After following online tutorials I have only been able to *partially* set it up. First, it is possible to ping both routers from both networks through the VPN (with the assigned private IP). Second, I am able to reach the local subnet from the remote MikroTik router with a ping. However, the other way around is unreachable (ping the remote subnet from the local subnet/router). I have been reading the MikroTik forums and testing its advice, but nothing has worked so far (changing firewall filters, adding IP routes, toggling L2TP options, etc.).
For instance, these ping work:
192.168.2.1 (local router) <- - -> 192.168.1.1 (remote router)
192.168.1.1 (remote router) - -> 192.168.2.225 (local subnet)
While this ping does not:
192.168.2.1 (local router) -/-> 192.168.1.90 (remote subnet)
(See attached network diagrams).
I do not think the firewall filters are the root of the problem because both routers have near mirrored filters. Moreover, all drop rules should be logged, and I have only seen "invalid" connections be dropped while sending a ping.
Does anyone have any insight about why the L2TP server's LAN is unreachable? And a follow-up, unrelated question: would you recommend WireGuard over L2TP/IPsec for a site to site VPN?
Any advice would be greatly appreciated!
PD. Tutorials I have followed:
1. https://todotelecom.freshdesk.com/suppo ... l2tp-ipsec
2. https://www.cloudbrigade.com/mikrotik-l2tp-vpn-setup/
L2TP site to site cannot reach server's LAN
You do not have the required permissions to view the files attached to this post.
Last edited by sargil on Mon Mar 17, 2025 11:05 am, edited 1 time in total.
Re: L2TP site to site cannot reach server's LAN
First guess, there is no route to local network on remote router. Without configuration export for both sides it's hard to tell. See here viewtopic.php?t=203686
Re: L2TP site to site cannot reach server's LAN
I bet the problem lies with the routing...
...for s2s links use ipip / ipsec
...wireguard uses an algorithm without hardware support
...for s2s links use ipip / ipsec
...wireguard uses an algorithm without hardware support
Re: L2TP site to site cannot reach server's LAN
Sure, here goes the config for these routers (excluding firewall, it's attached in the original answer):
Code: Select all
# GENERIC (same config. at both endpoints)
/interface bridge
add name=bridge1
/interface list
add name=LAN
add name=WAN
/interface bridge port
add bridge=bridge1 interface=LAN
/ip neighbor discovery-settings
set discover-interface-list=none
/ip settings
set tcp-syncookies=yes
/ip dns
set servers=8.8.8.8,1.1.1.1
/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
/tool bandwidth-server
set enabled=no
/tool mac-server
set allowed-interface-list=none
/tool mac-server mac-winbox
set allowed-interface-list=none
/tool mac-server ping
set enabled=no
# L2TP SERVER
/ip dhcp-server network
add address=192.168.1.0/24 dns-server=8.8.8.8,1.1.1.1 gateway=192.168.1.1
/ip route
add gateway=X
# VPN route:
add dst-address=192.168.2.0/24 gateway=10.200.1.2
/ip address
add address=192.168.1.1/24 interface=bridge1 network=192.168.1.0
/ppp profile
add local-address=10.200.1.1 name=tunel-L2TP use-encryption=required
/interface l2tp-server server
set default-profile=tunel-L2TP enabled=yes \
use-ipsec=required ipsec-secret=X
# Secret for "client 1" in the network diagram.
/ppp secret
add name=X profile=tunel-L2TP service=l2tp \
local-address=10.200.1.1 remote-address=10.200.1.2 \
password=X
# L2TP CLIENT 1
/ip pool
add name=dhcp1 ranges=192.168.2.200-192.168.2.254
/ip dhcp-server
add address-pool=dhcp1 interface=bridge1 name=dhcp
/ip cloud
set ddns-enabled=yes ddns-update-interval=30m update-time=yes
/ip dhcp-server lease
add address=192.168.2.213 client-id=a:aa:aa:a:aa:aa:aa mac-address=aa:aa:aa:aa:aa:aa server=dhcp
/ip dhcp-server network
add address=192.168.2.0/24 dns-server=8.8.8.8,1.1.1.1 gateway=192.168.2.1
/ip route
add dst-address=0.0.0.0/0 gateway=192.168.10.10
# VPN route:
add dst-address=192.168.1.0/24 gateway=10.200.1.1
/interface l2tp-client
add connect-to=X disabled=no ipsec-secret=X \
name=VPN password=X \
use-ipsec=yes user=X
/ip ipsec profile
set [ find default=yes ] enc-algorithm=aes-256,aes-192,aes-128 hash-algorithm=sha256
/ip ipsec proposal
set [ find default=yes ] auth-algorithms=sha256,sha1 enc-algorithms="aes-256-cbc,aes-256-ctr,aes-256-gcm,ae\
s-192-cbc,aes-192-ctr,aes-192-gcm,aes-128-cbc,aes-128-ctr,aes-128-gcm" pfs-group=modp2048Yes, looking into it, L2TP/IPsec is preferred over WireGuard for site to site tunnels....for s2s links use ipip / ipsec
...wireguard uses an algorithm without hardware support
Re: L2TP site to site cannot reach server's LAN
on client1 try to set vpn interface as gateway, not an IP address
Code: Select all
/ip route
# VPN route:
add dst-address=192.168.1.0/24 gateway=VPNRe: L2TP site to site cannot reach server's LAN
[size=150][/size][quote]Yes, looking into it, L2TP/IPsec is preferred over WireGuard for site to site tunnels.[/quote]
is that from a security perspective or CPU performance impact on the router?
thanks
is that from a security perspective or CPU performance impact on the router?
thanks
Re: L2TP site to site cannot reach server's LAN
on client1 try to set vpn interface as gateway, not an IP addressCode: Select all/ip route # VPN route: add dst-address=192.168.1.0/24 gateway=VPN
Right now, there is a route which I guess it was automatically defined while setting the L2TP-client, and does not show in these export configs... The guides I followed used an "intermediary" private network (i.e. 10.200.1.1). The route shows as active, but the remote subnet is still unreachable.
Code: Select all
Dst. Address Gateway
10.200.1.1/32 VPN interface # route to reach L2TP server through VPN interface?
192.168.1.0/24 10.200.1.1 # route to reach remote subnet from assigned private IP to VPN connection?
192.168.1.0/24 VPN interface # Same as above?
Well, from a personal/beginner perspective (still reading about it, advice welcome), we think that WireGuard VPN should be set up in each computer, right? Instead of a connection from router to router (site to site)? Which for us is undesired.is that from a security perspective or CPU performance impact on the router?
thanks
Re: L2TP site to site cannot reach server's LAN
Please post complete configs of both devices the way they actually are, because "similar" is not good enough - in your "common" firewall export, there is just one of the LAN subnets in the allowed_to_router address list (add address=192.168.1.1-192.168.1.254 list=allowed_to_router). Just don't forget to obfuscate sensitive information.
You gave a lot of care to inividual treatment of different ICMP type packets but your input filter rules contain no action=drop rule except the one that matches on connection-state=invalid, so your devices listening on public addresses may be misused e.g. for DNS response attacks.
You have also given a lot of care to prevent your network from sending nonsense outside, but the nonsense won't get anywhere anyway so there is also not much point in doing that.
My impression is that the firewall examples in Mikrotik documentations are more oriented to demonstrate the various capabilities but people take them as something mandatory; if you look at the firewall configuration Mikrotik ships as default for the SOHO models, it looks very different from those examples - not only is it way simpler but it also provides better protection.
For a multi-user environment, Wireguard is an administrative nightmare and its overall security as compared to e.g. L2TP/IPsec is not that much better because in a typical case, the administrator has to assign and deliver the private key to the users, so the advantage of the private key never leaving the device that identifies itself using it is lost. If an administrator wants to change the address assigned to the client, the change needs to be done at both the "server" side and in the configuration file on the user's device.
Having said that, there is actually no one-size-fits-all "best" VPN type for nomadic users, as each standards-based VPN client has some limitations. With Windows, I prefer IKEv2 with RADIUS username/password authentication, because it allows both a kind of MFA and pushing routes to the client (it is a decision of Mikrotik that SSTP and L2TP do not support that although the mechanism used on Windows side is the same like the one used for IKEv2), but with Android and Apple clients, pushing routes has limitations.
You gave a lot of care to inividual treatment of different ICMP type packets but your input filter rules contain no action=drop rule except the one that matches on connection-state=invalid, so your devices listening on public addresses may be misused e.g. for DNS response attacks.
You have also given a lot of care to prevent your network from sending nonsense outside, but the nonsense won't get anywhere anyway so there is also not much point in doing that.
My impression is that the firewall examples in Mikrotik documentations are more oriented to demonstrate the various capabilities but people take them as something mandatory; if you look at the firewall configuration Mikrotik ships as default for the SOHO models, it looks very different from those examples - not only is it way simpler but it also provides better protection.
As for which VPN protocol to use for what: Wireguard is fine for home users who are also the administrators, because its configuration is wonderfully simple - which it indeed is, but simply due to the lack of any options. It is also considered great for weak devices as its encryption algorithm uses the CPU very efficiently, but the same algorithm can be used also for IPsec since months ago.Well, from a personal/beginner perspective (still reading about it, advice welcome), we think that WireGuard VPN should be set up in each computer, right? Instead of a connection from router to router (site to site)? Which for us is undesired.
For a multi-user environment, Wireguard is an administrative nightmare and its overall security as compared to e.g. L2TP/IPsec is not that much better because in a typical case, the administrator has to assign and deliver the private key to the users, so the advantage of the private key never leaving the device that identifies itself using it is lost. If an administrator wants to change the address assigned to the client, the change needs to be done at both the "server" side and in the configuration file on the user's device.
Having said that, there is actually no one-size-fits-all "best" VPN type for nomadic users, as each standards-based VPN client has some limitations. With Windows, I prefer IKEv2 with RADIUS username/password authentication, because it allows both a kind of MFA and pushing routes to the client (it is a decision of Mikrotik that SSTP and L2TP do not support that although the mechanism used on Windows side is the same like the one used for IKEv2), but with Android and Apple clients, pushing routes has limitations.
Re: L2TP site to site cannot reach server's LAN
Hello,
@sindy thanks for your in-depth and well-put response! You are absolutely right that, because I was learning its capabilities, many settings were copy-pasted from the manuals (e.g. the massive ICMP block)
We just set up this router as a minimal working test/example. We expect to adjust and improve its (firewall) settings later on. I saw that the default settings you mentioned for the firewall are maintained in a post [1] within this forum, right?
[1]: viewtopic.php?f=13&t=175129&p=856824&hi ... es#p856824
About DDoS protection: we have a rule on the client-side which I didn't include in the exported settings. Now I have included the WHOLE settings below (some IPs change from the diagrams) . This DDoS filter caused some issues by blacklisting a client within the network. Our solution was to add 'src-address=!192.168.0.0/24' to avoid private IPs to jump to the DDoS chain (is this a good idea?).
PD. The issue with the VPN persists.
Could it be caused by a lack of a dhcp-server within the L2TP server router (while L2TP client does have it, and thus L2TP server is correctly assigned IPs from this subnet)? I'm grasping at straws
@sindy thanks for your in-depth and well-put response! You are absolutely right that, because I was learning its capabilities, many settings were copy-pasted from the manuals (e.g. the massive ICMP block)
We just set up this router as a minimal working test/example. We expect to adjust and improve its (firewall) settings later on. I saw that the default settings you mentioned for the firewall are maintained in a post [1] within this forum, right?
[1]: viewtopic.php?f=13&t=175129&p=856824&hi ... es#p856824
About DDoS protection: we have a rule on the client-side which I didn't include in the exported settings. Now I have included the WHOLE settings below (some IPs change from the diagrams) . This DDoS filter caused some issues by blacklisting a client within the network. Our solution was to add 'src-address=!192.168.0.0/24' to avoid private IPs to jump to the DDoS chain (is this a good idea?).
Does anyone happen to know any guides about using the algorithm of WireGuard with IPsec? Would it be recommended? Would it change its behaviour and require setting up auth codes to each client instead of setting it up once at the router?The same algorithm (WireGuard) can be used also for IPsec since months ago.
PD. The issue with the VPN persists.
Could it be caused by a lack of a dhcp-server within the L2TP server router (while L2TP client does have it, and thus L2TP server is correctly assigned IPs from this subnet)? I'm grasping at straws
Code: Select all
# Exported settings for both routers.
# L2TP SERVER (with static public IP)
# RouterOS 7.17.2
#
/interface bridge
add name=bridge1
/interface ethernet
set [ find default-name=ether1 ] disable-running-check=no
set [ find default-name=ether2 ] disable-running-check=no
/interface list
add name=LAN
add name=WAN
# I should read more about this:
/ip ipsec proposal
set [ find default=yes ] auth-algorithms=sha256,sha1 enc-algorithms="aes-256-c\
bc,aes-256-ctr,aes-256-gcm,aes-192-cbc,aes-192-ctr,aes-192-gcm,aes-128-cbc\
,aes-128-ctr,aes-128-gcm" pfs-group=modp2048
# "Required encryption" for L2TP tunnel.
/ppp profile
add name=tunel-L2TP use-encryption=required
/interface bridge port
add bridge=bridge1 interface=LAN
/ip neighbor discovery-settings
set discover-interface-list=none
/ip settings
set tcp-syncookies=yes
# L2TP server with required IPsec.
/interface l2tp-server server
set default-profile=tunel-L2TP enabled=yes use-ipsec=required
/interface list member
add interface=ether2 list=LAN
add interface=ether1 list=WAN
/ip address
add address=X interface=ether1 network=X
add address=192.168.15.1/24 interface=ether2 network=192.168.15.0
/ip dhcp-client
add interface=ether1
/ip dhcp-server network
add address=192.168.15.0/24 dns-server=8.8.8.8,1.1.1.1 gateway=192.168.15.1
/ip dns
set servers=8.8.8.8,1.1.1.1
/ip firewall address-list
# Site A (server)
add address=192.168.15.1-192.168.15.254 list=allowed_to_router
# Site B (client) but is this required?
add address=192.168.0.1-192.168.0.254 comment="L2TP-client addresses" list=\
allowed_to_router
# The following range might be wrong (it should be 10.231.1.1-10.231.1.254???)
add address=10.231.1.1-10.231.3.254 list=allowed_to_router
add address=0.0.0.0/8 comment=RFC6890 list=not_in_internet
add address=172.16.0.0/12 comment=RFC6890 list=not_in_internet
add address=192.168.0.0/16 comment=RFC6890 list=not_in_internet
add address=10.0.0.0/8 comment=RFC6890 list=not_in_internet
add address=169.254.0.0/16 comment=RFC6890 list=not_in_internet
add address=127.0.0.0/8 comment=RFC6890 list=not_in_internet
add address=224.0.0.0/4 comment=Multicast list=not_in_internet
add address=198.18.0.0/15 comment=RFC6890 list=not_in_internet
add address=192.0.0.0/24 comment=RFC6890 list=not_in_internet
add address=192.0.2.0/24 comment=RFC6890 list=not_in_internet
add address=198.51.100.0/24 comment=RFC6890 list=not_in_internet
add address=203.0.113.0/24 comment=RFC6890 list=not_in_internet
add address=100.64.0.0/10 comment=RFC6890 list=not_in_internet
add address=240.0.0.0/4 comment=RFC6890 list=not_in_internet
add address=192.88.99.0/24 comment="6to4 relay Anycast [RFC 3068]" list=\
not_in_internet
/ip firewall filter
add action=accept chain=input comment=\
"Accepta connexions <input> conegudes,untracked (basic)" \
connection-state=established,related,untracked
add action=accept chain=input comment=\
"Accepta entrada al router des de LAN\?" src-address-list=\
allowed_to_router
add action=accept chain=input comment="Accepta sempre protocol ICMP" \
protocol=icmp
add action=accept chain=input comment="Accepta loopback (per CAPsMAN\?)" \
dst-address=127.0.0.1
add action=accept chain=input comment=\
"Accepta UDP dels ports IPSEC (L2TP VPN)" dst-port=1701,500,4500 \
in-interface-list=WAN protocol=udp
add action=accept chain=input comment="Accepta protocol IPSEC (L2TP VPN)" \
protocol=ipsec-esp
add action=drop chain=input comment=\
"Exclou connexions <input> invalides (basic)" connection-state=invalid \
log=yes log-prefix=input_invalid
add action=fasttrack-connection chain=forward comment=FastTrack \
connection-state=established,related hw-offload=yes
add action=accept chain=forward comment=\
"Accepta connexions <forward> conegudes,untracked (basic)" \
connection-state=established,related,untracked
add action=accept chain=forward comment=\
"Accepta entrada politica IPSEC <forward>" ipsec-policy=in,ipsec
add action=accept chain=forward comment=\
"Accepta sortida politica IPSEC <forward>" ipsec-policy=out,ipsec
add action=accept chain=forward comment=\
"Sortida a internet des de la xarxa local" src-address-list=\
allowed_to_router
add action=drop chain=forward comment=\
"Exclou connexions <forward> invalides (basic)" connection-state=invalid \
log=yes log-prefix=forward_invalid
add action=drop chain=forward comment=\
"Frena paquets <forward> d'origen privat i entrant per WAN" \
dst-address-list=not_in_internet in-interface=bridge1 log=yes log-prefix=\
private_from_LAN out-interface=!bridge1
add action=drop chain=forward comment=\
"Frena paquets <forward> sense <DSTNAT>" connection-nat-state=!dstnat \
connection-state=new in-interface-list=WAN log=yes log-prefix=sense_NAT
add action=jump chain=forward comment=\
"Salta des de <forward> fins als filtres <ICMP>" jump-target=icmp \
protocol=icmp
add action=drop chain=forward comment=\
"Frena paquets <forward> d'origen privat i entrant per WAN" \
in-interface-list=WAN log=yes log-prefix=privat_entrant_WAN \
src-address-list=not_in_internet
add action=drop chain=forward comment="Frena paquets LAN sense IP correcta" \
in-interface=bridge1 log=yes log-prefix=LAN_IP_incorrecta \
src-address-list=!allowed_to_router
add action=accept chain=icmp comment="echo reply" icmp-options=0:0 protocol=\
icmp
add action=accept chain=icmp comment="Xarxa fora d'abast" icmp-options=3:0 \
protocol=icmp
add action=accept chain=icmp comment="Amfitrio (<host>) fora d'abast" \
icmp-options=3:1 protocol=icmp
add action=accept chain=icmp comment=\
"Amfitrio (<host>) fora d'abast; necessita fragmentacio" icmp-options=3:4 \
protocol=icmp
add action=accept chain=icmp comment="Permet peticions d'<echo>" \
icmp-options=8:0 protocol=icmp
add action=accept chain=icmp comment="Permet quan es supera el temps" \
icmp-options=11:0 protocol=icmp
add action=accept chain=icmp comment="Permet error amb els parametres" \
icmp-options=12:0 protocol=icmp
add action=drop chain=icmp comment="Rebutja la resta de peticions ICMP" log=\
yes log-prefix=drop_other_ICMP
/ip firewall nat
add action=masquerade chain=srcnat comment="<Masquerade> predeterminada" \
ipsec-policy=out,none out-interface-list=WAN
/ip ipsec profile
set [ find default=yes ] enc-algorithm=aes-256,aes-192,aes-128 \
hash-algorithm=sha256
/ip route
add gateway=X
# The IP route for the L2TP/IPsec tunnel for reaching 'local/client' subnet.
add disabled=no distance=1 dst-address=192.168.0.0/24 gateway=10.231.1.2 \
routing-table=main scope=30 suppress-hw-offload=no target-scope=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
# Two different subnets (different sites) should be assigned different ppp secrets, right?
# With incremental 'remote-addresses'? (from 10.231.1.1 of the server, onwards to 10.231.1.254).
/ppp secret
add local-address=10.231.1.1 name=X profile=tunel-L2TP \
remote-address=10.231.1.2 service=l2tp
add local-address=10.231.1.1 name=X profile=tunel-L2TP \
remote-address=10.231.1.3 service=l2tp
/system note
set show-at-login=no
/tool bandwidth-server
set enabled=no
/tool mac-server
set allowed-interface-list=none
/tool mac-server mac-winbox
set allowed-interface-list=none
/tool mac-server ping
set enabled=no
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# L2TP CLIENT
# RouterOS 7.17.2
#
/interface bridge
add name=bridge1
/interface ethernet
set [ find default-name=ether1 ] disable-running-check=no
set [ find default-name=ether2 ] disable-running-check=no
/interface l2tp-client
add connect-to=X disabled=no name=\
"VPN tunnel site to site" use-ipsec=yes user=X
/interface list
add name=LAN
add name=WAN
# I should read more about this:
/ip ipsec proposal
set [ find default=yes ] auth-algorithms=sha256,sha1 enc-algorithms="aes-256-c\
bc,aes-256-ctr,aes-256-gcm,aes-192-cbc,aes-192-ctr,aes-192-gcm,aes-128-cbc\
,aes-128-ctr,aes-128-gcm" pfs-group=modp2048
/ip pool
add name=dhcp1 ranges=192.168.0.200-192.168.0.254
/ip dhcp-server
add address-pool=dhcp1 interface=bridge1 name=dhcp
/interface bridge port
add bridge=bridge1 interface=LAN
/ip neighbor discovery-settings
set discover-interface-list=none
/ip settings
set tcp-syncookies=yes
/interface list member
add interface=ether2 list=LAN
add interface=ether1 list=WAN
/ip address
add address=192.168.1.1/24 interface=ether1 network=192.168.1.0
add address=192.168.0.1/24 interface=ether2 network=192.168.0.0
/ip cloud
set ddns-enabled=yes ddns-update-interval=30m update-time=yes
/ip dhcp-client
add interface=ether1
/ip dhcp-server lease
add address=192.168.0.213 client-id=X mac-address=X server=dhcp
/ip dhcp-server network
add address=192.168.0.0/24 dns-server=8.8.8.8,1.1.1.1 gateway=192.168.0.1
/ip dns
set servers=8.8.8.8,1.1.1.1
/ip firewall address-list
add address=192.168.0.1-192.168.0.254 list=allowed_to_router
add address=192.168.15.1-192.168.15.254 comment="VPN remote addresses" list=\
allowed_to_router
# The following range might be wrong (it should be 10.231.1.1-10.231.1.254???)
add address=10.231.1.1-10.231.3.254 list=allowed_to_router
add address=0.0.0.0/8 comment=RFC6890 list=not_in_internet
add address=172.16.0.0/12 comment=RFC6890 list=not_in_internet
add address=192.168.0.0/16 comment=RFC6890 list=not_in_internet
add address=10.0.0.0/8 comment=RFC6890 list=not_in_internet
add address=169.254.0.0/16 comment=RFC6890 list=not_in_internet
add address=127.0.0.0/8 comment=RFC6890 list=not_in_internet
add address=224.0.0.0/4 comment=Multicast list=not_in_internet
add address=198.18.0.0/15 comment=RFC6890 list=not_in_internet
add address=192.0.0.0/24 comment=RFC6890 list=not_in_internet
add address=192.0.2.0/24 comment=RFC6890 list=not_in_internet
add address=198.51.100.0/24 comment=RFC6890 list=not_in_internet
add address=203.0.113.0/24 comment=RFC6890 list=not_in_internet
add address=100.64.0.0/10 comment=RFC6890 list=not_in_internet
add address=240.0.0.0/4 comment=RFC6890 list=not_in_internet
add address=192.88.99.0/24 comment="6to4 relay Anycast [RFC 3068]" list=\
not_in_internet
# 'Atacants' means attacker, 'diana' are targets.
add list=ddos-atacants
add list=ddos-diana
/ip firewall filter
add action=accept chain=input comment=\
"Accepta connexions <input> conegudes,untracked (basic)" \
connection-state=established,related,untracked
add action=accept chain=input comment=\
"Accepta entrada al router des de LAN\?" src-address-list=\
allowed_to_router
add action=accept chain=input comment="Accepta sempre protocol ICMP" \
protocol=icmp
add action=accept chain=input comment="Accepta loopback (per CAPsMAN\?)" \
dst-address=127.0.0.1
add action=accept chain=input comment=\
"Accepta UDP dels ports IPSEC (L2TP VPN)" dst-port=1701,500,4500 \
in-interface-list=WAN protocol=udp
add action=accept chain=input comment="Accepta protocol IPSEC (L2TP VPN)" \
protocol=ipsec-esp
add action=drop chain=input comment=\
"Exclou connexions <input> invalides (basic)" connection-state=invalid \
log=yes log-prefix=input_invalid
add action=jump chain=forward comment=\
"Nou trfic talla intents DDoS (origen extern)" connection-state=new \
jump-target=detecta-ddos src-address=!192.168.0.0/24
add action=fasttrack-connection chain=forward comment=FastTrack \
connection-state=established,related hw-offload=yes
add action=accept chain=forward comment=\
"Accepta connexions <forward> conegudes,untracked (basic)" \
connection-state=established,related,untracked
add action=accept chain=forward comment=\
"Accepta entrada politica IPSEC <forward>" ipsec-policy=in,ipsec
add action=accept chain=forward comment=\
"Accepta sortida politica IPSEC <forward>" ipsec-policy=out,ipsec
add action=accept chain=forward comment=\
"Sortida a internet des de la xarxa local" src-address-list=\
allowed_to_router
add action=drop chain=forward comment=\
"Exclou connexions <forward> invalides (basic)" connection-state=invalid \
log=yes log-prefix=forward_invalid
add action=drop chain=forward comment=\
"Frena paquets <forward> d'origen privat i entrant per WAN" \
dst-address-list=not_in_internet in-interface=bridge1 log=yes log-prefix=\
private_from_LAN out-interface=!bridge1
add action=drop chain=forward comment=\
"Frena paquets <forward> sense <DSTNAT>" connection-nat-state=!dstnat \
connection-state=new in-interface-list=WAN log=yes log-prefix=sense_NAT
add action=jump chain=forward comment=\
"Salta des de <forward> fins als filtres <ICMP>" jump-target=icmp \
protocol=icmp
add action=drop chain=forward comment=\
"Frena paquets <forward> d'origen privat i entrant per WAN" \
in-interface-list=WAN log=yes log-prefix=privat_entrant_WAN \
src-address-list=not_in_internet
add action=drop chain=forward comment="Frena paquets LAN sense IP correcta" \
in-interface=bridge1 log=yes log-prefix=LAN_IP_incorrecta \
src-address-list=!allowed_to_router
add action=accept chain=icmp comment="echo reply" icmp-options=0:0 protocol=\
icmp
add action=accept chain=icmp comment="Xarxa fora d'abast" icmp-options=3:0 \
protocol=icmp
add action=accept chain=icmp comment="Amfitrio (<host>) fora d'abast" \
icmp-options=3:1 protocol=icmp
add action=accept chain=icmp comment=\
"Amfitrio (<host>) fora d'abast; necessita fragmentacio" icmp-options=3:4 \
protocol=icmp
add action=accept chain=icmp comment="Permet peticions d'<echo>" \
icmp-options=8:0 protocol=icmp
add action=accept chain=icmp comment="Permet quan es supera el temps" \
icmp-options=11:0 protocol=icmp
add action=accept chain=icmp comment="Permet error amb els parametres" \
icmp-options=12:0 protocol=icmp
add action=drop chain=icmp comment="Rebutja la resta de peticions ICMP" log=\
yes log-prefix=drop_other_ICMP
add action=return chain=detecta-ddos dst-limit=\
32,32,src-and-dst-addresses/10s
add action=add-dst-to-address-list address-list=ddos-diana \
address-list-timeout=10m chain=detecta-ddos
add action=add-src-to-address-list address-list=ddos-atacants \
address-list-timeout=10m chain=detecta-ddos
/ip firewall nat
add action=masquerade chain=srcnat comment="<Masquerade> predeterminada" \
ipsec-policy=out,none out-interface-list=WAN
/ip firewall raw
add action=drop chain=prerouting comment=\
"Impedeix connexions marcades com a potencial DDoS" dst-address-list=\
ddos-diana src-address-list=ddos-atacants
/ip ipsec profile
set [ find default=yes ] enc-algorithm=aes-256,aes-192,aes-128 \
hash-algorithm=sha256
/ip route
# Route from mikrotik to Orange's router.
add dst-address=0.0.0.0/0 gateway=192.168.1.10
# The IP route for the L2TP/IPsec tunnel for reaching 'remote/server' subnet.
add dst-address=192.168.15.0/24 gateway=10.231.1.1
/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 note
set show-at-login=no
/tool bandwidth-server
set enabled=no
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN
/tool mac-server ping
set enabled=no
Re: L2TP site to site cannot reach server's LAN
@rextended is indeed doing a good job there.the default settings you mentioned for the firewall are maintained in a post [1] within this forum
It is enough to add/enable the chacha20poly1305 as enc-algorithms of the default row of /ip/ipsec/proposal on both the L2TP server/IPsec responder side and at the L2TP client/IPsec initiator side. When L2TP is asked to generate the IPsec configuration, it uses a policy template from group default to dynamically create the necessary /ip/ipsec/policy item, and that template uses the default item from /ip/ipsec/proposal unless you change that.Does anyone happen to know any guides about using the algorithm of WireGuard with IPsec? Would it be recommended? Would it change its behaviour and require setting up auth codes to each client instead of setting it up once at the router?
Be careful - the actual algorithms to be used for Phase 1 (IKE) and Phase 2 (data SAs) are chosen among those that both the initiator and the responder support, so if you permit only chacha20poly1305 as enc-algorithms at one device and the other device does not support that encryption algorithm at all, Phase 2 will not establish between them. You have to think about this when you plan to use the L2TP server both to set up a site-to-site tunnel and to allow PCs and phones to connect.
Also, if all the encryption algorithms in a profile provide also the message authentication (in addition to chacha20poly1305, also aes-gcm behaves that way), the auth-algorithm list must be empty ("") - setting it to none throws an error.
But bear in mind that it only makes sense to use chacha20poly1305 for IPsec Phase 2 if one of the devices does not support any of the AES algorithms in hardware, because even though chacha20poly1305 is optimized for implementation in software with a minimum CPU use, it still uses the CPU quite a lot so its use has an impact on the overall throughput of the device. It just takes less CPU as compared to AES running also in software.
Regarding the initial issue:
The routes on the router seem fine to me, and the firewall is still unusual but shoud not interfere.
What is definitely wrong is that the LAN IP addresses are attached to a member port of bridge1 (ether2) rather than bridge1 itself; it semi-works but it causes surprises. I don't think it is related to your issue but nevertheless fix it to prevent future headaches.
There is also another potential issue - even the best intentions can turn into PITAs. Traditionally (as in "in all the examples and in common communication"), the name LAN is used for lists of IP interfaces that are considered LAN ones. An interface that is member port of a bridge is not an IP interface any more, the IP configuration should be attached to the bridge (as in "the virtual interface of the router to which the virtual switch is connected") instead, so if you use an interface list to add its member interfaces as member ports of a bridge, that list should bear some other name than LAN - the bridge itself cannot be a member of it (otherwise you get an error for adding a bridge as a member port of itself) but should a rule your IP firewall refer to interface list LAN whilst bridge1 would not be a member of that list, the rule would behave differently from what you'd expect it to. In your simple configuration, I would make ether2 a member port of the bridge directly, not via an interface list, and keep the name LAN for the usual purpose.
There is one catch - Windows computers by default ignore ping requests that come from outside their connected subnets. So when you say that you cannot ping via the tunnel, what kind of device is the target of the ping?
To see what is going on, the best approach is to use /tool/sniffer. Let's say you are going to ping a device with address 192.168.0.222 on the L2TP client site from a device with address 192.168.15.111 on the L2TP server site. Before starting the ping, run /interface/bridge/port/set [find] hw=no on both devices to avoid some packets from not being shown during sniffing, open a command line (terminal) window on each router, make it as wide as your screen allows, and in those wide windows, run /tool/sniffer/quick ip-address=192.168.0.222 ip-protocol=icmp on the server site and /tool/sniffer/quick ip-address=192.168.15.111 ip-protocol=icmp on the client site. Then start pinging .0.222 from .15.111. If everything is configured correctly, you should see the ping request to get in via ether2 and bridge1 and leave through <l2tp-X> on the server, arrive through "VPN tunnel site to site" to the client site, and leave through bridge1 and ether2 to the connected device in LAN. The response of the .0.222, if any, should take the same path in reverse order. The root cause of the issue is located where the actual results of the sniffing differ from the expected ones.
One more remark that again has nothing to do with the issue itself - the use-encryption item on the /ppp/profile row has nothing to do with IPsec. It enables or disables the use fo MPPE encryption on PPP level which only increases CPU load, not the level of security, if the PPP transport packets are encrypted (using IPsec in your case or using TLS for the SSTP tunnels).
Re: L2TP site to site cannot reach server's LAN [SOLVED]
The device in the remote subnet we were trying to ping had 2 network interfaces. One of them was connected to a LAN (with the L2TP server mikrotik) while the other had direct access to WAN without going through this mikrotik router. Confusingly, the device responded to pings from the remote mikrotik, although it was not using it as its WAN gateway. We then disabled the network interface with direct WAN access and the issue was solved. Now the device receives and sends ping through the VPN gateway as expected.
Once again @sindy thanks for your advice; we should've started with the sniffing tool way earlier. We discovered the issue while performing 'tracepath' from the remote device to a local device. We saw that the gateway was not through the VPN (not even the router).
Thanks too for telling me about the bridge. While configuring it, I was unsure about whether the addresses are linked to the bridge or the ether, and if I should make both the bridge and the ether interfaces members of the list "LAN". I will make your suggested modifications. Personally, I did barely know what an "IP" was two months ago, so it has been a great learning experience.
Finally, regarding encryption algorithms; we have decided to not use WireGuard's 'chacha20poly1305' for now. We might test it later on, keeping your valuable considerations in mind. I will disable 'use-encryption' option too, which I set up following a Youtube video-guide. Thanks for the heads-up!
Next to-do: shaving off the ICMP block and setting up firewall and bridge (somewhat) properly
Once again @sindy thanks for your advice; we should've started with the sniffing tool way earlier. We discovered the issue while performing 'tracepath' from the remote device to a local device. We saw that the gateway was not through the VPN (not even the router).
Thanks too for telling me about the bridge. While configuring it, I was unsure about whether the addresses are linked to the bridge or the ether, and if I should make both the bridge and the ether interfaces members of the list "LAN". I will make your suggested modifications. Personally, I did barely know what an "IP" was two months ago, so it has been a great learning experience.
Finally, regarding encryption algorithms; we have decided to not use WireGuard's 'chacha20poly1305' for now. We might test it later on, keeping your valuable considerations in mind. I will disable 'use-encryption' option too, which I set up following a Youtube video-guide. Thanks for the heads-up!
Next to-do: shaving off the ICMP block and setting up firewall and bridge (somewhat) properly