Trying to set up failover of VPN tunnels, however, coming across a few issues.
I'm using the same Service Provider and mirror all L2TP/IPSEC option for the primary tunnel, however the second tunnel is not coming online.

Questions: Is it possible that the conflict arises as I'm using same IPSEC conf for both and they collide thus 2nd tunnel not coming?

Can you please post the config for the tunnels as well as any IPSec config?

Hi,

This is the present config, which works flawlessly on the primary L2TP/IPSEC tunnel from the same provider, but when i try to set the second and give it a higher distance it constantly terminates the session when the 1st one is down... but when 1st one enabled its tunnel goes up seconds while the 2nd is still stuck on "terminating session..." etc.

What do you want to achieve? Connect two tunnels to the same remote VPN peer (same IP address for both tunnels) using a different uplink for each of the tunnels?

If so: to route the packets through different uplinks, you must set a distinct local address to each of the two IPsec peer configurations at the "client" side, so that you could choose the right uplink based on local source address of the IPsec transport packet. But for L2TP over IPsec configured the way you did it (with use-ipsec=yes and the secret), the IPsec peer is generated dynamically and you have no possibility to specify the local side address to be used; if you want to do it another way, you have to configure an IPsec tunnel manually (and then L2TP may not be necessary at all, you can use IPsec with shared secret authentication and x-auth to distinguish between the two users at the "server" side if necessary and use any inner tunnel so that you could prioritize between the two tunnels).

Sindy,

Thank you, that was a very in-depth answer to my question. However, in the given circumstances, I'm the client using 3rd party VPN service trying to connect to two of their VPN end nodes silmultenenously, so when both of online, i can try to do ECMB routing and balance the traffic, instead of the originally planned failover of the two. I think given the circumstances, moving the packets between the two endpoints would be more ideal for the critical side of the network. Unless you have a simpler and more stable/reliable way of assuring connectivity, would be glad to hear.

In-depth answers to ambiguous questions rarely help

OK, so you have two different access points to the VPN service. This makes the situation easier because for an L2TP over IPsec tunnel, you can specify the remote address.

