Community discussions

MikroTik App
 
sindy
Forum Guru
Forum Guru
Topic Author
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Thu Apr 05, 2018 11:54 pm

WARNING! Risk of brain overheat. Prepare some coolware before reading.

The well-known problem

L2TP/IPsec clients reaching the server via NAT do work but only one at a time per each public address. A new client connection from behind the same public address ruins the pre-existing client session.

The root cause

To understand what is wrong, one must stop looking at L2TP/IPsec as at a magic blackbox and closely inspect its strictly layered structure. L2TP/IPsec is literally L2TP transported using IPsec, both protocol-wise and (at least in case of RouterOS) application-wise: when you tick the "use IPsec" check-box in L2TP settings, RouterOS automatically creates an IPSec peer and, at client side, an appropriate policy necessary to transport the L2TP connection. The same IPsec setup can be done manually instead of ticking the check-box in the L2TP configuration, and the resulting processing of the packets is exactly the same in both cases.

According to the standard, L2TP is transported using UDP and both the server and the client use port 1701 to both send and receive. So all standards adherent client implementations use port 1701 also locally.

The L2TP/IPsec standard requires that ESP transport mode is used. ESP transport mode is designed for efficient encapsulation of encrypted traffic directly between two machines, so it does not carry any information about source and destination IP address in the encapsulated payload as it would be redundant. It is assumed that these addresses are the same for the original transported packet and the ESP transport packet. If one of the addresses eventually changes on the way from the sender to the recipient, the decrypted and de-encapsulated packet inherits this changed address. The information about ports is part of the transported payload; ESP itself has no notion of ports at all.

The fact that ESP uses no ports means that it cannot be handled by a NAT; to work this around, the NAT-T extension to IPsec has introduced encapsulation of ESP into UDP. However, this only allows the UDP-encapsulated ESP to be forwarded through the NAT properly. In the process of de-encapsulation of the ESP payload from the UDP transport, the information about source port of the UDP (which has been changed by the NAT to distinguish one flow from another) is lost. The source address of the ESP packet is inherited from the UDP packet in which the ESP has come encapsulated.

When, in the next step, the UDP packet carrying the L2TP is decrypted and de-encapsulated from the ESP, its source address is inherited from the ESP, so it is again the public IP of the NAT, and the source port is the one from which the client has sent the UDP before encapsulating it into the ESP. So if both clients behind the same NAT send from the same port (1701), the L2TP server sees both as coming from the same socket address, consisting of the public address of the NAT and the same port provided by each client. Thus not only that the flows are indistinguishable from each other when received but there is also no way to address the response packets selectively to one of them - the IPsec policy matches only on address and port, not on anything in the payload.

Some client implementations are aware of this and use random ports. RouterOS server implementation is not strict in this and accepts connections from such clients, so this is a solution of the problem for these implementations but not for other ones, like the one of Microsoft Windows. And it is also not a solution for the Android embedded client which uses a random port for L2TP but doesn't restrict its IPsec policy to this port.

The solution at server side RouterOS

As there is no out-of-the-box way to link the source port of the "inner" UDP (the one which carries the L2TP) to the source port of the "outer" UDP packet (the one which carries the ESP), we need to convey the information distinguishing the two client's flows from one another across two encapsulating layers using some other means. Without coding, the only way is to change the transport packets' source IP addresses to unique ones depending on their source ports. So what we need is to use source-NAT on received packets. Problem solved - from the point of view of the L2TP server and IPsec policy matching, there is no ambiquity or conflict as each flow is coming from a unique IP address.

Implementation Details

The above sounds easy but the first cooldown comes when you realize that src-nat does not work for received packets as it is deemed useless for any sane application scenario. We could use two routers in a chain to do that but that would mean extra hardware costs and also some inconvenience. So the first task is to make RouterOS src-nat a received packet and then continue handling it as a received one. The solution is to take any two local addresses and establish an IP-IP tunnel between them, so that we could run the same packet through the whole firewall machinery twice on a single machine. We receive the packet from a physical interface, route it "out" using one of the IP-IP tunnel's ends as the output interface, and we "receive" it the second time from the other end of that tunnel.

Another task is the assignment of a unique source address depending on port. While we could theoretically map the port number 1:1 into the lower two bytes of the IP address, the issue here is that very often flows from two clients behind different NAT boxes come from the same port (like 1024), so that method would not be 100% safe. So this is not the way even if we neglect some other associated complications. The solution is to use a stack of addresses and give each new connection its own address regardless the actual source address and port.

The address assignment policy of src-nat action of RouterOS firewall is not helpful here, as it does not prefer diversity, so if two connections come from different ports on the same IP address, the src-nat rule is likely to assign them the same address no matter how large pool it has got as to-address. A per-connection-classifier can use a hash of source address and port but even with an annoying amount of rules the uniqueness of address assignment would not be guaranteed. The solution is to use a single address in the src-nat rule and increment it each time it gets assigned to a new connection. As using the available means it is impossible to do this fast enough, there is a big chance that two connections get src-nat'ed to the same source address, so we need to resolve that systematically. To do so, the firewall filter in the second pass checks a src-address-list for the first packet of each new connection; if the source address is already there, the firewall drops the packet, thus preventing the connection from establishing, otherwise it adds the source to the address list with a 1 minute lifetime and accepts the packet. So the first connection with a particular source address always succeeds and all the following ones always fail. Once per a couple of seconds, a cleaner script checks whether the source address currently configured in the src-nat rule is used by a properly established connection; if it is, the script updates the rule with an unused address and cleans any connection attempts waiting for a response because their establishing packets have been dropped by the second pass through the firewall, which makes the firewall treat a retransmission of the same packet as a brand new one and thus use the src-nat rule on it. The client retransmits the IPsec connection establishing packet for tens of seconds before it gives up, therefore many clients would have to attempt to connect during the same time window of several seconds so that the most unlucky ones would fail. This can happen e.g. after a network outage if the clients are autonomous devices which keep on trying, so effectively for some of them the network outage will seem to last longer than for others.

It is also worth noting that we need to prevent the incoming UDP transport packets from being delivered to the IPsec stack already in the first pass; to do that, we must dst-nat them to an address which is not a local one to the router using a dst-nat rule which matches in the first pass, and dst-nat them back to the original address using a dst-nat rule which matches in the second pass. Routes must be added to send the internal traffic through the tunnel.

What makes all this even possible is that it is enough to give this special treatment to packets coming to UDP port 4500. The NAT-T mechanism of IPsec does not require that the UDP-encapsulated communication coming to port 4500 would come from the same IP address from which the initial IKE communication was coming to port 500. There would be no way to pair connections to port 500 with connections to port 4500 coming from the same client.

The limitations

The pool of IP addresses used for src-nat must be significantly larger than the maximum expected number of clients connected simultaneously, because if an established connection breaks, the connection tracker remembers it for minutes so its src-nat address cannot be reused during that time. So if some of the clients have unstable connections and reconnect quite frequently, they would exhaust the pool. If your network is so large and complex that you cannot find a free pool of thousands of addresses, the way out is to mark the response IPsec packets from the server and policy-route them back to the tunnel, while the traffic to actual owners of these addresses is routed normally.

The risks

Each modification of the src-nat rule causes a configuration save. This means an extra wear for the flash chip. I have no idea what this may cause in real life deployment on Routerboards. To reduce the impact and also to save some resources, I recommend to exclude packets with source port 4500 from the special treatment. The background is such that NATs usually only change the source port if the original one is already used for another connection to the same remote socket. So in many cases the connection from our first client behind each NAT comes from port 4500 and thus does not cause a modification of the src-nat rule, and in many of these cases the client will be the only one behind that NAT.

The configuration
# Create a bridge without any member ports so that we'd have something to attach the additional local IP address to.
# Actually the address could be added to an existing interface, but a member-less bridge never fails.
/interface bridge
add name=aux-lo protocol-mode=none

# Add another local address - just to have this part independent from the rest of the configuration.
/ip address
add address=127.0.1.1 interface=aux-lo network=127.0.1.1

# Add a firewall rule permitting local traffic - currently, default firewall rules drop traffic from in-interface-list=!LAN which
# includes local traffic
/ip firewall filter
add chain=input src-address=127.0.0.0/8 dst-address=127.0.0.0/8 action=accept place-before=right after the "accept established,related" rule

# Create the two ends of the local tunnel
/interface ipip
add local-address=127.0.0.1 mtu=1500 name=ipip-inner remote-address=127.0.1.1
add local-address=127.0.1.1 mtu=1500 name=ipip-outer remote-address=127.0.0.1

# Add routes for the addresses used for the solution
/ip route
add distance=1 dst-address=10.0.0.0/20 gateway=ipip-inner
add distance=1 dst-address=10.0.15.254/32 gateway=ipip-outer

# Add the chain of firewall rules preventing newer connections from killing an older one before the cleaner script changes the src-nat address
/ip firewall filter
add chain=udp-4500-in src-address-list=src-addresses-in-use action=drop
add chain=udp-4500-in action=add-src-to-address-list address-list=src-addresses-in-use address-list-timeout=1m
add chain=udp-4500-in action=accept

# Add the firewall rule sending new packets to UDP 4500 coming from the tunnel to the chain above
/ip firewall filter
add action=jump chain=input connection-state=new dst-port=4500 in-interface=ipip-inner jump-target=udp-4500-in protocol=udp place-before=right after the "accept established,related" rule

# The usual IPsec- and L2TP-related firewall rules must be there as well, usually they already exist
add action=accept chain=input connection-state=new dst-port=500,4500 protocol=udp
add action=accept chain=input connection-state=new dst-port=1701 ipsec-policy=in,ipsec protocol=udp

# Add the firewall rule permitting forwarding of dst-nated packets in the first pass
/ip firewall filter
add action=accept chain=forward connection-state=new dst-address=10.0.15.254

# Add the NAT rules
/ip firewall nat
# Restore our public IP address on packets after they've passed through the tunnel
add action=dst-nat chain=dstnat dst-address=10.0.15.254 in-interface=ipip-inner to-addresses=1.2.3.4
# src-nat the packets before sending them to the tunnel
add action=src-nat chain=srcnat out-interface=ipip-outer protocol=udp to-addresses=10.0.0.1
# Redirect packets to port 4500 to the auxiliary destination address to give them the special treatment;
# for testing that it works with only two client devices, remove the "src-port=!4500"
add action=dst-nat chain=dstnat dst-port=4500 src-port=!4500 dst-address=1.2.3.4 protocol=udp to-addresses=10.0.15.254

# Add the cleaner script
/system script
add name=l2tp-helper owner=admin policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon source=\
":local cntr 0; \\\
    \n:local auxip [/ip firewall nat get [find chain=\"srcnat\" && out-interface=\"ipip-outer\"] to-addresses]; \\\
    \n:while ([/ip firewall connection print count-only where src-address~\"^\$auxip\" && dst-address~\":4500\" && seen-reply]=1) \
    do={\
    \n  :set auxip (\$auxip+1); \\\
    \n  :if (\$auxip>10.0.15.253) do={:set auxip 10.0.0.1};:set cntr (\$cntr+1)\
    \n}\
    \n:if (\$cntr>0) do={\
    \n  /ip firewall nat set [find chain=\"srcnat\" && out-interface=\"ipip-outer\"] to-addresses=\"\$auxip\"; \\\
    \n  /ip firewall connection remove [find dst-address~\":4500\" && !seen-reply]\
    \n}\
    \n"

# Schedule the cleaner script to run every 3 seconds right from the restart
/system scheduler
add interval=3s name=l2tp-scheduler on-event=l2tp-helper policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon \
    start-time=startup

Last edited by sindy on Sat May 08, 2021 10:06 pm, edited 4 times in total.
 
User avatar
pcunite
Forum Guru
Forum Guru
Posts: 1345
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: Multiple L2TP/IPsec clients behind NAT - solved

Fri Apr 06, 2018 3:30 am

