Good afternoon
I would like to know if this is possible. It turns out that I have two Mikrotik one (Client) and the other (Server). In the Mikrotik client I have two connections (ISP) to the internet Route 1 and Route 2. The Mikrotik client communicates through VPN (Client) always using route 1. I would like to create another VPN client that uses route 2 and communicates with the same Mikrotik Server. Is this possible? Thanks for any information.
Sure it is…
Just route your VPN client through the ISP you need using either Routing Rules or Mangles Facility…
It is possible in principle but not exactly straightforward. First, what VPN type do you use? Also, why do you expect the server side internet connectivity to be so much more reliable than the client side connectivity that you consider a failover solution only at the client side?
Thank you for the answer. Actually I have 3 routes in the Mikrotik client. The main route is by cable modem, route 2 is by antenna (WISP) and route 3 is by LTE with a plan of 1GB per month. The idea of being able to specify that one of the VPN (L2TP with IPSEC) connections go through route 3 is in a special case that the failover made by the Mikrotik client through route 2 fails, either because the connection through the antenna (WISP) does not work or something happened with the failover. In this way I would have a way to get to Mikrotik by route 3. This Mikrotik client connection is important since it is a second house that I own in another state and I have a security system in it. The Mikrotik connection (Server) is in the residence where I am most of the time and in this connection I have a fiber connection.
Thanks with any idea
First a remark regarding the LTE part - both L2TP and IPsec send quite a lot of keepalive traffic even when no payload is transported, so you might find 1 GB per month insufficient if the VPN was constantly up. You can set dial-on-demand to yes but it only makes sense if the payload connection is always initiated from the client side.
Second, the answer to the topic title.
To allow multiple VPN connections towards the same server to run simultaneously and use different WANs, you have to set the src-address parameters of each of the individual /interface l2tp-client rows to one of the WAN IPs if the WAN IPs are static; if they are not, you have to create an /interface bridge with no member ports and attach to it several private /32 addresses not conflicting with any subnet you use, and use these as src-address values. Let’s use a.a.a.a and b.b.b.b as an example.
The thing is that if no src-address is specified, the route to the destination is found first in routing table main (which is used if no routing-mark is assigned to the packet), and the address assigned to the gateway interface of that route is used as a source one for the packet. Since there is just one route to the server in this routing table, all your connections would go through the same WAN.
Next, you have to create a default route via a proper gateway for each WAN, with routing-mark=via-. If the WAN IPs are dynamic, you’ll need also action=masquerade rules in chain srcnat of /ip firewall nat, to change the source address from the private one to the one currently assigned to that WAN interface.
And lastly, you set up rows in /ip route rule:
src-address=a.a.a.a action=lookup-only-in-table table=via-WAN1
src-address=b.b.b.b action=lookup-only-in-table table=via-WAN2
These will make sure that the proper routing table, and therefore WAN interface, will be used depending on the src-address set for the individual /interface l2tp-client row.
To let the payload traffic choose one of the VPN tunnels by priority, you add static routes, one per each L2TP interface, with same dst-address and different distance values. When one of the tunnels goes down, the route via that interface will become inactive and the one with lowest distance value will be chosen among those that remain active.
Or you may just set multiple routes, each via a different WAN, with dst-address=ip.of.the.server, and let a single VPN connection re-establish via another WAN if the currently used one fails, but such a way adds some headache if combined with src-nat or masquerade.
Thanks for the good explanation. I’ll will tried to implement it that way.
When one of the tunnels goes down, the route via that interface will become inactive and the one with lowest distance value will be chosen among those that remain active.
Or he cant just use lookup instead of lookup only in table, so if the WAN in the Route Rules specified for that source address is down, it will go through the main routing Table, whatever that is…
What you suggest would definitely be useful as a generic failover solution, but here in particular the idea is that each of the VPN tunnels is hardlinked to exactly one WAN.
When one of the tunnels goes down, the route via that interface will become inactive and the one with lowest distance value will be chosen among those that remain active.
my answer was according to your responce above…
Since we only have two WAN interfaces here, if one goes down, only one will remain active…
So just using lookup, in case the prefered WAN specified in the lookup Table is down, only one remains active and that would be the main one…
Ofcorse we can specify routes with different distances for the same destination address and Routing Mark, so that we can apply failover, but as a choice, in this example, using just lookup would have the same result…
Maybe I wasn’t clear enough in describing my concept.
Consider three categories of traffic:
- the VPN transport packets sent/received by the router itself towards the remote VPN server
- the VPN payload - the traffic between both sites’ LANs
- any other traffic
My understanding of the topic title was that the OP wants to stick the VPN transport packets belonging to each VPN connection to a particular WAN, be it dead or alive. If the WAN dies, the VPN connection via that WAN dies as well. For this, the src-address and /ip route rule rows with action=lookup-only-in-table are used.
If you don’t stick each VPN connection to a single WAN this way, and if there is masquerade at the primary WAN, the single L2TP/IPsec connection that should be using the primary WAN gets re-established via the secondary one if the primary one dies. But it will then stay on the secondary one even if the primary one recovers - unless you take additional measures to force it back. And if you do take these additional measures, there is basically no need to use multiple VPN tunnels - a single tunnel failing over between WANs is also a plausible approach. But again, the topic title explicitly asks for two VPNs. The advantage of the multi-VPN approach is that you can get faster failover times by checking transparency of the VPN tunnels using your own scripted tools and disabling the routes based on the results rather than waiting for the VPN keepalives to detect the failure and shutdown the virtual interfaces. Or you can use the BFD monitoring along with OSPF instead of scripts. Either way, the price to pay for the faster failover is higher volume of overhead traffic.
Further considering only the case with one VPN tunnel per WAN, the VPN payload packets are routed using routes in routing table main, one route per VPN tunnel, prioritized using distance, but also disabled by a script, or controlled using OSPF.
The rest of the traffic (router’s own traffic other than the VPN transport one, and traffic of LAN devices towards other destination than the other site’s LAN) is not considered here at all.
Thanks for all the information, now I have one VPN using a specific route, the way I was looking for. Thanks