This topic is actually a bundle.
So let's discuss the possible ways of interconnecting the sites first.
Research EOIP!
My recommendation is to use EoIP only where really necessary. It has its positives, and it has its negatives too - additional CPU load, fragmentation aspects, and some random surprises reported now and then that some never encounter and for others it makes EoIP unusable.
First, are the "CPEs" also Mikrotik ones? If yes, it has become possible some years ago to transport VLANs directly using Mikrotik wireless interface: you set up the wireless interface at one end with
mode=ap-bridge, the wireless interface at the other one with
mode=station-bridge, both with
bridge-mode=enabled, and you make each a member port of the bridge with
vlan-filtering=yes whose other member is the Ethernet interface of the "CPE".
This approach is the simplest one configuration-wise.
The only issue here is the degree of your paranoia. For the traffic which ends up in internet anyway, there is no need to care about security on the wireless link as the traffic may be intercepted anywhere else between your network and the remote server with less effort; for the local traffic between the two sites, you may be concerned about the WPA2 security vulnerabilities, and you may want to additionally cipher the traffic using IPsec, Wireguard, or OpenVPN. On RouterOS 6.x, Wireguard is not available and OpenVPN can only use TCP as transport, which makes it a bad choice for VoIP on a potentially lossy wireless link (and costs you some tiny bit of extra bandwidth even on a lossless one). Otherwise, OpenVPN would be the ideal choice as it supports L2 tunneling directly. On ROS 6.x, it was not possible to combine
vlan-filtering=yes with PPP-based L2 tunnels like the OpenVPN one, though - I don't know whether this will change in ROS 7). IPsec and Wireguard are L3 only, so you have to use EoIP together with these to obtain L2 transparency.
So if security of the inter-site traffic is a concern, or if the radios are not Mikrotik ones and do not support VLAN transparency, you have to consider EoIP (over IPsec).
Regarding the WAN failover, there are other topics on the same (two sites, each with an own internet connection, interconnected using a local link).
In general, you can create one VLAN/subnet solely for the WAN sharing purpose (let's call it WAN-VLAN), and some simple routing related to it. Monitoring of primary WANs' transparency all the way to internet is a local job of each router (see the scriptless WAN failover by @Chupaka and others). Src-nat or masquerade would be done only on the "real" WANs.
For Site L to use Site R's WAN as a backup one, Site L has a preferred default route via its primary WAN, and a backup default route with Site R's IP addres in the WAN-VLAN subnet as a gateway.
As long as LANs on Site L and Site R do not share any IP subnets, Site R has routes to all Site L's subnets via Site L's IP address in the WAN-VLAN subnet. For site R to use Site L's WAN as a backup one, you add a mirrored configuration.
The point you may want to address is that the traffic would not loop between the sites if both "real" WANs are down, as this could exhaust the CPU or the bandwidth of the link between the sites, so local traffic would be affected. If that is an issue, you don't even need policy routing (using a specific routing table depending on the source address of a packet), firewall rules are enough to prevent traffic from looping - a packet which arrives from Site L cannot be sent back to Site L at Site R and vice versa. So dropping packets whose both
in-interface and
out-interface is the "WAN-VLAN" is enough to deal with this.
The most complicated thing to address is if you have a VLAN & subnet spawning both sites, devices in this subnet on each site should prefer the local WAN, and you want these devices to use DHCP. If this is your case, the easiest solution would be to prevent DHCPDISCOVER packets in these VLANs from delivery across the inter-site link by means of
/interface bridge filter rules; unfortunately, these rules currently do not allow to inspect L3&L4 fields of packets carried by VLAN-tagged frames. So if you need this for more than one VLAN, it requires quite a complex setup with multiple bridges at at least one of the sites.