Wow ... I've had issues with this on Peplink devices.

I think MikroTik should someone bake your solution into the firmware somehow.
 
drakerex
just joined
Posts: 1
Joined: Sat May 05, 2018 2:22 am

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Sat May 05, 2018 2:28 am

@sindy - In the following is the 10.0.0.0/20 for inner considered what you're using as your LAN? ie, the same as 192.168.2.0/24 (as example).

Also - Is the 10.0.15.254/32 the same as a WAN IP or is this an internal binding for the loop creation on the bridge only? Or is that considered the end client's IP range given the /32? If so on the latter, if we're using a DHCP pool for our external vpns, how would we bind that part dynamically?

add distance=1 dst-address=10.0.0.0/20 gateway=ipip-inner
add distance=1 dst-address=10.0.15.254/32 gateway=ipip-outer
 
sindy
Forum Guru
Forum Guru
Topic Author
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Wed May 16, 2018 4:12 pm

@sindy - In the following is the 10.0.0.0/20 for inner considered what you're using as your LAN? ie, the same as 192.168.2.0/24 (as example).

Also - Is the 10.0.15.254/32 the same as a WAN IP or is this an internal binding for the loop creation on the bridge only? Or is that considered the end client's IP range given the /32? If so on the latter, if we're using a DHCP pool for our external vpns, how would we bind that part dynamically?

add distance=1 dst-address=10.0.0.0/20 gateway=ipip-inner
add distance=1 dst-address=10.0.15.254/32 gateway=ipip-outer
Sorry for late answer, I haven't received a notification e-mail.
Yes, 10.0.15.254 is just the last individual address from 10.0.0.0/20. The whole range you choose instead of the 10.0.0.0/20 in the example must not collide with any private range you use, including the pools you use to assign addresses to the L2TP clients. There is no relationship between the pool from which you assign addresses to L2TP clients and this range (except that they must not collide). These addresses are not assigned to any interface anywhere.
 
voll
just joined
Posts: 9
Joined: Mon Sep 03, 2018 5:04 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Mon Sep 03, 2018 5:39 pm

Hi Sindy!

I've been trying to implement your solution for a couple of days now, but with minimal progress unfortunately and am hoping for some help at this point...

On first glance, your tutorial screams complex (took me a good couple of hours to disseminate everything lol).

My setup involves a CHR v 6.42.7 acting as the L2TP/IPsec server and two windows 10 clients dialling from behind the same public IP. As expected, the last dialled client will "keep alive", while the first will hang around for anything between 1-15mins before disconnecting. Pinging the router while both are connected renders an alternate response (5-10s worth of responses for one client, then it times out and the other one begins to receive them - to be expected I guess).

My Jump rule (and consequently the udp-4500-in chain) is not being hit at all, no matter where I position it in the firewall and am beginning to suspect an IP config problem somewhere. Also, I have no local ranges conflicting with your proposed config values.

Would it be too much to ask for a server-side config sample for reference?

Much appreciated!
 
sindy
Forum Guru
Forum Guru
Topic Author
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Mon Sep 03, 2018 8:24 pm

Both the lab device on which I've developed the configuration and the sole machine on which I'm currently running it in production have much more complex firewall rules and many unrelated settings. Therefore, both would have to be edited before posting, so there is a risk of losing some important bit during this process. On the other hand, the configuration already posted in the OP has been cut to bare bone of what is necessary for it to run.

So I propose you the reverse, export your config following the instruction in my automatic signature (and take special care about the "systematical" part while obfuscating) and I'll have a look. This will also allow me to identify the missing or misleading part of the description above.
 
voll
just joined
Posts: 9
Joined: Mon Sep 03, 2018 5:04 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Tue Sep 04, 2018 10:58 am

Thanks for your swift reply & totally understand.

Here is my export:
---------------------------------------------------------------------
# sep/03/2018 15:31:25 by RouterOS 6.42.7
#
#
#
/interface bridge
add name=aux-lo protocol-mode=none
/interface ethernet
set [ find default-name=ether1 ] name=mgmt-106
set [ find default-name=ether1 ] name=technative-LAN-2002
set [ find default-name=ether1 ] name=wan-704
/interface ipip
add local-address=127.0.0.1 mtu=1500 name=ipip-inner remote-address=127.0.1.1
add local-address=127.0.1.1 mtu=1500 name=ipip-outer remote-address=127.0.0.1
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip pool
add name=VPN-pool ranges=10.200.31.20-10.200.31.120
add name=DHCP-pool ranges=10.200.30.121-10.200.30.200
/ip dhcp-server
add address-pool=DHCP-pool disabled=no interface=technative-LAN-2002 name=\
    dhcp-technative
/ppp profile
add dns-server=10.200.30.254 local-address=10.200.31.254 name=l2tp-in \
    remote-address=VPN-pool
/interface l2tp-server server
set authentication=mschap2 default-profile=l2tp-in enabled=yes ipsec-secret=\
    [Secret] use-ipsec=yes
/ip address
add address=127.0.1.1 interface=aux-lo network=127.0.1.1
add address=10.200.30.254/24 interface=technative-LAN-2002 network=\
    10.200.30.0
add address=[public_IP]/27 interface=wan-704 network=[public_network]
/ip dhcp-client
add add-default-route=no disabled=no interface=mgmt-106
/ip dhcp-server network
add address=10.200.30.0/24 dns-server=10.200.30.254 gateway=10.200.30.254
/ip dns
set allow-remote-requests=yes
/ip firewall address-list
add address=10.222.203.0/24 list=bliss-mgmt
add address=10.220.220.0/24 list=bliss-mgmt
add address=10.200.30.0/24 list=internal-LAN
add address=10.200.31.0/24 list=internal-LAN
/ip firewall filter
add action=accept chain=input comment="Accept mgmt-in" src-address-list=\
    bliss-mgmt
add action=accept chain=input disabled=yes src-address-list=internal-LAN
add action=accept chain=input comment="Allows Ping" protocol=icmp
add action=drop chain=udp-4500-in comment=\
    "Prevent new VPN-conn to kill old one" src-address-list=\
    src-addresses-in-use
add action=add-src-to-address-list address-list=src-addresses-in-use \
    address-list-timeout=1m chain=udp-4500-in
add action=accept chain=udp-4500-in
add action=accept chain=input comment="Allow E&R In" connection-state=\
    established,related
add action=jump chain=input connection-state=new dst-port=4500 in-interface=\
    ipip-inner jump-target=udp-4500-in protocol=udp
add action=accept chain=input comment="Allow local loop" dst-address=\
    127.0.0.0/8 log-prefix=local127 src-address=127.0.0.0/8
add action=accept chain=input comment="Allow VPN protocols" connection-state=\
    new dst-port=500 protocol=udp
add action=accept chain=input protocol=ipsec-esp
add action=accept chain=input connection-state=new dst-port=1701 \
    ipsec-policy=in,ipsec protocol=udp
add action=accept chain=input connection-state=new dst-port=4500 protocol=udp
add action=accept chain=input in-interface=technative-LAN-2002
add action=drop chain=input comment="Drop all other" in-interface=wan-704 \
    log-prefix="drop pool"
add action=accept chain=forward comment=\
    "Allow forwarding of dst-nated packets in the first pass" \
    connection-state=new dst-address=10.0.15.254
add action=accept chain=forward comment="Allow E&R Fw" connection-state=\
    established,related
add action=accept chain=forward comment="Allow Internal FW" dst-address-list=\
    internal-LAN src-address-list=internal-LAN
add action=drop chain=forward comment="Drop all other" connection-state=\
    invalid
/ip firewall nat
add action=dst-nat chain=dstnat comment="Restore our public IP address on pack\
    ets after they've passed through the tunnel" dst-address=10.0.15.254 \
    in-interface=ipip-inner to-addresses=1.2.3.4
add action=src-nat chain=srcnat comment=\
    "src-nat the packets before sending them to the tunnel" out-interface=\
    ipip-outer protocol=udp to-addresses=10.0.0.1
add action=dst-nat chain=dstnat comment="Redirect packets to port 4500 to the \
    auxiliary destination address to give them the special treatment" \
    dst-address=1.2.3.4 dst-port=4500 protocol=udp src-port=!4500 \
    to-addresses=10.0.15.254
add action=masquerade chain=srcnat comment="Masq everything else" \
    dst-address=!10.0.0.0/8 out-interface=wan-704
/ip ipsec peer
add address=0.0.0.0/0 dh-group=modp1024 enc-algorithm=aes-256,aes-128,3des \
    exchange-mode=main-l2tp generate-policy=port-override secret=[Secret]
/ip route
add distance=2 gateway=[next_hop]
add distance=1 dst-address=10.0.0.0/20 gateway=ipip-inner
add distance=1 dst-address=10.0.15.254/32 gateway=ipip-outer
add distance=1 dst-address=10.220.220.0/24 gateway=10.223.203.254
/ppp aaa
set use-radius=yes
/ppp secret
add name=[test_acc1] password=[pass] profile=l2tp-in service=l2tp
add name=[test_acc2] password=[pass] profile=l2tp-in service=l2tp
/radius
add address=10.200.30.251 secret=[radius_secret] service=ppp src-address=\
    10.200.30.254
/system clock
set time-zone-name=Europe/London
/system identity
set name=Technative-vr2
/system logging
add disabled=yes prefix=VPNLog topics=ipsec
/system scheduler
add interval=3s name=l2tp-scheduler on-event=l2tp-helper policy=\
    ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon \
    start-time=startup
/system script
add name=l2tp-helper owner=dionita policy=\
    ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon source="\
    \":local cntr 0; \\\\\\\r\
    \n    \\n:local auxip [/ip firewall nat get [find chain=\\\"srcnat\\\" && \
    out-interface=\\\"ipip-outer\\\"] to-addresses]; \\\\\\\r\
    \n    \\n:while ([/ip firewall connection print count-only where src-addre\
    ss~\\\"^\\\$auxip\\\" && dst-address~\\\":4500\\\" && seen-reply]=1) \\\r\
    \n    do={\\\r\
    \n    \\n  :set auxip (\\\$auxip+1); \\\\\\\r\
    \n    \\n  :if (\\\$auxip>10.0.15.253) do={:set auxip 10.0.0.1};:set cntr \
    (\\\$cntr+1)\\\r\
    \n    \\n}\\\r\
    \n    \\n:if (\\\$cntr>0) do={\\\r\
    \n    \\n  /ip firewall nat set [find chain=\\\"srcnat\\\" && out-interfac\
    e=\\\"ipip-outer\\\"] to-addresses=\\\"\\\$auxip\\\"; \\\\\\\r\
    \n    \\n  /ip firewall connection remove [find dst-address~\\\":4500\\\" \
    && !seen-reply]\\\r\
    \n    \\n}\\\r\
    \n    \\n\""

----------------------------------------------------------------------------------------------------
As you can see, besides a radius instance and some mgmt rules, the setup is pretty much bare. The CHR is VLAN agnostic so the IDs are set per interface outside the VM. Must be something small that I'm missing :)

Really appreciate taking the time to examine this!
 
sindy
Forum Guru
Forum Guru
Topic Author
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Tue Sep 04, 2018 12:01 pm

Could it be as simple as that you haven't realized that you have to replace 1.2.3.4 in my chain=dstnat rules by your actual public IP address?

Other than that, you have configured an IPsec peer with exchange-mode=main-l2tp manually, and you have also configured use-ipsec=yes and secret on /interface l2tp-server server. It works but you end up with two peers running and only one of them actually used.
 
voll
just joined
Posts: 9
Joined: Mon Sep 03, 2018 5:04 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Tue Sep 04, 2018 1:18 pm

Yes, those did slip through. Thanks for pointing that out!
I've changed the L2TP Server settings to "Use IPsec=no" and left only one IPsec Peer on. Also, did the public IP swap in the NAT dst rules.

