Thu May 13, 2021 10:50 pm
You can set multiple VRRP interfaces with different virtual IPs on the same group of physical interfaces, you just have to use a different VRRP ID for each of them (exceptions exist but better avoid using the same one).
To synchronize the state of VRRP running on different physical interfaces in order that the same router was always active in all VRRP groups, you have to use the on-master and on-backup scripts in the configuration of one of the VRRP interfaces you choose as the controlling one on one of the routers, which will change the priority value of all the other VRRP interfaces depending on the state of the controlling one.
So at router B, all VRRP interfaces have priority 50; at router A, all VRRP interfaces have priority 100, so when both routers are alive, A is the master in all VRRP groups. On B, the on-master script on the controlling VRRP interface sets the priority of all other VRRP interfaces to 150, and the on-backup script sets it back to 50. So whenever the physical interface to which the controlling one is attached goes down at router A, and thus the controlling one goes to master mode on router B, the other ones at router B go to master mode too thanks to the change of priority. Once the physical port at router A goes up again, the controlling VRRP interface at B gets back to backup mode (because its own priority hasn't been changed by the on-master script), and in a few seconds the other interfaces return to backup mode too as the on-backup script lowers their priority.
Not knowing the details of your WAN environment, there is a small risk - the choice of VRRP MAC addresses is very limited, so you could get into conflict with other clients in the same L2 segment if they had the same idea and you didn't coordinate the used VRRP IDs with them.
dst-nat will work, but as the tracked connections are not synchronized between the physical routers in RouterOS 6.x, after a takeover, some connections will fail as the first packet to come will be from the LAN side, so it may get a different port on WAN side than the one which is port-forwarded by the dst-nat rule. If you have to change the port number in the port forwarding rules, you must use symmetric src-nat rules to mitigate this issue.
Example:
chain=dstnat protocol=tcp dst-address=the.wan.ip.1 dst-port=443 action=dst-nat to-ports=44443 to-addresses=192.168.1.1
requires
chain=srcnat protocol=tcp src-address=192.168.1.1 src-port=44443 action=srcnat to-addresses=the.wan.ip.1 to-ports=443
If you have loose-tcp-tracking under /ip firewall connection tracking set to no, the above will not help as mid-session packets (SYN flag not set) will not be allowed by the firewall anyway.