what exactly this does?
is that like load balancing or like redundant options?
It’s indeed redundancy. If configured this way, the initiator peer establishes Phase 1 towards two responder peers, but only establishes Phase 2 to one of them at a time. The responder peers both act as gateways towards the subnets accessible via the initiator, using VRRP or using some dynamic routing protocol to advertise themselves. There is no readily available interworking between the IPsec stack and the VRRP/dynamic routing, so the easiest way is that both the two responders have static routes to send the traffic for the initiator’s subnets to each other and the IPsec policies are generated dynamically from templates on them. So on the responder currently chosen for Phase 2 by the initiator, the policies get created and “override” those static routes, whereas the other responder forwards the traffic for the initiator subnets to the “lucky” one thanks to those static routes if it receives it.
There is no automatic fallback - if both responders are available right after startup, the initiator sets up Phase 2 with the first one, but later on, if the currently used responder becomes unreachable/unresponsive, the initiator establishes the Phase 2 with the other one and keeps using it even if the first one becomes reachable again. If you don’t like that, you have to use a script to enforce the fallback.
Hello,
I have basically 0 experience with scripting in Mikrotik. how do i setup a script for automatic fallback? or at least to enforce it? is it ok to make a script that disable - enable the ipsec policy?
Thanks in advance
If the goal is to force the traffic back to the primary path, I would rather temporarily disable just the backup peer than the whole policy. And, if you want to do what you can to prevent surprises, you should use a scheduler item with start-time=startup to enable the backup peer - just for the unlikely case when the router will lose power or crash after your script will have disabled the peer but before the delay for re-enabling will expire. You will also need the scheduler to spawn the monitoring of the peer & policy state periodically, as unlike some other parts of RouterOS, the IPsec stack isn't equipped with any event handling interface (where you could associate a script to a state change, as can be done for the PPP or DHCP stuff).