Now I'm getting some hits on rules which defo counts as progress... The drop rule meant to prevent killing the old connection as well as the 127 loop are never hit thou :(. Secondary connections do drop randomly within minutes and any effort to communicate simultaneously from test1 / test2 (while established) fails. Sometimes, the disconnection occurs immediately after attempting to actively send packets through a connection (pinging for example).

Noticed that, upon dialling, the generated IPsec policies differ:

1st established connection generates a policy with src-addr=router_public_Ip and dst-addr=10.0.0.1
2nd established connection generates a policy with src-addr=router_public_Ip and dst-addr=remote_public_ip

Would that be normal?
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7038
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Tue Sep 04, 2018 3:04 pm

Does this overcomplicated thing really necessary, where you can switch to ike2 and forget about NAT problems?
 
voll
just joined
Posts: 9
Joined: Mon Sep 03, 2018 5:04 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Tue Sep 04, 2018 3:45 pm

I'm new to IKE1/2 really.. So, let me get this straight: Implementing a cert-based VPN would assign uniqueness to two or more clients dialling behind same NAT device?
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Tue Sep 04, 2018 3:59 pm

Does this overcomplicated thing really necessary, where you can switch to ike2 and forget about NAT problems?
IKE2 does require a PKI infrastructure, doesn't it? That is overcomplicated just as well... it introduces the new
problem of certificate generation, installation, backup and renewal. Using a PSK is so much simpler.
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7038
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Tue Sep 04, 2018 4:00 pm

Not really, can be done with EAP authentication.
And if clients are only ROS devices or IOS you can use PSK as well.
 
sindy
Forum Guru
Forum Guru
Topic Author
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Tue Sep 04, 2018 4:33 pm

Not really, can be done with EAP authentication.
...and User Manager isn't sufficient for this (unless I've missed something during past half a year) so you need an external RADIUS server.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Tue Sep 04, 2018 4:50 pm

Not really, can be done with EAP authentication.
And if clients are only ROS devices or IOS you can use PSK as well.
I decided to experiment a little with this.
It appears to be possible to have a IKE2 IPsec peer alongside a main peer at the server side (where I do not use the auto-generated peer config), good.
However, at the client side I would like to use auto-generated peer but it is not possible to specify IKE2 anywhere.
WIth manually configured peer it is working. However, my L2TP client has a DNS name that resolves to 2 different IP addresses (2 different ISP at the main office)
so auto-generated peer is more convenient as it generates the correct peer for the actual remote IP in use for the connection.
 
sindy
Forum Guru
Forum Guru
Topic Author
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Tue Sep 04, 2018 5:13 pm

I decided to experiment a little with this.
It appears to be possible to have a IKE2 IPsec peer alongside a main peer at the server side (where I do not use the auto-generated peer config), good.
However, at the client side I would like to use auto-generated peer but it is not possible to specify IKE2 anywhere.
WIth manually configured peer it is working. However, my L2TP client has a DNS name that resolves to 2 different IP addresses (2 different ISP at the main office)
so auto-generated peer is more convenient as it generates the correct peer for the actual remote IP in use for the connection.
I'm a bit lost - what has an auto-generated peer to do with IKE2 mode? If you use an IKE2-controlled SA to transport L2TP, you fall to the same rabbit hole like with IKE1-controlled SA regarding NAT and transport mode; if you use plain IKE2 mode, which is what @mrz suggests, I cannot see how the client-side peer could be a dynamic one.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Tue Sep 04, 2018 5:17 pm

I'm a bit lost - what has an auto-generated peer to do with IKE2 mode? If you use an IKE2-controlled SA to transport L2TP, you fall to the same rabbit hole like with IKE1-controlled SA regarding NAT and transport mode; if you use plain IKE2 mode, which is what @mrz suggests, I cannot see how the client-side peer could be a dynamic one.
I did not know that, I understood I only needed to change main exchange mode into IKE2 exchange mode at both ends.
However, that is not possible with auto-generated peer (setting IPsec checkmark and entering PSK).
How do you configure an L2TP client with "plain IKE2 mode"?
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7038
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Tue Sep 04, 2018 5:23 pm

You don't there is no need for L2TP when ike2 is used.
 
sindy
Forum Guru
Forum Guru
Topic Author
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Tue Sep 04, 2018 5:24 pm

@voll, sorry, I need to concentrate on analysing your behaviour which is currently impossible due to other factors so we'll come back to it later :-)

@pe1chl, as you've anticipated you cannot, you need to configure the peer manually. The auto-generated peer always uses main-l2tp, and the auto-generated peers for ipip, gre, eoip... tunnels always use main. If you want anything special (non-default exchange modes, non-default proposals used to auto-generate policies), you have to configure the peer manually.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Tue Sep 04, 2018 6:02 pm

You don't there is no need for L2TP when ike2 is used.
Then what kind of tunnel do you use? I don't want to use plain IPsec because I want to route traffic between several subnets, not only a single endpoint address.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Tue Sep 04, 2018 6:04 pm

If you want anything special (non-default exchange modes, non-default proposals used to auto-generate policies), you have to configure the peer manually.
But unfortunately you cannot use manual peer config with multiple peer addresses (which works OK with auto-generated policies)
 
sindy
Forum Guru
Forum Guru
Topic Author
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Tue Sep 04, 2018 6:15 pm

Don't mix auto-generated (dynamic) policies with auto-generated (dynamic) peers. With mode-config, the policy is dynamically generated at both peers ("client" and "server"), always using the locally visible (public) IP address of the remote peer as sa-dst-address.

But yes, plain IKE2 uses policies to choose packets to be tunnelled, which you are famous for not being a fan of :-)
 
voll
just joined
Posts: 9
Joined: Mon Sep 03, 2018 5:04 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Tue Sep 04, 2018 7:02 pm

@voll, sorry, I need to concentrate on analysing your behaviour which is currently impossible due to other factors so we'll come back to it later :-)
No worries Sindy

I've temporarily set in place a softether.org server instance which seems to work flawlessly with multiple clients dialling side-by-side behind same wan ip.

Would be nice to have a pure mikrotik solution to it, but I can also appreciate Mikrotik not focusing on L2TP/IPsec that much as it becomes deprecated in favour of IKE.

Will pursue this thread with same interest as your solution does look intriguing in its own right :)
 
sindy
Forum Guru
Forum Guru
Topic Author
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Wed Sep 05, 2018 1:59 am

Noticed that, upon dialling, the generated IPsec policies differ:

1st established connection generates a policy with src-addr=router_public_Ip and dst-addr=10.0.0.1
2nd established connection generates a policy with src-addr=router_public_Ip and dst-addr=remote_public_ip

Would that be normal?
This is normal because you've kept the src-port=!4500 in the dst-nat rule. This causes the first connection established through the client-side NAT to bypass the whole thing. The sole purpose of this is to reduce flash wear as the whole "overcomplicated thing" is necessary only if multiple clients are behind the same NAT. The fact that you can see it as 2nd in the list is not important, the list is not ordered by connection establishment time. And it also explains why the rules preventing one connection from affecting the next one do not count, as there is no conflict. The second connection through the NAT comes from a source port like 1024, and the locally assigned source address (10.0.0.1) is added to the address-list, but as no further connection comes in before the scheduled script changes the to-addresses value in the action=src-nat rule, the collision-preventing rule (drop new connections if coming from an IP currently on address-list) has no reason to kick in.

Secondary connections do drop randomly within minutes and any effort to communicate simultaneously from test1 / test2 (while established) fails. Sometimes, the disconnection occurs immediately after attempting to actively send packets through a connection (pinging for example).
No idea here, it sounds to me as unrelated to the NAT-beating setup.

Can you show me the output of /ip firewall connection print where dst-address~":4500" (substitute the public IPs of course) while both connections are up (logged in)?

Can you add a 3rd device and show the same output?
 
dhcpy
just joined
Posts: 12
Joined: Tue Oct 19, 2010 6:38 am

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Fri Dec 21, 2018 4:31 pm

Good day,
Great analysis and superb workaround!!

I had the same problem, came here googling. Now I know this is out of my league though so will find other solution.
Seems this is not a mikrotik issue, but a protocols and features limitation.
Would be nice though, to have the wiki updated on this things, giving that (to my knowledge) is the official mikrotik documentation, they should put a little effort in the guidance of this kind of common scenarios (roadwarriors behind NAT)..And if opting for betters solutions, as IKE is the trend, well then put that statement somewhere with emphasis.
I would have saved time not reading on solutions that require god level tweaking.
thanks again sindy!
 
sindy
Forum Guru
Forum Guru
Topic Author
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Fri Dec 21, 2018 6:52 pm

Now I know this is out of my league though so will find other solution.
It is actually not so complex once you draw it. The only complex thing in it is that you have to squeeze the functionality normally provided by two routers into just one.

Seems this is not a mikrotik issue, but a protocols and features limitation.
Correct.

as IKE is the trend
A standalone IKEv2 (i. e. without the L2TP on top of it) is the trend, not IKE(v1) which is outdated, and the way it is used in the operating systems' native clients, IKEv2 has the advantage of leaving out one layer of tunneling so the confusion intirinsic to L2TP/IPsec doesn't exist: also here, packets from each of the clients behind a common public IP arrive from a different UDP port, but unlike in the L2TP/IPsec case, the information about that client-representing port is not lost.

What scares many people is the need to handle certificates induced by the fact that all OS-provided IKEv2 clients seem to insist on their use although a pre-shared key is also supported by IKEv2 as a protocol suite. If all you want is to connect the device to a single VPN "server", handling of certificates is actually not terribly complex. As soon as you need the same device to connect to several servers, it may be more tricky: I haven't seen any support of multiple own identities on e.g. Windows or Android, so I'm afraid the embedded client would use the same certificate to authenticate itself to all servers, and this causes a headache if the certificate is not signed by any public certification autority because all servers would have to accept certificates signed by the private CA used. Which constitutes a security hole from the point of view of the server administrator.

But unless one of the certificate-related points as mentioned above is an issue for you, IKEv2 is an easy substitution of L2TP/IPsec which doesn't suffer from the "multiple clients behind same public IP" trouble.
 
billybons2006
just joined
Posts: 21
Joined: Fri Jun 27, 2014 11:43 am

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Fri Jan 11, 2019 12:43 pm

Thank you for information, explanation and example. I tested this, it works with iPhone and Windows and, really, Android can't connect to the server :(
 
sindy
Forum Guru
Forum Guru
Topic Author
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Fri Jan 11, 2019 3:14 pm

