If you have really restored a backup rather than imported an export, you have cloned also the MAC addresses, so this is the first point to clarify.

Well, I did that. Export the Master backup, restore that backup using import from PC. Both RBs show their respective MAC addresses at Winbox.

I know that the gateway may be the problem. The VRRP is x.x.x.3.
I am using RB Master (which is x.x.x.1) as DNS and Webproxy servers. Both RBs have x.x.x.1 as gateways. Should I use x.x.x.x.3?

If so, how can I bond the DNS and Webproxy seemlessly?

Can we use DHCP Relay as x.x.x.3 so VRRP works properly without distressing the static clients?

If previous is not possible, do we also have to delete the ClientIDs at Leases so VRRP can identify the devices?

You can do either an import of .rsc file (which is a plaintext script) or a restore of .backup file (which is a compressed and ciphered binary file).
If you did the latter and it didn't rewrite MAC addresses, something must have changed in the way how the restore is done.

I am lost. The idea of VRRP is that the addresses used by external devices are the virtual ones. So the two Mikrotiks using VRRP to backup each other should have their physical addresses e.g. like .253 and .254, and the virtual one should be .1. Or you have to configure the hosts (or the DHCP server) to have .3 as gateway and DNS.

You can use the virtual address as gateway for the other devices as a gateway is stateless. DNS is halfway to stateless - if the primary Tik stops responding and the DNS requests start coming to the secondary one, its cache will be empty so some DNS requests regarding records cached by the primary one will be forwarded to upstream server, but the client won't notice anything but slightly higher response time. But DHCP is completely stateful, so unless you'd find a way to synchronize the leases granted by the primary to the secondary (I don't know any such way), the clients may get different addresses from the secondary than which they got from the primary.

I don't use webproxy but I'd say it is similar to DNS behaviour; however, as you have different internet connection with a different public IP, existing connections will be broken and will have to be re-established by the client.

As said above. DNS works the same from the perspective of the client regardless on which Tik the virtual IP is currently up. Webproxy will work the same but existing TCP sessions will break when VRRP moves the virtual IP.

If you mean a DHCP relay from these Tiks to some external DHCP server, then it doesn't matter which of the Tiks forwards the client's requests. But it just moves the issue one floor higher - if that server dies, you're left without the DHCP service. So for full redundancy, you need two DHCP servers which synchronize the leases.

VRRP does not know anything about DHCP or the external devices' IDs. It just moves the virtual addresses among the VRRP group members. If the virtual address migrates, the virtual MAC address migrates too, so the external devices do not notice a change. The VRRP group member which become active will have to use ARP to determine MAC addresses of those external devices but that's also nothing worth worrying.

I managed to make my PC hold connection but not in my table or cellphone.

I managed to make my PC hold connection but not in my table or cellphone.

Now wait. What means "hold connection", and what means "table" - a VoIP phone or a desktop PC? If the cellphone is connected using wireless as I suppose, there is not just the DHCP and gateway part, there is also the wireless authentication which cannot be inherited from one AP to another. So describe each case separately, and detail what means to "hold connection".

I meant with "hold connection" to be able to surf without problems (within 3-5 seconds after unplugging the Master MK) straight internet access.

I'm using my router with wireless DumbAP so clients go straight to MK.

OK, so not in the sense that you wouldn't have to re-establish the TCP connections.

So both the tablet and the mobile phone are connected to a wireless AP which just "translates wireless to Ethernet", but already the DHCP is running on the Tik. And there is a switch between the AP and the two Tiks so if one Tik is down the AP can still talk to the other one, correct?

Do the tablet and mobile phone have static leases reserved or do they get dynamic addresses? How long does it take them to recover, if they do at all? The point is that the client knows the IP of the server which has granted them the lease, and when it expires, the client first tries to renew it with that server before resorting to broadcasting again.

And, last point, have you changed the gateway and dns-server items in /dhcp server network to the virtual IP?

What I can see is that you now only deal with the static leases (as the parameter address-pool of /ip dhcp-server is set to the default value static-only), so the fact that the pools for dynamic leases are the same at both routers does not cause any trouble now.

But I can see that on the 450, the default gateway assigned to the DHCP clients is the physical 10.0.50.1, which means that the client devices lose it once that router goes down. On the 750, it is properly set to the virtual address 10.0.50.3. So set it to 10.0.50.3 also on the 450 under /ip dhcp-server network, enable the 450, wait until the DHCP client devices renew their leases while the 450 is enabled, and then disable/disconnect the 450 again. The mobile devices should continue to work normally, like the PC. Is my guess correct that you have set the IP configuration statically on the PC, with default gateway set to 10.0.50.3, whereas the tablet and phone get the gateway address via DHCP?

Off topic, what subject do you teach?

The problem was that some devices renewed on the 450 (even though this last one was disconnected) and some others on the 750. Even waiting for the leases to be renown. That was a mess. I didn't understand why some devices kept waiting for the 450 and not liking to the then active 750.

Attach the DHCP servers at both machines to the VRRP interface rather than the "physical" interface. The client remembers the IP address of the DHCP server from which it got the lease so it asks it for renewal using DHCPREQUEST to its individual (unicast) address before reverting to broadcasting a DHCPDISCOVER. And it may take a different time with different client implementations before the client gives up trying with the previous server and starts broadcasting again. If you attach the DHCP servers to the VRRP interfaces, only the DHCP server attached to the currently active VRRP interface will be active, but it will inherit the virtual IP address from the VRRP interface so the clients will get the virtual address not only as the default-gateway and dns-server one but also as the leasing-server one. It is still valid that the pools should not overlap to avoid conflicting addresses to be assigned.

I did everything suggested but it is not working properly. Some routers (Openwrt) receive their leases fine but the following happens. I can ping them a few seconds after the Tik reboots but I get timeouts after a few seconds of receiving the lease. Openwrt receive default VRRP gateway and DNS fine. I can even ping from within the Openwrt to check internet and works fine but I am totally confused about this behavior.

Offtopic: From the given config that I posted a few posts before, what things do you see I can improve or polish?

• stop using PPTP - it provides no actual security and no known advantage as compared to L2TP, except that recent updates of Windows 10 have broken L2TP/IPsec functionality whilst PPTP seems tto have survived
• to post configurations, place them between [code] and [/code] tags directly to the post; if you upload them as files, use plain text format, not .doc or .docx as there are no attributes of the text for whose transport you'd need the extra capabilities of these formats, and most people with basic awareness of network security do not download files in these formats from unknown sources as they have a history of being used to convey malware
• it is useless to create a static dhcp lease for the virtual VRRP address - should not be harmful though
• it is a bad idea to have overlapping IP address pools (the one for dhcp and the one for ppp clients), I'm not sure how the machine coordinates leases from different pools
• it is better not to assign to PPP clients addresses from local LAN subnets as it makes it necessary to activate arp-proxy on the LAN interfaces from these subnets, and arp-proxy is not selective (you cannot say which for which destination connected subnets it should work and for which it should not)
• I personally prefer firewalls which drop everything except what you selectively permit to firewalls which permit everything what you selectively drop. If you forget to permit anything, your legal users will come to complain quickly; if you forget to drop something, your illegal users will never complain
• check the idea of a stateful firewall - it allows you to only carefully inspect the first packet of each new connection, the second and further packets of connections whose first packets you've let through will be handled by a single rule (action=accept connection-state=established,related) at the top of each chain, lowering the CPU consumption on firewalling. This may not be exactly true where connection tracking (which is the key element of a stateful firewall) is not activated, as connection-tracking itself is quite CPU-intensive, but whenever you use NAT, connection tracking gets activated anyway so no point in ignoring it in filter
• there is no need to specify to-ports in action=dst-nat rules if the to-ports value equals the dst-port value - but it's not harmful
• if you ever start using ssh, only use allow-none-crypto=yes if really necessary (which means never unless you're the guy who asked for it to be implemented) an use strong-crypto=yes
• only enable upnp if you really cannot live without it as it is a security disaster
• tidy up after tests - /ipv6 route add distance=1 gateway=*5 shows that there used to be some interface which you've removed later (supposedly a 6to4 one)

... arp-proxy is not selective (you cannot say which for which destination connected subnets it should work and for which it should not)

/ip arp
add address=192.168.10.254 interface=bridge published=yes

• stop using PPTP - it provides no actual security and no known advantage as compared to L2TP, except that recent updates of Windows 10 have broken L2TP/IPsec functionality whilst PPTP seems tto have survived

[*]to post configurations, place them between [code] and [/code] tags directly to the post; if you upload them as files, use plain text format, not .doc or .docx as there are no attributes of the text for whose transport you'd need the extra capabilities of these formats, and most people with basic awareness of network security do not download files in these formats from unknown sources as they have a history of being used to convey malware

[*]it is useless to create a static dhcp lease for the virtual VRRP address - should not be harmful though

[*]it is a bad idea to have overlapping IP address pools (the one for dhcp and the one for ppp clients), I'm not sure how the machine coordinates leases from different pools

[*]it is better not to assign to PPP clients addresses from local LAN subnets as it makes it necessary to activate arp-proxy on the LAN interfaces from these subnets, and arp-proxy is not selective (you cannot say which for which destination connected subnets it should work and for which it should not)

[*]I personally prefer firewalls which drop everything except what you selectively permit to firewalls which permit everything what you selectively drop. If you forget to permit anything, your legal users will come to complain quickly; if you forget to drop something, your illegal users will never complain

[*]check the idea of a stateful firewall - it allows you to only carefully inspect the first packet of each new connection, the second and further packets of connections whose first packets you've let through will be handled by a single rule (action=accept connection-state=established,related) at the top of each chain, lowering the CPU consumption on firewalling. This may not be exactly true where connection tracking (which is the key element of a stateful firewall) is not activated, as connection-tracking itself is quite CPU-intensive, but whenever you use NAT, connection tracking gets activated anyway so no point in ignoring it in filter

[*]there is no need to specify to-ports in action=dst-nat rules if the to-ports value equals the dst-port value - but it's not harmful

[*]if you ever start using ssh, only use allow-none-crypto=yes if really necessary (which means never unless you're the guy who asked for it to be implemented) an use strong-crypto=yes

[*]only enable upnp if you really cannot live without it as it is a security disaster

[*]tidy up after tests - /ipv6 route add distance=1 gateway=*5 shows that there used to be some interface which you've removed later (supposedly a 6to4 one)[/list]

[*]it is a bad idea to have overlapping IP address pools (the one for dhcp and the one for ppp clients), I'm not sure how the machine coordinates leases from different pools

I had to do it in order to "see" my routers. Also, I had to activate Proxy-Arp in LAN.

[*]it is better not to assign to PPP clients addresses from local LAN subnets as it makes it necessary to activate arp-proxy on the LAN interfaces from these subnets, and arp-proxy is not selective (you cannot say which for which destination connected subnets it should work and for which it should not)

Is there another simple way rather than using p-arp? Let's say, I want 10.50.10.x (LAN) pool to communicate to 10.50.15.x (VPN) but couldn't figure it out.

[*]I personally prefer firewalls which drop everything except what you selectively permit to firewalls which permit everything what you selectively drop. If you forget to permit anything, your legal users will come to complain quickly; if you forget to drop something, your illegal users will never complain

Not sure what to do here.

[*]check the idea of a stateful firewall - it allows you to only carefully inspect the first packet of each new connection, the second and further packets of connections whose first packets you've let through will be handled by a single rule (action=accept connection-state=established,related) at the top of each chain, lowering the CPU consumption on firewalling. This may not be exactly true where connection tracking (which is the key element of a stateful firewall) is not activated, as connection-tracking itself is quite CPU-intensive, but whenever you use NAT, connection tracking gets activated anyway so no point in ignoring it in filter

I need to understand this later. Not clear to my actual knowledge.