Still, your configuration is a bit puzzling. As already stated, if you create an L2TP-client interface (or an L2TP-server but that's obviously not your concern) with use-ipsec set to yes, RouterOS automatically creates a dynamic IPsec peer using the settings. However, I can see a statically configured IPsec peer in your configuration export. Is that another one relevant for some other IPsec tunnel or have you mistakenly supposed that you have to create a static configuration, and so that static IPsec peer points to the same remote address like the L2TP client remote address?

Great opener

My apologize the proposal referred to is for another tunnel, irrelevant to the situation mentioned in this post. I will edit it eliminate confusion.

UPDATE: Let me re-post the configs

Trying to set up failover of VPN tunnels, however, coming across a few issues.
I'm using the same Service Provider and mirror all L2TP/IPSEC option for the primary tunnel, however the second tunnel is not coming online.

Questions: Is it possible that the conflict arises as I'm using same IPSEC conf for both and they collide thus 2nd tunnel not coming?

Note that if you are trying to setup l2tp behind a NAT or behind same router in a LAN, only one client can come up at a time. You cannot have two clients connected on a LAN behind a NATed interface.

You cannot have two clients connected on a LAN behind a NATed interface.

This is true for pure l2tp clients connecting from behind the same NAT to the same remote server.

The OP has clarified that he has two different remote servers so the NAT device would have to be quite stupid to have a problem in this case.

L2TP over IPsec should not suffer from this as it is L2TP over IPsec and IPsec with NAT-T extension uses UDP as lowest layer transport so NAT traversal is not an issue.

Okay, so now we have two dynamically generated IPsec peer configurations. They still differ in remote address but the local one is determined automatically. The first thing you need to ensure is that for each of the two L2TP-client interfaces remote addresses (connect-to addresses to use the proper vernacular), you'll use the proper uplink. That usually means to set an individual route to each destination with a gateway IP provided by that uplink. Have you done that?

Normally, it is better to export the complete configuration with hide-sensitive option, and then replace user names and IP addresses by some x.y.z patterns but it is really helpful if relationships between addresses remain visible (e.g. the /interface l2tp-client connect-to address and the /ip route dst-address should be substituted by the same x.y.z). By doing so you prevent a lot of questions.

Fine point. I edited/updates the script above for easier reading. Let me know if that helps. I was also thinking about nTH load balancing for the VPN tunnels. Frankly, as originally considered ECMP will not be the best option and there will be link sessions that will have to last for a very long time which ECMP would not work. Perhaps you have an opinion on it too.

Anyways, the basic issue still persists... two tunnels dont want to play nice simultaneously.

Somehow I have problems to get to the same page.

My understanding is the following: there are two remote L2TP/IPsec servers somehow providing access to the same remote network. You want to build two tunnels from a single RouterBoard, each to one of them, each using a different physical connection. To route some generic traffic through these two tunnels, you want to use ECMP. Do I get this part right?

OK.

I have one RB2011. I'm using 3rd party VPN service proder connecting via L2TP/IPSEC protocol. This VPN provider has two difference end nodes in Canada, so i would like to connect to each end node in Canada via L2TP/IPSEC protocol and keep both tunnels online at all time, so if 1 goes down or something happens to it, traffic will move to the other tunnel, and when the 1st tunnel comes back online the traffic will be shared again etc.

ECMP was one option than i started thinking about NTH, both have pros / cons.... my ultimate goal is have stable link to a platform located in Canada which takes only canadian IP, thus the VPN tunnels.

Re-post of the configs:

The OP has clarified that he has two different remote servers so the NAT device would have to be quite stupid to have a problem in this case.

I did n't get this part from his earlier post. In that case its not the issue.

OK. What has made me ask again was that your routing marks etc. are in contrast with what I expect. So I'll give you my complete description of how I would do it.

There is the "tunnel payload" - the packets that need to be delivered to destination through the VPN tunnel. For them, you may use whatever routing strategy you consider best (I have no opinion here as I had to google what ECMP means), but this strategy has to work with only the two tunnels as gateways. The tunnels are represented by virtual interfaces of type l2tp-client, which get IP addresses from the VPN server(s).

These payload packets are enciphered and encapsulated into "transport packets" - the UDP packets carrying ESP carrying L2TP carrying the payload.

However, the routing rules for the transport packets have to be completely different from those used for payload packets. I assume that the two physical connections to the internet are connected to two distinct Ethernet ports of your Mikrotik, each with its own IP address and gateway. Possibly one of them is used as the primary one for all generic traffic, not fitting to any of the two groups discussed above.

So to make sure that each of your tunnels' transport packets will be sent using a different physical channel regardless what else may happen, you need to provide two /32 routes, one per each remote server IP, each using the "default" gateway of a different one of the two uplinks as that route's gateway. If the uplinks assign your IP address dynamically and the "default" gateway indicated may change with each assignment, you'll have to use scripting to keep track with the changes (i.e. to re-set the gateway of the individual route for a VPN server with each DHCP assignment received as a copy of the default gateway received).

By creating these two routes you also ensure that any dynamically obtained default route (as provided by the L2TP servers configured with add-default-route=yes) does not cause the second tunnel to get established through the first one. As the transport packets are locally originated, no src-nat is needed for them as they should leave with the IP of the interface where the uplink is terminated as source. Unless the uplinks are something exotic, this should be automatic.

The next thing to solve is that you have a bunch of "default" gateways assigned dynamically. You have addressed this by setting different default-route-distance values to the two l2tp-client interfaces, but it means that any routing strategy is effectively disabled because routing will choose the default route with lowest distance value unless it is unavailable. And if also your uplinks feed you with dynamic default routes, you need to configure the DHCP clients to assign even lower distances to them, so that the routes received from l2tp always win for the "tunnel payload".

Now unless you do something about it, the winning default route for generic traffic will be the same like for the "tunnel payload".

If you want different routes to be chosen for the tunnel payload and generic traffic, you'll need to use scripting to set routing marks to be checked to the various default routes, and you'll need to use firewall rules to assign routing marks to different kinds of traffic. Normally, I would give the uplink-provided default routes a high distance (low priority) and no routing mark, while the tunnel-provided default routes would have higher priority but would only be available to tunnel-payload packets which have been marked with a routing mark by firewall mangle rules based on destination address of the service due to which you undergo all this exercise.

However, as the dhcp client settings allow to attach a script to the address assignment event, l2tp client does not. So you have to invert the philosophy - you need to assign low distance (high priority) and routing mark to the uplink-provided default routes, and assign the same routing mark to the generic packets and no routing mark to the tunnel payload packets. This way, the uplink-provided routes become unavailable for the tunnel payload, so it will use those provided by l2tp.

And, finally, as you already do, you also have to provide the srcnat rules for the tunnel payload, as the l2tp VPN provider expects only packet with source address they have assigned to you.

Sindy, thank you for taking the time to write it all. It was very helpful and I appreciate it. Just a few things for clarification:

- I'm using 2 ISPs assigned to 2 WANs, however, ISP1 is primary as its a cable provider and ISP2 is wireless broadband which has limitation of 2Gb per month, thus ISP2 is a failover in the event ISP1 goes down as it happened in the past during major rain days.
- DHCP client for both WAN1 and WAN2 have their respective scripts which provide failover and found it to be most effective so far
- VPN tunnels are all outgoing from 1 LAN and 1 WAN (ISP1), thus having 2 tunnels on 1 WAN tunnel is where the issue is

I manage to run 2 tunnels at the same time, however, the issue was (as you mentioned in your answer) now I have 2 public IPs which create conflict in connectivity for basic tools like browser etc.
I was considering using nTH as Load Balancing as I thought it would be best way to do failover and LB at the same time, however, it also comes with its own issue which will require further investigation.

Meanwhile, I want to thank you for your time and explanation it was very helpful and hope somehow in the future i would be able to run a few ideas by you.