I would suspect the Android connection issue to be related either to permitted encryption algorithms in peer profile and/or policy, or to some particular Android version. My variouos Android devices work well with this (except that after the initially suggested session time expires, they pretend to be connected but actually transport no data, but that's again unrelated to the multiple-clients-behind-same-NAT issue).

So as the first step, I'd disconnect all clients if possible, enable IPsec logging (/system logging add topics="ipsec,!packet"), run /log print follow-only where topics~"ipsec" file=ipsec-start, make an attempt to connect the Android, stop the log print once the Android reports failure, download the file and study it for encryption and authentication algorithm match between the devices.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Fri Jan 11, 2019 5:37 pm

Indeed you must set
/ip ipsec peer profile
enc-algorithm=aes-128,3des hash-algorithm=sha1

When you set other enc-algorithm like aes-256 or other hash algoritthm it will just fail on some Android versions.
For /ip ipsec proposal (phase 2 settings) you can have aes-256 enabled when you really think that the secret service is after you.
 
oreggin
Member Candidate
Member Candidate
Posts: 172
Joined: Fri Oct 16, 2009 9:21 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Fri May 17, 2019 9:10 pm

Hi!
I build a hub and spokes IKEv2/rsa signature auth with L2TP over IPSec setup with Tik deivces.
There is one central HUB with static public address, and there are some spokes, one of them have a dynamic public address, and the other is behind NAT where NAT public address is dynamic as well.
Public addressed CPE is connect to the HUB Tik router without any problem, but the CPE behind NAT can't connect. I think because dynamic policy derived from template is always gets transport mode and I need tunnel mode. So IKEv2 not solve my problem :(
I using RoS v6.44.3 all of the devices.
Sorry if someone asked the same before, but is there a way to create a template which creating tunnel mode dynamic policies? Or it is impossible?
cheers,
oreggin
 
sindy
Forum Guru
Forum Guru
Topic Author
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Fri May 17, 2019 9:21 pm

A policy generated from a template always accommodates to the tunnel or transport mode requested by the remote peer.

Independent from this, I didn't have in mind to use IKEv2 to transport L2TP instead of IKE(v1) but to use directly IKEv2, i.e. without the L2TP inside.
 
oreggin
Member Candidate
Member Candidate
Posts: 172
Joined: Fri Oct 16, 2009 9:21 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Mon May 20, 2019 12:52 pm

How can I request tunnel mode, if both side has dynamic policies? I can't find this option in RoS :(
I using BGP inside L2TP to distribute (IPv4+IPv6) routes between hubs and spoke, so i think i can't drop L2TP, or can I? How?
Oh, and I missed the MPLS part inside the L2TP.
 
sindy
Forum Guru
Forum Guru
Topic Author
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Mon May 20, 2019 1:13 pm

How can I request tunnel mode, if both side has dynamic policies? I can't find this option in RoS :(
As you've mentioned IKEv2 and rsa-signature, I cannot see how you can use a dynamically created policy at both ends. Do you have use-ipsec=yes in the /interface l2tp-client settings? And if you do, doesn't the dynamically created IKE(v1) peer collide with the manually created IKEv2 one when it comes to which one of the two will be used to create the SAs used by the policy? I mean, the two pairs of peers (with exchange-mode=main and with exchange-mode=ike2) may run simultaneously, but as IP addresses of the endpoints are the same, I don't dare to guess which of the pairs of control SAs will be used to negotiate the transport SAs for the policy.

I using BGP inside L2TP to distribute (IPv4+IPv6) routes between hubs and spoke, so i think i can't drop L2TP, or can I? How?
Oh, and I missed the MPLS part inside the L2TP.
BGP would not be a problem with GRE or IPIP, but for MPLS you need L2TP or EoIP.

In any case, I think we've got quite far away from the scope of the topic - do you really have multiple spokes visible to the hub from behind a common IP address, and these spokes are road warriors, i.e. they connect from another place each time?
 
oreggin
Member Candidate
Member Candidate
Posts: 172
Joined: Fri Oct 16, 2009 9:21 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Mon May 20, 2019 1:41 pm

Under "/interface l2tp-client" I set "use-ipsec=no" as if I'm right it supports only PSK based auth.
I configured dynamic policies under "/ip ipsec":
/ip ipsec peer set 0 exchange-mode=ike2
/ip ipsec identity set 0 auth-method=rsa-signature generate-policy=port-override
Unfortunately I didn't found better solution.
 
sindy
Forum Guru
Forum Guru
Topic Author
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Mon May 20, 2019 2:36 pm

Wait. Are you saying that by setting generate-policy=port-override at both peers, if one of them wants to send a packet to the other one, a matching transport policy is automatically generated from the template? That doesn't make sense to me... I've always thought that at least one end must have a fixed policy, or use mode-config=request-only to request its local address from the remote peer and generate the local policy from the received mode-config instruction.

 
oreggin
Member Candidate
Member Candidate
Posts: 172
Joined: Fri Oct 16, 2009 9:21 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Mon May 20, 2019 3:11 pm

I didn't mentioned IPSec is the outer and L2TP is inside of it. In the reverse situation the result performance is terrible.
Now I have dynamic policies on both end and it works if peers are not behind NAT.
I'm not an IPSec expert, so do you say I need set static policy on spokes? On spokes because I have only one fix IP and it has the HUB and I must set SA dest address in static policy? How policies generated on hub for each spokes? And how it will works if a spoke is behind NAT?

Thanks!
 
sindy
Forum Guru
Forum Guru
Topic Author
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Mon May 20, 2019 3:47 pm

Now I have dynamic policies on both end and it works if peers are not behind NAT.
OK, I'm afraid I start understanding what's actually going on there.

I'm not an IPSec expert, so do you say I need set static policy on spokes? On spokes because I have only one fix IP and it has the HUB and I must set SA dest address in static policy? How policies generated on hub for each spokes? And how it will works if a spoke is behind NAT?
I don't consider myself an IPsec expert either, just an advanced user. But my understanding is this:
  • to transport the actual data, you need a pair of security associations, which are basically unidirectional encrypted links
  • to choose which data to send via the security association and in which form, you need a policy, which is a combination of
    • the traffic selector - a combination of source and destination IP addresses or subnets and, eventually, protocol, and if protocol is specified and supports the notion of ports, also possibly of source and destination port
    • payload encapsulation mode (transport or tunnel)
    • encryption and authentication algorithms which may be chosen from (the "proposal")
    • the rules to create and use the SA - the address of the remote device which must be one of IPsec peers, the local address to use if it makes a difference, and the sharing mode, i.e. whether an existing SA to the same remote peer can be reused for packets matching other policies' traffic selectors
  • to control the establishment of the SAs needed to serve the policies, a "control" SA between the peers needs to be established first.
A "data" SA may be created only as late as when a packet matching policy's traffic selector appears, or in advance. But if the packet to be transmitted doesn't match the traffic selector of any existing policy, it is simply sent in plaintext. No comparison to peer addresses is done.

To accommodate for dynamic environments, you can use policy templates which are then used in one of the following ways:
  • if one peer has a manually configured policy (manually configured from the perspective of the IPsec astro clock), it offers its traffic selector to the other peer, which checks whether a mirror traffic selector fits to one of its policy templates and dynamically creates a policy if it does
  • if mode-config is used, the mode-config requestor (which is normally the initiator) gets the address and route list from the other peer and converts that into policies locally (so it needs to have generate-policy set to something else than no), and then offers the result to the other peer as in the case above
  • specifically for L2TP, EoIP, ... tunnels in Mikrotik, the code handling the tunnel interface creates the policy at client side, so from the perspective of the user it is a dynamically created one but the IPsec treats it as one provided from outside, so it handles it as in the first point

All the above leads me to a conclusion that when you start the hub and the spoke on public address, you'll likely find that no policy's traffic selector actually matches the L2TP transport packets, so they flow between the devices in plaintext. Which also explains why it doesn't work on spokes which are behind NAT.

When the policy is generated from a template, its sa-dst-address and sa-src-address are assigned dynamically to match those used by the "control" SA. This allows to traverse NAT if tunnel mode is used, and to certain extent also if transport mode is used - in particular, the combination of public IP and the port of the remote peer must be unique for each remote peer.

 
oreggin
Member Candidate
Member Candidate
Posts: 172
Joined: Fri Oct 16, 2009 9:21 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Mon May 20, 2019 4:40 pm

Thanks for deep explanations, good to learn something new every day.
BTW your conclusion is not exactly right as our L2TP tunnels are encrypted, I checked it. Dynamic policies generated on HUB and spokes and SA counters increasing with the amount of trasmitted bytes. I don't say that I 100% understand why, but all of it works while all spokes has public IP. And you are right as I must have an additional firewall rule on HUB to drop unencrypted L2TP traffic.
My detailed configs over here:
HUB:
/ip ipsec peer add exchange-mode=ike2 local-address=192.0.2.1 name=Spokes passive=yes send-initial-contact=no
/ip ipsec identity add auth-method=rsa-signature certificate=cert_HUB generate-policy=port-override peer=Spokes
Spoke1:
/ip ipsec peer add address=192.0.2.1/32 exchange-mode=ike2 name=HUB
/ip ipsec identity add auth-method=rsa-signature certificate=cert_Spoke1 generate-policy=port-override peer=HUB remote-certificate=cert_HUB
192.0.2.1 is my HUB's address for the documentation. I know the certs part is not clear for now but working on it ;)

"ip ipsec policy print" on HUB shows every spokes has a policy with "DA" flag and "action=encrypt level=unique ipsec-protocols=esp tunnel=no ph2-count=1"

Do you think my setup would not work or it is bad conception?
 
sindy
Forum Guru
Forum Guru
Topic Author
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Mon May 20, 2019 6:05 pm

I just don't get how these dynamically created policies came into existence out of blue. I'll have to check later how is that possible, but I'd prefer to see the full export and also the output of /ip ipsec policy print (anonymized along with the export as per my hint below to maintain consistence) from the hub and from one spoke on a public address.
 
oreggin
Member Candidate
Member Candidate
Posts: 172
Joined: Fri Oct 16, 2009 9:21 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Mon May 20, 2019 7:14 pm

Here are my anonymised configs and print outputs:
[oreggin@HUB] > ip ipsec export verbose
# may/20/2019 17:52:51 by RouterOS 6.44.3
# software id = XXXX-XXXX
#
# model = XXX
# serial number = XXXXXXXXXXXX
/ip ipsec mode-config
set [ find default=yes ] name=request-only responder=no
/ip ipsec policy group
set [ find default=yes ] name=default
/ip ipsec profile
set [ find default=yes ] dh-group=xxx dpd-interval=xxx dpd-maximum-failures=xxx enc-algorithm=xxx hash-algorithm=xxx lifetime=xxx name=default nat-traversal=yes proposal-check=xxx
/ip ipsec peer
add disabled=no exchange-mode=ike2 local-address=192.0.2.1 name=Spokes passive=yes profile=default send-initial-contact=no
/ip ipsec proposal
set [ find default=yes ] auth-algorithms=xxx disabled=no enc-algorithms=xxx lifetime=xxx name=default pfs-group=xxx
/ip ipsec identity
add auth-method=rsa-signature certificate=cert_HUB disabled=no generate-policy=port-override peer=Spokes
/ip ipsec policy
set 0 disabled=no dst-address=0.0.0.0/0 group=default proposal=default protocol=all src-address=0.0.0.0/0 template=yes
/ip ipsec settings
set xauth-use-radius=no
[oreggin@HUB] > ip ipsec policy print
Flags: T - template, X - disabled, D - dynamic, I - invalid, A - active, * - default 
 0 T * group=default src-address=0.0.0.0/0 dst-address=0.0.0.0/0 protocol=all proposal=default template=yes

 1  DA  src-address=192.0.2.1/32 src-port=any dst-address=198.51.100.1/32 dst-port=any protocol=all action=encrypt level=unique ipsec-protocols=esp tunnel=no proposal=default ph2-count=1
[oreggin@HUB] >
Spoke1:
[oreggin@spoke1] > ip ipsec export
# may/20/2019 17:52:57 by RouterOS 6.44.3
# software id = XXXX-XXXX
#
# model = XXX
# serial number = XXXXXXXXXXXX
/ip ipsec mode-config
set [ find default=yes ] name=request-only responder=no
/ip ipsec policy group
set [ find default=yes ] name=default
/ip ipsec profile
set [ find default=yes ] dh-group=xxx dpd-interval=xxx dpd-maximum-failures=xxx enc-algorithm=xxx hash-algorithm=xxx lifetime=xxx name=default nat-traversal=yes proposal-check=xxx
/ip ipsec peer
add address=192.0.2.1/32 disabled=no exchange-mode=ike2 name=HUB profile=default send-initial-contact=yes
/ip ipsec proposal
set [ find default=yes ] auth-algorithms=xxx disabled=no enc-algorithms=xxx lifetime=xxx name=default pfs-group=xxx
/ip ipsec identity
add auth-method=rsa-signature certificate=cert_Spoke1 disabled=no generate-policy=port-override match-by=certificate peer=HUB remote-certificate=cert_HUB
/ip ipsec policy
set 0 disabled=no dst-address=0.0.0.0/0 group=default proposal=default protocol=all src-address=0.0.0.0/0 template=yes
/ip ipsec settings
set xauth-use-radius=no
[oreggin@spoke1] > ip ipsec policy print
Flags: T - template, X - disabled, D - dynamic, I - invalid, A - active, * - default
 0 T * group=default src-address=0.0.0.0/0 dst-address=0.0.0.0/0 protocol=all proposal=default template=yes

 1  DA  src-address=198.51.100.1/32 src-port=any dst-address=192.0.2.1/32 dst-port=any protocol=all action=encrypt level=unique ipsec-protocols=esp tunnel=no proposal=default ph2-count=1
[oreggin@spoke1] >
I hope you can find out why my setup works.
 
sindy
Forum Guru
Forum Guru
Topic Author
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Mon May 20, 2019 11:48 pm

Thanks for deep explanations, good to learn something new every day.
I cannot agree more :)

