How to make a parallel "keepalive" backup of two VPN:EoIP over IPsec in one bridge on mikrotik with 2WAN?

Question

VPN

There is a central microtic with one WAN and a branch in which there are 2 WANs with real IP addresses.
1. In the branch, I set up and checked the automatic switching of Internet channels from different providers according to this instruction .
2. I made two incoming interfaces on the central one and, accordingly, two initiating ones on the client Mikrotik according to this instruction
. But the EoIP pair of interfaces on the client and server works only over one WAN Internet channel, i.e. when the first provider in the branch goes down, the second pair on the standby, according to the "keepalive" rule, does not initiate communication between offices.
local address, remote address, tunnel id, ipsec secret - were configured according to their pairs and rechecked several times.
Tell me how to "debug" routing at the moment of switching and why the second "reserve" pair does not work in such a scheme?

Answer 1

Oh mom. Are you sure you need such complexities?
For a branch, it is better to use the simplest solution of all. One has only to remember to add magic to the mangle so that the router responds to the outside through the interface through which the packet arrived, so that it would be possible to reach the router through both channels.
Next - EoIP - a thing needed in some situations, if you need stupid l3 connectivity between offices - l2tp / ipsec. Even in the piggy bank about EoIP - at one time there were problems with the fact that the interface seems to be active, but the traffic through it does not run exactly until the interface is distorted, people sculpted scripts for this. Now it seems like they fixed it, whether they will break it again - I don’t know.

Answer 2

Igor_kov , are you sure that you need it this way? First, you almost organized the ring. 2EoIP tunnels in 2 bridges, it's all the same to connect 2 simple switches, 2 patch cords. Saved you 2 things, 1) you did not get the second interface. 2) By default, Mikrotik has RSTP enabled on the bridge (if you haven't turned it off yourself). Further down the line, Mr. Poisonsabsolutely correctly sent you to read about switching channels without scripts. It just works. Next, I ask you, think again, do you need to combine offices over L2? Do you understand that all broadcast traffic will go to 2 offices at once?. And what will happen if tomorrow it will be necessary to add another branch?. It is more difficult to set up firewalls and so on to restrict access between offices. In the general case, if there are no applications and equipment, for the operation of which it is necessary that they be in the same broadcast domain. It makes no sense to combine offices on L2, please consider L3.
Now on the topic of how to debug: 1) Redo the channel switching as indicated above. Next, throw EoIP out of the bridges. To eliminate the influence of RSTP. Disable IPSEC. B to see if both tunnels are up with KeepAlive enabled. (see status should be R). You have already been written Above, most likely, the problem is that the router is a stupid animal, and sends its packets in accordance with the routing table. As a result, the following story is obtained, let the head office 3.3.3.3. The main provider in the branch 1.1.1.1 reserve - 2.2.2.2. The router is told to set up a tunnel between 3.3.3.3 and 2.2.2.2. The router does what it does: generates an EoIP packet, and sends it .... there according to the routing table. And who is our main pravider? 1.1.1.1 As a result, the request to establish a tunnel connection with 2.2.2.2-3.3.3.3 arrived through another channel 1.1.1.1. D In general, this is not what we wanted, but the tunnel would come up if not.... second problem: sends 3.3.3.3 a connection request to 2.2.2.2. Ok, the packet came, we did something with it and we answer ... attention in accordance with the routing table, where is it written what? if the 1st provider is working, answer with 1.1.1.1. As a result, the head office waits for a response from 2.2.2.2 to request a and receives a response from 1.1.1.1. And he throws it away. In total, you need to do roughly two things: 1) so that the router responds from the interface to which it received the request, 2) EoIP connections from the filial with 2.2.2.2-3.3.3.3 must still go through interface 2.2.2.2 :) This is all solved with using mangl'o magic. attention in accordance with the routing table where it says what? if the 1st provider is working, answer with 1.1.1.1. As a result, the head office waits for a response from 2.2.2.2 to request a and receives a response from 1.1.1.1. And he throws it away. In total, you need to do roughly two things: 1) so that the router responds from the interface to which it received the request, 2) EoIP connections from the filial with 2.2.2.2-3.3.3.3 must still go through interface 2.2.2.2 :) This is all solved with using mangl'o magic. attention in accordance with the routing table where it says what? if the 1st provider is working, answer with 1.1.1.1. As a result, the head office waits for a response from 2.2.2.2 to request a and receives a response from 1.1.1.1. And he throws it away. In total, you need to do roughly two things: 1) so that the router responds from the interface to which it received the request, 2) EoIP connections from the filial with 2.2.2.2-3.3.3.3 must still go through interface 2.2.2.2 :) This is all solved with using mangl'o magic.