I hope you can find out why my setup works.
The answer is that it works because there really is this feature (which may be a brand new one or a repercussion of the past, I don't dare to even guess which one is correct - maybe the IPsec RFC even requires this behaviour) which creates a transport mode policy with protocol=all if those /ip ipsec identity rows at each peer which cause a successful establishment of phase 1 between the peers have generate-policy set to port-strict or port-override and there is no configured and enabled policy on any of the peers whose sa-dst-address would match the address of the remote peer, nor is mode-config=request-only set on any of the /ip ipsec identity rows involved.


So back to your issue - if you need to set up a tunnel encrypted using IPsec, NAT becomes an issue if transport mode is used and several remote peers share the same public IP from the perspective of the local peer. In these cases, you need to use a dirty trick which I have described here on the forum not longer than a month ago, so I may still be able to find that topic rather than describing it once again. It involves a statically configured policy on the spoke side with tunnel mode encapsulation, and also some NAT rules.

 
oreggin
Member Candidate
Member Candidate
Posts: 172
Joined: Fri Oct 16, 2009 9:21 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Tue May 21, 2019 11:43 am

We have only one spoke behind every branch's ISP modem which are the NAT GWs, but spokes behind NAT with this configuration does not work.
There is no need any trick to supports more spoke behind the same NAT GW.
We need a trick to build tunnel mode (instead of transport mode) dynamic tunnels to works through NAT, if I'm right and it is possible.
BTW I made this config based on the L2TP "use-ipsec" mechanism ;)
 
oreggin
Member Candidate
Member Candidate
Posts: 172
Joined: Fri Oct 16, 2009 9:21 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Tue May 21, 2019 4:31 pm

Now it comes into my mind I tried this HUB setup with cisco CPE and when it is connects to HUB it somehow generating tunnel mode policy but I can't figured out how did it do that :(
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Tue May 21, 2019 5:01 pm

Cisco have their own protocol for that (DMVPN).
 
oreggin
Member Candidate
Member Candidate
Posts: 172
Joined: Fri Oct 16, 2009 9:21 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Tue May 21, 2019 5:12 pm

Cisco have their own protocol for that (DMVPN).
Yes, high-end vendors has mGRE+NHRP based DMVPN which is good but not scalable above some thousands of tunnels and it is off topic over here.
 
sindy
Forum Guru
Forum Guru
Topic Author
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Tue May 21, 2019 6:34 pm

We have only one spoke behind every branch's ISP modem which are the NAT GWs, but spokes behind NAT with this configuration does not work.
There is no need any trick to supports more spoke behind the same NAT GW.
We need a trick to build tunnel mode (instead of transport mode) dynamic tunnels to works through NAT, if I'm right and it is possible.
BTW I made this config based on the L2TP "use-ipsec" mechanism ;)
No. If a single client is behind a NAT (or even behind several NATs in series), you don't need the tunnel mode of encapsulation - in fact, it makes the configuration simpler if you don't. Read the initial article of this topic, it explains why. So if it doesn't work the reason must be different. The L2TP/IPsec clients behind NAT work this way if you set use-ipsec=yes, the only difference to your setup, on top of the IKE type and authentication method, is that the policy at client side is not created by the IPsec stack itself but by the L2TP configiration handler, and if I remember right, it is restricted to UDP and ports 1701 at both ends. But that is not a difference which would affect the overall result.

So can you show me the /ip ipsec policy print and /ip ipsec policy print detail from the hub and the spoke behind NAT?
 
oreggin
Member Candidate
Member Candidate
Posts: 172
Joined: Fri Oct 16, 2009 9:21 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Wed May 22, 2019 1:33 pm

Meanwhile I switched the cabelmodem to bridge mode for testing so now the spoke has public IP, but I will switch it back as cabelmodem in this mode has a reduced feature set.
Another thing I tried is a static policy on spoke with UDP:1701:1701 and tunnel mode, under identity "generate-policy=none", but unfortunately I must set the SRC to router source address in SRC option or at least the /8 or /4 subnet where that address is. On HUB dynamic policies generated with the same subnet and phase2 SAs address is my spoke's address. I don't know what will be happens if I sit this CPE back to behind NAT. BTW the configs now looks like:

HUB:
/ip ipsec identity
add auth-method=rsa-signature certificate=cert_HUB disabled=no generate-policy=port-strict peer=Spokes
/ip ipsec policy
set 0 disabled=no dst-address=0.0.0.0/0 group=default proposal=default protocol=udp src-address=192.0.2.1/32 template=yes

/ip ipsec policy print
Flags: T - template, X - disabled, D - dynamic, I - invalid, A - active, * - default 
 0 T * group=default src-address=192.0.2.1/32 dst-address=0.0.0.0/0 protocol=udp proposal=default template=yes 

 1  DA  src-address=192.0.2.1/32 src-port=1701 dst-address=198.0.0.0/8 dst-port=1701 protocol=udp action=encrypt level=unique ipsec-protocols=esp tunnel=yes sa-src-address=192.0.2.1
       sa-dst-address=198.51.100.1 proposal=default ph2-count=1
Spoke1:
/ip ipsec identity
add auth-method=rsa-signature certificate=cert_Spoke1 disabled=no generate-policy=no match-by=certificate peer=HUB remote-certificate=cert_HUB
/ip ipsec policy
set 0 disabled=yes dst-address=0.0.0.0/0 group=default proposal=default protocol=all src-address=0.0.0.0/0 template=yes
add action=encrypt disabled=no dst-address=192.0.2.1/32 dst-port=1701 ipsec-protocols=esp level=require proposal=default protocol=udp sa-dst-address=192.0.2.1 sa-src-address=0.0.0.0 \
    src-address=198.0.0.0/8 src-port=1701 tunnel=yes

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

 1  A  src-address=198.0.0.0/8 src-port=1701 dst-address=192.0.2.1/32 dst-port=1701 protocol=udp action=encrypt level=require ipsec-protocols=esp tunnel=yes sa-src-address=0.0.0.0 
       sa-dst-address=192.0.2.1 proposal=default ph2-count=1
If two Spoke hase a near IPv4 address then I must set different SRC in policy on Spokes otherwise only one spoke can connect.
 
sindy
Forum Guru
Forum Guru
Topic Author
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Wed May 22, 2019 2:12 pm

unfortunately I must set the SRC to router source address in SRC option or at least the /8 or /4 subnet where that address is, but in that case, only one of the spokes works at a time
Of course, because a mirror of each spoke's policy is created at hub side, so if the src-address of two spokes is the same, you end up with two policies with identical traffic selectors on hub side.

So when you use transport mode of encapsulation, the src-address of the policy is the same as its sa-src-address, and changes along the path with it. So it is the one assigned by the ISP modem at the spoke side, but silently changes into the public address of the ISP modem as it reaches the hub. So you'll see the policies not to mirror each other but nevertheless interwork properly.

When you use tunnel mode for encapsulation, you have to assign, to each of the spokes which uses tunnel mode, a unique private address and use it as src-address for the policy (and take measures that the L2TP packets would be sent from this address - the easiest way is to use an chain=srcnat action=srcnat protocol=udp src-port=1701 dst-port=1701 dst-address=the.public.ip.of.the.hub to-addresses=the.unique.private.ip rule as the first rule in /ip firewall nat). This way, the dst-address of policies at hub side will not end up with conflicting traffic selectors, and these unique addresses will be static ones so they won't depend on dynamically changing public IPs of the ISP modems. That address doesn't even need to be assigned to any interface on the spoke, the src-nat rule will do everything necessary.

Off topic, what is your native language if I may ask?
 
oreggin
Member Candidate
Member Candidate
Posts: 172
Joined: Fri Oct 16, 2009 9:21 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Wed May 22, 2019 3:05 pm

Off topic, what is your native language if I may ask?
Sure, my native lang is hungarian. I hope my english is not too wrong and you understand what I'd like to say. BTW we using worse, strange, mixed language in business that you shouldn't see/hear :-D
 
sindy
Forum Guru
Forum Guru
Topic Author
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Wed May 22, 2019 3:36 pm

I hope my english is not too wrong and you understand what I'd like to say.
English is not my native language either so I'm not the one to judge on the "too wrong" part; I also believe that I've understood everything properly so far. I've asked only because I have noticed some minor inditia that English is not your first language but they didn't match any of the "national versions" of English I can recognize :-)
 
Rok1215
just joined
Posts: 9
Joined: Sun Aug 04, 2019 11:43 am

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Fri Aug 23, 2019 11:38 am

I've been having a similar problem, with a remote VPN connection and a IP Phone connected on the same remote network, when the vpn connection is active, it drops the phone connection.
So I was recommended this topic, to solve my problem, and it seems like a solution. This is a lot more technical for me, than I am used so, so I apologize in advance for any stupid questions.
So I tried to follow your instructions, and from what I've read in this topic, the only thing that I would need to change is the "1.2.3.4", with my public IP?
And the first problem I ran into while trying to configure this, is with the line:
"add chain=input src-address=127.0.0.0/8 dst-address=127.0.0.0/8 action=accept place-before=right after the "accept established,related" rule
At place-before=right after the "accept established,related" rule" it gives me a syntax error, and I'm not sure if I'm supposed to change anything in this line?
 
sindy
Forum Guru
Forum Guru
Topic Author
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Fri Aug 23, 2019 3:24 pm

At place-before=right after the "accept established,related" rule it gives me a syntax error, and I'm not sure if I'm supposed to change anything in this line?
Sure you are. The whole text right after the "accept established,related" rule has to be replaced with a rule number; however, you have to know that the numbers are generated dynamically in each management window. So you cannot look at the firewall rule listing in WinBox or WebFig and use the rule numbers shown there; instead, in the same command line window where you'll be entering the rule above, do first /ip firewall filter print chain=input. You'll get a listing of all rules in chain input; it is likely (but not guaranteed) that the rule saying action=accept ... connection-state=established,related... will be numbered as 0 in the leftmost column; in such case, you'll set place-before=1 in the rule you will enter. Unfortunately there is only place-before, not place-after, and the number substitutes a reference so you cannot determine a rule using [find chain=input action=accept connection-state~"established"] and then add 1 to the resulting number because the result of find is a reference, not a number.

If the configuration of your machine comes from some very old ROS version, it is possible that your firewall looks different. So if you cannot find a rule action=accept ... connection-state=established,related... in chain input of your /ip firewall filter, follow the hint in my automatic signature below.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Fri Aug 23, 2019 3:53 pm

Normally when trying to get people to add some rule at a specific place I just give them the rule as commandline without any placement reference, it will be added at the end of the list, and then direct them to move it up using the GUI (either winbox or webfig)...
 
thaideval
just joined
Posts: 15
Joined: Mon Jul 01, 2019 11:23 am

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Fri Aug 23, 2019 5:32 pm

Is it still a thing? i mean if i have l2tp/ipsec vpn and i want to connect roadwarriors - i still have to do all this?.. well u did a hell of a job. respect for that.
But i honestly thought this bug would be fixed ..

btw what vpn u will advice for roadwarriors on mikrotik?
i can imagine its not l2tp/ipsec.. is it pure ipsec?
 
sindy
Forum Guru
Forum Guru
Topic Author
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Fri Aug 23, 2019 10:05 pm

Is it still a thing? i mean if i have l2tp/ipsec vpn and i want to connect roadwarriors - i still have to do all this?
Only if you need several road warriors connected from the same LAN at the same time, which often means that the sessions come to the server from the same public address.

But i honestly thought this bug would be fixed ...
It is not a bug of RouterOS, it is a design choice of the gentlemen who have defined L2TP over IPsec.

btw what vpn u will advice for roadwarriors on mikrotik?
i can imagine its not l2tp/ipsec.. is it pure ipsec?
If you don't mind the need to install a machine certificate on the Windows, it's definitely IKEv2, which is pure IPsec and doesn't suffer from the issue this topic deals with.
Plus it is currently the only VPN type for which Mikrotik can push routes to the Windows client, so you neither have to send all the client's traffic via the VPN nor you have to configure routes towards the VPN subnets manually on the client, because starting from 6.44, RouterOS responds to DHCPINFORM with a DHCPACK carrying an Option 249 which carries a route list generated from the split-include item in the /ip ipsec mode-config row referred to from the ip ipsec identity row.
 
thaideval
just joined
Posts: 15
Joined: Mon Jul 01, 2019 11:23 am

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Sat Aug 24, 2019 5:00 pm

Thank you very much, man!
I will now try to setup ipsec/ikev2. I will try eap-radius (dont wonna struggle with client certificates).
 
Rok1215
just joined
Posts: 9
Joined: Sun Aug 04, 2019 11:43 am

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Thu Aug 29, 2019 10:42 am

At place-before=right after the "accept established,related" rule it gives me a syntax error, and I'm not sure if I'm supposed to change anything in this line?
Sure you are. The whole text right after the "accept established,related" rule has to be replaced with a rule number; however, you have to know that the numbers are generated dynamically in each management window. So you cannot look at the firewall rule listing in WinBox or WebFig and use the rule numbers shown there; instead, in the same command line window where you'll be entering the rule above, do first /ip firewall filter print chain=input. You'll get a listing of all rules in chain input; it is likely (but not guaranteed) that the rule saying action=accept ... connection-state=established,related... will be numbered as 0 in the leftmost column; in such case, you'll set place-before=1 in the rule you will enter. Unfortunately there is only place-before, not place-after, and the number substitutes a reference so you cannot determine a rule using [find chain=input action=accept connection-state~"established"] and then add 1 to the resulting number because the result of find is a reference, not a number.

If the configuration of your machine comes from some very old ROS version, it is possible that your firewall looks different. So if you cannot find a rule action=accept ... connection-state=established,related... in chain input of your /ip firewall filter, follow the hint in my automatic signature below.
Thank you for your help, it was as you stated, and everything went as planned, and I got no other syntax errors, and I see the VPN connections go trough the IP tunnels now.
But it seems like this isn't a solution for my problem. If I understand correctly, this is a solution if you have 2 L2TP/IPsec connections from the same network, that connect to the same public ip. But in my case I have 1 VPN connection, and a VoIP telephone connection, and I am not sure what kind of encryption protocol it uses. So this is a standard Samsung IP Telephone, that just connects to our office public IP, and then goes to our MikroTik router and then to our OfficeServ phone server that uses the g.729a codec. For this to work, the following ports are opened and set for this on the router:
-6000 UDP = IP data SIP connection, -9000 UDP = IP connection setup, -30000-30030 UDP = IP channels.
Is there any way for the router to distinguish between the VPN connection and the VoIP connection? Because right now, it will always prioritize the VPN connection, and the phone disconnects when you connect trough the VPN, and then reconnects when the VPN connection is turned off.
 
sindy
Forum Guru
Forum Guru
Topic Author
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Thu Aug 29, 2019 11:22 am

If I understand correctly, this is a solution if you have 2 L2TP/IPsec connections from the same network, that connect to the same public ip.
Not exactly but maybe it's just wrong wording. There is no problem if multiple clients connect to the same server (listening at a public IP); the problem which my setup overcomes is that the server receives both the clients' connections from the same IP address because both clients are behind the same NAT.

But in my case I have 1 VPN connection, and a VoIP telephone connection, and I am not sure what kind of encryption protocol it uses. So this is a standard Samsung IP Telephone, that just connects to our office public IP, and then goes to our MikroTik router and then to our OfficeServ phone server that uses the g.729a codec. For this to work, the following ports are opened and set for this on the router:
-6000 UDP = IP data SIP connection, -9000 UDP = IP connection setup, -30000-30030 UDP = IP channels.
Is there any way for the router to distinguish between the VPN connection and the VoIP connection? Because right now, it will always prioritize the VPN connection, and the phone disconnects when you connect trough the VPN, and then reconnects when the VPN connection is turned off.
Words "standard", "usual", "normal", "typical" bear no useful information :)

If I get you right, the VoIP phone doesn't need the VPN to work, but once you start the VPN, the phone stops working. This suggests that the phone is connected to the LAN of the VPN client router and while the VPN is down, it connects to the public IP address of Mikrotik in the office directly; when the VPN connects, routing on the client Mikrotik changes accordingly and the packets from the VoIP phone start getting to the office via some other path or stop getting there at all.

So open a separate topic for this, and start from a drawing which removes any doubts regarding the interconnections and eventual NATs and port forwardings between the phone and the client router and also between the office router and the call server there.
 
oreggin
Member Candidate
Member Candidate
Posts: 172
Joined: Fri Oct 16, 2009 9:21 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Fri Aug 30, 2019 2:54 pm

Meanwhile I tested a script for update ipsec policy behind NAT:
:global uplinkif "ether1"
:global poladdr [ /ip ipsec policy get [ find peer=HUB ] src-address ]
:global polip [:pick $poladdr 0 [:find $poladdr "/"]]
:global intaddr [ /ip address get [ find interface=$uplinkif and dynamic ] address ]
:global intip [:pick $intaddr 0 [:find $intaddr "/"]]
:if ($intip != $polip) do={
	:log info ("IPSec policy update...")
	/ip ipsec policy set [ find peer=HUB ] src-address="$ipinterf/32"
}
Router run this in every 5 minutes, and check.

Another issue what I faced for is the NAT in cabelmodem. Sometimes the translation entry stucked in and IPSecSA-s can't get established so I need to disable ipsec peer for some seconds and then reenable:
:global state [ /ip ipsec active-peers get [ find remote-address=1.2.3.4 ] state ]
:global phc [ /ip ipsec policy get [ find peer=HUB ] ph2-count ]
:if ($state != "established") do={
	/ip ipsec peer disable [ find name=HUB ]
	:delay 62
	/ip ipsec peer enable [ find name=HUB ]
} else={
	:if ($phc < 1) do={
		/ip ipsec peer disable [ find name=HUB ]
		:delay 62
		/ip ipsec peer enable [ find name=HUB ]
	}
}
I assume that UDP translation timeout in camblemodem NAT implementation is 30sec, so I doubled it plus increased by 2 so I get 62. This is a rare situation and I survive 62+some seconds without VPN.
 
jaytcsd
Member
Member
Posts: 332
Joined: Wed Dec 29, 2004 9:50 am
Location: Pittsboro IN
Contact:

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Mon Sep 16, 2019 11:52 pm

Very informative, I just skimmed over it and will dive into it later today.
I had L2TP IPSEC working in 2011 under 5.4 but as the OS was updated I kept having to chase the changes to make it work, finally I gave up.
 
Dutchman
just joined
Posts: 5
Joined: Fri Oct 19, 2018 4:15 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Wed May 20, 2020 1:51 pm

Hi Sindy,
Will this solution work if there is more than just 2 Road Warriors L2TP/IPsec clients behind NAT?
I have about 10 on a site and they use one central fibre line to connect to our main VPN server and from what I pick up is that it works as it gives one of the devices a Caller ID in the 10.0.0.0/20 range but the others still seem get the same public address and then reconnect after a bit.
Thanks!
 
sindy
Forum Guru
Forum Guru
Topic Author
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Wed May 20, 2020 2:55 pm

Will this solution work if there is more than just 2 Road Warriors L2TP/IPsec clients behind NAT?
That's the very purpose of this solution.

I have about 10 on a site and they use one central fibre line to connect to our main VPN server and from what I pick up is that it works as it gives one of the devices a Caller ID in the 10.0.0.0/20 range but the others still seem get the same public address and then reconnect after a bit.
I don't understand from your description what the actual problem is. All L2TP clients' connections arrive to the Mikrotik with the same public source IP, that's correct. The solution depends, however, on the fact that the client-side NAT should assign a different UDP port at its WAN side to each of these connections, which is what NATs normally do, otherwise they would be unable to map incoming packets from the same remote server address and port to the proper pinhole (connection).

The whole solution is based on incrementing the internal src-nat address for each new connection. So post the export of your current configuration, and also the output of /ip firewall connection print detail where dst-address~"500\$" while multiple clients are attempting to connect.

Also bear in mind that the solution has been created at ROS 6.43 times, so it may be not only a mistake in configuration but something may have changed slightly.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Fri Jun 26, 2020 11:24 am

Hi sindy,

Recently I see a lot of people complaining that with version 6.47 their L2TP/IPsec connections fail when they are behind the same NAT.
They claim it works when they downgrade.

Are you aware of any fix that MikroTik may have introduced somewhere in the 6.46 branch or earlier, and that suddenly made it work without this elaborate workaround?
(and which now has been broken again in 6.47)

I was not aware of that... or maybe there are just some cases where it happened to work?
 
noib
Member Candidate
Member Candidate
Posts: 291
Joined: Fri Jan 25, 2013 6:04 pm
Location: France
Contact:

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Fri Jun 26, 2020 11:57 am

I confirm this behaviour.
RouterOS 6.47 as L2TP server
Cambium access points as L2TP clients (no IPSEC here)
Works fine with 1 AP. But the second AP, connecting from the same LAN, never gets in.

Reverting server to "long-term" 6.45.9 and woot, both APs connect.
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7038
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Fri Jun 26, 2020 12:14 pm

Post ipsec policies and installed SAs from version where it works and from version where it does not.

Multiple l2tp/ipsec connections behind one NAT router will work if at least one of the following conditions apply:
*) each client gets NATed behind unique public IP address;
*) each client uses unique L2TP source port.

Devices like windows and ROS always use 1701 as source port, so these clients will never be able to establish more than one connection at the same time, because it is not possible to distinguish which packet belongs to which client since src port and src address is identical for all the clients.

Other L2TP vendors may randomize source port, in this case ipsec can creates unique SAs for address and port combination.

This apply to all ROS versions including the older ones.
 
sindy
Forum Guru
Forum Guru
Topic Author
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Fri Jun 26, 2020 1:26 pm

@mrz, I haven't installed 6.47 anywhere yet and won't do that until the frequent write issue is resolved (currently nowhere to run CHR, where frequent writes wouldn't mean excess wear of the flash chip), but from what I've understood from the related complaints in the "6.47 has been released" topic, those users who did use clients behind same client-side NAT were using multiple IP addresses at the server side so that the combination of client side NAT IP and server side IP was unique all the time. So if this approach has stopped working, it may be related to a change in the way how the policies are generated, or how the L2TP server chooses an IP address for the response, so the multiple server-side IPs do not help any more.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Fri Jun 26, 2020 1:30 pm

Multiple l2tp/ipsec connections behind one NAT router will work if at least one of the following conditions apply:
*) each client gets NATed behind unique public IP address;
*) each client uses unique L2TP source port.
Of course when the IPsec is done over NAT the NAT-T UDP source port (normally 4500) has to be different for the two different clients. At least one of them has to be translated to another source port by the NAT router.
That information could be communicated to the IPsec layer as part of the key to select the IPsec session and then to the L2TP layer to distinguish the L2TP connections.
That is probably how those VPN routers that can do this impossible thing are doing it.
Not very clean, but it does help the customer.
 
sindy
Forum Guru
Forum Guru
Topic Author
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Wed Jul 01, 2020 11:31 pm

RouterOS 6.47 as L2TP server
Cambium access points as L2TP clients (no IPSEC here)
Works fine with 1 AP. But the second AP, connecting from the same LAN, never gets in.
@noib, the issue of two clients behind the same public IP is directly related to use of IPsec to encrypt the L2TP; without IPsec, the client-side ports become different after passage through the NAT, so the server has no problem telling one from another.

So the issue you have with 6.47 must be different in some regard, can you open a dedicated topic for it as it is strictly speaking irrelevant to this one, post your configuration export in that new topic, and place a link to it here? The configuration may be from the version which works fine, no need to upgrade and downgrade again.
 
noib
Member Candidate
Member Candidate
Posts: 291
Joined: Fri Jan 25, 2013 6:04 pm
Location: France
Contact:

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Mon Jul 06, 2020 12:24 pm

@sindy, i do not use IPSEC, just plain L2TP, indeed this is irrelevant to this topic, sorry. I will create a new topic.
 
sindy
Forum Guru
Forum Guru
Topic Author
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Mon Jul 06, 2020 12:29 pm

I will create a new topic.
It seems there is no need: viewtopic.php?f=21&t=161887&start=300#p803641
 
killersoft
Member Candidate
Member Candidate
Posts: 235
Joined: Mon Apr 11, 2011 2:34 pm
Location: Victoria, Australia

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Wed Jul 08, 2020 5:22 am

Can confirm in 6.47 there is an issue with l2tp/ipsec vpn, where the server + client device is also a mikrotik, and the client runs a NAT. The client side NAT rule doesnt even get a hit when IPSEC is enabled(both ends). If I turn it off(both ends) and just run l2tp, all is good and the src-nat rule gets hits on the client MT side and the end client machine get a connection

[Internet-SVR-MT l2tp/ipsec]----------internet/isp---[ether1(dhcp-client)--MT l2tp/ipsec(no prob connecting)----srcnat-rule----bridge(dhcp-svr)--ether2]-----client machine(s)

Client can connect to far end(srv side) internet if IPSEC is disabled
If IPSEC = enabled ( client box cant get past client-side MT ) & notably the srcnat rule doesn't get a hit from the client.

No problems under 6.45.9 !!
 
sindy
Forum Guru
Forum Guru
Topic Author
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Wed Jul 08, 2020 8:32 am

Client can connect to far end(srv side) internet if IPSEC is disabled
If IPSEC = enabled ( client box cant get past client-side MT ) & notably the srcnat rule doesn't get a hit from the client.

No problems under 6.45.9 !!
So the L2TP/IPsec client is running on the client side Mikrotik itself, not on the client PC, correct?

Can you post both Mikrotik configurations (see anonymisation hints in my automatic signature just below)?
 
killersoft
Member Candidate
Member Candidate
Posts: 235
Joined: Mon Apr 11, 2011 2:34 pm
Location: Victoria, Australia

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Thu Jul 09, 2020 6:59 am

Client can connect to far end(srv side) internet if IPSEC is disabled
If IPSEC = enabled ( client box cant get past client-side MT ) & notably the srcnat rule doesn't get a hit from the client.

No problems under 6.45.9 !!
Can you post both Mikrotik configurations (see anonymisation hints in my automatic signature just below)?
TO NOTE THIS WORKS UNDER 6.45.9 - LONG TERM, BUT 6.47 BREAKS(notably the client MT Firewall->NAT rule doesn't have a single hit of data! )


SERVER-MT SIDE(AWS HOSTED CHR)
/interface ethernet
set [ find default-name=ether1 ] disable-running-check=no
/ip ipsec proposal
set [ find default=yes ] enc-algorithms=aes-256-cbc,aes-192-cbc
/ip pool
add name=vpn-pool ranges=192.168.175.2-192.168.175.20
/ppp profile
add change-tcp-mss=yes name=L2PT_SERVER_PROFILE remote-address=vpn-pool \
    use-encryption=yes
/ip neighbor discovery-settings
set discover-interface-list=all
/interface l2tp-server server
set authentication=mschap2 default-profile=L2PT_SERVER_PROFILE enabled=yes \
    mrru=1500 use-ipsec=yes
/ip dhcp-client
add dhcp-options=hostname,clientid disabled=no interface=ether1
/ip firewall filter
add action=accept chain=input in-interface=ether1 protocol=gre
add action=accept chain=input comment="allow L2TP VPN (ipsec-esp)" \
    in-interface=ether1 protocol=ipsec-esp
add action=accept chain=input comment="allow L2TP VPN (500,4500,1701/udp)" \
    dst-port=500,1701,4500 in-interface=ether1 protocol=udp
add action=accept chain=forward connection-state=established,related
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1
/ip firewall service-port
set ftp disabled=yes
set tftp disabled=yes
set irc disabled=yes
set h323 disabled=yes
set udplite disabled=yes
/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
/ppp secret
add local-address=192.168.175.1 name=Work profile=default-encryption \
    remote-address=192.168.175.3 service=l2tp
/system clock
set time-zone-name=Australia/Sydney
/system package update
set channel=long-term
/tool romon
set enabled=yes


CLIENT MT(VPN) DEVICE
# jul/08/2020 11:46:02 by RouterOS 6.45.9
/interface wireless
set [ find default-name=wlan1 ] band=2ghz-g/n channel-width=20/40mhz-Ce \
    country=australia disabled=no installation=indoor mode=ap-bridge ssid=DF
/interface bridge
add name=bridge1
/interface l2tp-client
add add-default-route=yes allow=mschap2 connect-to=***.***.***.*** disabled=no \
    name=PPP_LINK use-ipsec=yes user=Work
/interface wireless security-profiles
set [ find default=yes ] authentication-types=wpa2-psk disable-pmkid=yes \
    eap-methods="" mode=dynamic-keys supplicant-identity=MikroTik
/ip ipsec profile
set [ find default=yes ] nat-traversal=no
/ip pool
add name=dhcp_pool0 ranges=192.168.100.2-192.168.100.254
/ip dhcp-server
add address-pool=dhcp_pool0 disabled=no interface=bridge1 lease-time=1h name=\
    dhcp1
/interface bridge port
add bridge=bridge1 interface=ether2
add bridge=bridge1 interface=wlan1
/interface bridge settings
set use-ip-firewall=yes use-ip-firewall-for-pppoe=yes \
    use-ip-firewall-for-vlan=yes
/interface l2tp-server server
set use-ipsec=yes
/ip address
add address=192.168.100.1/24 interface=bridge1 network=192.168.100.0
/ip cloud
set update-time=no
/ip dhcp-client
add dhcp-options=hostname,clientid disabled=no interface=ether1
/ip dhcp-server network
add address=192.168.100.0/24 gateway=192.168.100.1
/ip firewall filter
add action=accept chain=input src-address=192.168.100.0/24
/ip firewall nat
add action=masquerade chain=srcnat out-interface=PPP_LINK src-address=\
    192.168.100.0/24
/ip route
add distance=1 gateway=PPP_LINK
/system clock
set time-zone-name=Australia/Sydney
/system package update
set channel=long-term
/system routerboard settings
set auto-upgrade=yes


A LAPTOP / PC THEN CONNECTS TO THE CLIENT-MT DEVICE EITHER VIA WIFI OR ETH2 !
 
radians
just joined
Posts: 1
Joined: Thu Nov 19, 2020 3:07 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Thu Nov 19, 2020 3:12 pm

Hello to all,
It's very very interesting this post, but also very complex to follow. I new with mikrotik, and i will need some help.
Someone can help me on this? sorry for ask...

thanks in advance. RAD
 
Zacharias
Forum Guru
Forum Guru
Posts: 3459
Joined: Tue Dec 12, 2017 12:58 am
Location: Greece

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Thu Oct 07, 2021 8:58 pm

@sindy,

Is this considered as fixed in later versions ?
As i' ve tested the connection from a second client from the same network connecting to the same remote L2TP server will stay up...

I guess the change log *) l2tp - fixed multiple tunnel establishment from the same remote IP address (introduced in v6.47);
refers to that ?
 
sindy
Forum Guru
Forum Guru
Topic Author
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Thu Oct 07, 2021 9:47 pm

I guess the change log *) l2tp - fixed multiple tunnel establishment from the same remote IP address (introduced in v6.47);
refers to that ?
I was discussing that with someone when 6.47 has been released, and Emils has stated that it was an issue of bare L2TP, without IPsec. So completely unrelated. To overcome the limitation of L2TP/IPsec clients, by a "fix" in RouterOS itself, Mikrotik would have to create some proprietary interworking between the IPsec layer and the L2TP layer - namely, it would have to overwrite the src-port of the L2TP packets decapsulated from the IPsec transport ones by the src-port value received in these transport packes.

If the first client stays connected after the second one connects from behind the same NAT, I's assume it's because RouterOS now refuses to install the second one's policy as it would collide with an already existing one.
 
Zacharias
Forum Guru
Forum Guru
Posts: 3459
Joined: Tue Dec 12, 2017 12:58 am
Location: Greece

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Sat Oct 09, 2021 12:36 pm

@sindy,

Policies are created for both the Remote L2TP/IPsec clients, which are exact the same, except the second one is missing the Destination Port field, its empty, whereas for the first one is 1701...
Other than that i can't see any other difference...

To sum up, both L2TP clients are on the same L2 network, and are connected to the Same remote L2TP/IPsec Server that has a Public IP configured on its interface...
IPsec is set to required ofcorse

Connection stays up with no problems...

So what is the case here ?
 
sindy
Forum Guru
Forum Guru
Topic Author
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Sat Oct 09, 2021 2:33 pm

The fact that one policy has dst-port=1701 and the other one doesn't is the key - see the last two paragraphs of chapter The root cause in the OP.

I'd assume the reason in your case is that you use different client implementations. The L2TP standard says that both the client and the server bind to the same UDP port, 1701, but not all clients respect this - when both clients are connected, /ip firewall connection print where dst-address~":1701" should show you the actual ports the clients use. Similarly, the traffic selectors requested by the clients differ - some ask for addr1:addr2:udp:1701:1701, others ask for just addr1:addr2.

If I remember well, Windows were using 1701 at their side and a port-strict policy; Android phones were using a random port and an addr1:addr2 policy.

So in your case, the policy with dst-port=1701 is likely the first one to get hit, so packets towards client.public.ip:1701 get sent down the SA created by that policy; the "wider" policy catches the rest of the traffic towards client.public.ip, which didn't match the first one because its destination port differs from 1701, and sends it down its own SA.
 
Zacharias
Forum Guru
Forum Guru
Posts: 3459
Joined: Tue Dec 12, 2017 12:58 am
Location: Greece

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Sat Oct 09, 2021 4:10 pm

@sindy you 're right on that... It is a Windows client and an Android Client...
The Android client indeed uses a different src port and not 1701...

So that is why it works ...
From a quick search i see the port on windows can not be changed ...
 
Zacharias
Forum Guru
Forum Guru
Posts: 3459
Joined: Tue Dec 12, 2017 12:58 am
Location: Greece

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Thu Jan 06, 2022 5:34 pm

Has anyone tested if there is a fix on that on ROS v 7 ?

I found this viewtopic.php?t=109554#p543642
 
GuntOn
just joined
Posts: 15
Joined: Mon Apr 23, 2018 7:11 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Mon Jan 10, 2022 4:55 pm

I'm also interested if this issue is fixed in RoS 7...
 
Zacharias
Forum Guru
Forum Guru
Posts: 3459
Joined: Tue Dec 12, 2017 12:58 am
Location: Greece

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Tue Jan 11, 2022 4:47 pm

I will test it as soon as i find some time...
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Tue Jan 11, 2022 5:15 pm

People are complaining that the L2TP Server isn't stable in v7 at the moment, so you should probably only test this when you have an independent test environment available.
 
sindy
Forum Guru
Forum Guru
Topic Author
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Tue Jan 11, 2022 5:25 pm

I will test it as soon as i find some time...
I've found the time right now - as expected, it behaves the same like it did before.

I'm also interested if this issue is fixed in RoS 7...
As outlined in the OP of this topic, it is not a bug of RouterOS to be "fixed" - it is a design choice of the gentlemen who standardized L2TP over IPsec, who gave priority to saving a few bytes of overhead over a possibility to allow multiple clients connect to the same server from behind the same public IP.

So if you have strong reasons to connect multiple non-Mikrotik L2TP/IPsec clients to the same L2TP/IPsec server from behind the same public IP, you have to use the workaround outlined in the OP even on ROS 7.2rc1 where I have just tested how it behaves without that workaround.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Tue Jan 11, 2022 6:14 pm

I think that the issue could be solved in the IPsec layer by allowing the use of the NAT-T UDP source port as an extra key for selection of the matching IPsec policy.
Even though all other parameters of the IPsec policy are the same, the NAT-T UDP ports cannot be, because the NAT router at the client side has seen that it has two UDP sessions from two clients to the same server, so it translates the source port from 4500 (the usual NAT-T port) to some random port.
When the IPsec implementation in v7 allows to use this extra information to key the policy selection, it can work around this problem without requiring configuration tricks.
That is probably also what other manufacturer's routers (that are claimed not to have this problem) are doing.

However, be warned: back in the days when MikroTik wrote that v7 would be the solution for all difficult problems, they probably had a rough sketch of all those modules that they would be going to rewrite and how they all would be so much better. In the years following, it looks like only the autorouting (BGP,OSPF) and maybe some features in the routing itself have survived that optimism. Many other new features were instead implemented in v6 and taken into v7 as well, and this is not one of them. It is not obvious that v7 has different IPsec code than v6 (as it is for routing).
 
sindy
Forum Guru
Forum Guru
Topic Author
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Tue Jan 11, 2022 6:55 pm

When the IPsec implementation in v7 allows to use this extra information to key the policy selection, it can work around this problem without requiring configuration tricks.
That is probably also what other manufacturer's routers (that are claimed not to have this problem) are doing.
The way you suggest, the information about the additional port number would have to reach the L2TP stack in the form of some meta-header of the payload packets extracted from those received using the particular IPsec policy, and then in the reverse direction, the L2TP stack would have to send the same meta-header and the IPsec traffic selection would have to use it as a key to select the policy. So not only that some specific behaviour would have to be linked to the IPsec identity - the L2TP stack would also have to be modified. So it would be a complex modification but, in a way, a clean one.

Another way would be to limit the specific behaviour to the decryption and encryption process of IPsec, leaving the L2TP code completely unchanged - instead of using a metaheader, it would be "enough" to let the decrypted UDP payload packet inherit the port number from the transport one. However, this would require a stateful behaviour of the policy, as it would have to remember the originally received payload port number in order to use it when substituting the payload destination port during encryption in the server->client direction.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Tue Jan 11, 2022 7:06 pm

The way you suggest, the information about the additional port number would have to reach the L2TP stack in the form of some meta-header of the payload packets extracted from those received using the particular IPsec policy, and then in the reverse direction, the L2TP stack would have to send the same meta-header and the IPsec traffic selection would have to use it as a key to select the policy. So not only that some specific behaviour would have to be linked to the IPsec identity - the L2TP stack would also have to be modified. So it would be a complex modification but, in a way, a clean one.
I think that is the reason why MikroTik wrote that it cannot be fixed in v6 but will be fixed in v7 ("when we do that IPsec rewrite anyway").
However, now that v7 has arrived, that rewrite probably did not (yet) take place, and the situation is still the same (cannot fix that now, maybe later).
 
Zacharias
Forum Guru
Forum Guru
Posts: 3459
Joined: Tue Dec 12, 2017 12:58 am
Location: Greece

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Tue Jan 11, 2022 7:51 pm

People are complaining that the L2TP Server isn't stable in v7 at the moment, so you should probably only test this when you have an independent test environment available.
Yes, that's what i had in mind...

@sindy, really ? It would be so nice if it worked ...
 
GuntOn
just joined
Posts: 15
Joined: Mon Apr 23, 2018 7:11 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Wed Jan 12, 2022 4:33 pm

It looks like this case won't be fixed any time soon and other solutions will have to be found. Has anyone tried SoftEther for multiple L2TP/IPsec clients behind NAT?
 
sindy
Forum Guru
Forum Guru
Topic Author
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Wed Jan 12, 2022 4:36 pm

Just for curiosity, what makes my workaround outlined in the OP unattractive?
 
Zacharias
Forum Guru
Forum Guru
Posts: 3459
Joined: Tue Dec 12, 2017 12:58 am
Location: Greece

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Wed Jan 12, 2022 8:33 pm

Just for curiosity, what makes my workaround outlined in the OP unattractive?
@sindy to be honest its not the fact that it is unattractive... simply there is no reason for that kind of complexity since i can just work with another type of VPN...
In ROS 7 openVPN works on UDP ( in ROS 6 only TCP was supported ) so i can use for the road warriors oVPN or Wireguard or IKEv2 ...
 
sindy
Forum Guru
Forum Guru
Topic Author
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Wed Jan 12, 2022 8:46 pm

simply there is no reason for that kind of complexity since i can just work with another type of VPN...
I am with you on this, I prefer IKEv2 myself for Windows connections as it is the only VPN type to currently support route pushing on Mikrotik acting as a server and once you beat the fear of certificate handling, it performs great. However, many people prefer native VPN clients, and L2TP/IPsec seems to be the only VPN type available at Android, Apple, and Windows without need to install a 3rd party app. So since @GuntOn mentions SoftEther acting as an L2TP/IPsec server in particular, I assume L2TP/IPsec is a must for their application. I did try SoftEther in the past (2-3 yers ago) and I remember had some no go issue with it, but I can't remember what it was.
 
randras
just joined
Posts: 1
Joined: Sun Mar 15, 2020 7:20 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Sun Oct 23, 2022 1:36 pm

Will this solution work if there is more than just 2 Road Warriors L2TP/IPsec clients behind NAT?
That's the very purpose of this solution.
@sindy - thank you very much the solution!
It's perfectly working on ROS 6.49.7
 
User avatar
NTheZone
just joined
Posts: 22
Joined: Fri Jun 19, 2020 8:47 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Wed Nov 09, 2022 10:22 pm

Thank you so much for starting this thread, sindy.

A total noob here running ROS 6.49.7, on an hAP ac2 and also want VPN access across multiple OS'es (iOS, Android, Ubuntu and Windows) and for multiple devices simultaneous on the same LAN. Are these the lines to customize, the bold items, specifically:

# Add routes for the addresses used for the solution
/ip route
add distance=1 dst-address=10.0.0.0/20 gateway=ipip-inner
add distance=1 dst-address=10.0.15.254/32 gateway=ipip-outer

# Add the firewall rule permitting forwarding of dst-nated packets in the first pass
/ip firewall filter
add action=accept chain=forward connection-state=new dst-address=10.0.15.254

# Add the NAT rules
/ip firewall nat
# Restore our public IP address on packets after they've passed through the tunnel
add action=dst-nat chain=dstnat dst-address=10.0.15.254 in-interface=ipip-inner to-addresses=1.2.3.4
# src-nat the packets before sending them to the tunnel
add action=src-nat chain=srcnat out-interface=ipip-outer protocol=udp to-addresses=10.0.0.1
# Redirect packets to port 4500 to the auxiliary destination address to give them the special treatment;
# for testing that it works with only two client devices, remove the "src-port=!4500"
add action=dst-nat chain=dstnat dst-port=4500 src-port=!4500 dst-address=1.2.3.4 protocol=udp to-addresses=10.0.15.254

# Add the cleaner script
/system script
add name=l2tp-helper owner=admin policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon source=\
":local cntr 0; \\\
\n:local auxip [/ip firewall nat get [find chain=\"srcnat\" && out-interface=\"ipip-outer\"] to-addresses]; \\\
\n:while ([/ip firewall connection print count-only where src-address~\"^\$auxip\" && dst-address~\":4500\" && seen-reply]=1) \
do={\
\n :set auxip (\$auxip+1); \\\
\n :if (\$auxip>10.0.15.253) do={:set auxip 10.0.0.1};:set cntr (\$cntr+1)\
\n}\
\n:if (\$cntr>0) do={\
\n /ip firewall nat set [find chain=\"srcnat\" && out-interface=\"ipip-outer\"] to-addresses=\"\$auxip\"; \\\
\n /ip firewall connection remove [find dst-address~\":4500\" && !seen-reply]\
\n}\
\n"

Questions:
  • What is ip 1.2.3.4 used for?
    What if my gateway / DHCP server is 192.168.88.1, how exactly would I change line: "if (\$auxip>10.0.15.253) do={:set auxip 10.0.0.1};:set cntr (\$cntr+1)"

Thank you.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18968
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Wed Nov 09, 2022 10:48 pm

Consider zerotier and/or wireguard for simple fast VPN accross all OSs.
 
sindy
Forum Guru
Forum Guru
Topic Author
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Thu Nov 10, 2022 12:44 am

Questions:
  • What is ip 1.2.3.4 used for?
1.2.3.4 needs to be substituted by the actual WAN IP of the router. By default, Windows clients refuse to connect to servers that indicate a different IP address than the one to which the client connects, i.e. those behind a NAT at server side. So the IPsec responder and L2TP server must listen at the public address, but at the same time we need that the incoming traffic was pushed through the tunnel, so we have to dst-nat it twice - to an auxiliary address (10.0.15.254 in the example) and then back to the original one(1.2.3.4 in the example). (NB - during those four years I have learned that the same effect can be accomplished another way, but it does not simplify the overall concept, at least not enough to be worth modifying the example).

  • What if my gateway / DHCP server is 192.168.88.1, how exactly would I change line: "if (\$auxip>10.0.15.253) do={:set auxip 10.0.0.1};:set cntr (\$cntr+1)"
In the example, a range from 10.0.0.1 to 10.0.15.253 is used to provide a unique address for each client, and 10.0.15.254 is used for another internal purpose. This must be a range that is not used anywhere inside your network; if the only subnet you use is 192.168.88.0/24, you can stick with 10.0.0.1-10.0.15.254. If 10.0.0.0/20 or a part of it was used in your network, you would have to use any other non-conflicting range of private addresses instead. The script row in particular ensures a rollover from the highest address in that range back to the lowest one (with each new connection attempt, the address is incremented by one, so after 4091 connection attempts it reaches the end of the range and needs to start from the first one again).

Thank you so much for starting this thread
I didn't know I was starting a thread, I was thinking I was posting an article :)
 
User avatar
NTheZone
just joined
Posts: 22
Joined: Fri Jun 19, 2020 8:47 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Thu Nov 10, 2022 7:11 am

Consider zerotier and/or wireguard for simple fast VPN accross all OSs.

Thanks, but as OP, I'm not looking to install any non-native apps on any of the platforms.
 
detect
just joined
Posts: 1
Joined: Wed Apr 26, 2023 5:25 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Wed Apr 26, 2023 5:34 pm

Hi Sindy, I am asking for your help.I have exactly the same problem as you describe, but it doesn't work for me.
Last edited by detect on Wed Apr 26, 2023 5:41 pm, edited 3 times in total.
 
sindy
Forum Guru
Forum Guru
Topic Author
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Multiple Road Warrior L2TP/IPsec clients behind NAT - solved

Sun Jan 14, 2024 9:15 pm

Hi, no notification has arrived back in March... I guess it is already irrelevant for you, but if not, try responding again.

Who is online

Users browsing this forum: baragoon, GoogleOther [Bot], Pincha3, SpOuK3 and 93 guests