99% of the time, you should be using a routed (TUN) tunnel, NOT a bridged (TAP) tunnel. And that's because you typically are connecting to another site you either don't control and fully trust, or perhaps you do, but it's impractical to deal w/ having the same IP network on each side. You now need to make sure you don't duplicate IP assignments. A routed tunnel is much easier to manage if you need to filter out access. You just define appropriate IP rules on each side.
Of course, the problem for me at this point is we have ZERO knowledge of the big picture here. I was just trying to think a bit outside the box here in case a bridged tunnel *might* be easier. But again, I have NO CLUE of the purpose of the tunnel, the parties involved, etc. It could be utterly impractical for many reasons. But in a vacuum of information, it's at least worth mentioning.
Years ago I owned two homes, each of which was managing its own private IP network (e.g., 192.168.99.0/24 and 10.0.10.0/24). It wasn't practical for me to manage the two sides using the same IP network and a bridged tunnel, so I used a site-to-site routed tunnel. But there were times where having a bridged tunnel was still useful. I was using FT (FreshTomato) at the time, so I created a new bridge w/ single port VLAN + VAP (virtual AP) that managed a bridged (TAP) tunnel to the other home. Anytime I connected a device to that wired port or VAP, it effectively became part of the remote IP network, as if it was actually connected directly to its switch/AP. Yet the rest of the network had access to the other over the routed (TUN) tunnel.
IOW, I could *selectively* places devices on the bridged (TAP) tunnel as needed. Those devices could still access their own local private network, but it would be *remotely* via the routed tunnel on the other side!! As I said, those devices behaved exactly as if they were *physically* located on the other network.
Problem w/ ASUS firmware (stock or Merlin) is it doesn't natively support user-defined VLANs, bridges, etc. For all practical purposes, you'd have to use additional routers and daisy-chained them behind their respective primary routers to manage that OpenVPN bridged tunnel, ideally using something that *does* offer those features.
But again, all these ideas may be impractical in certain circumstances.
The problem I see w/ your current approach is that you have a bridged tunnel that still requires routing. That sort of defeats the purpose. You'd have to multihome the primary router on each side w/ the other's IP network, so the traffic could be routed between them, except it would be over the same logical ethernet network. Again, sort of defeats the purpose since you still end up being routed wrt each other. But at least ethernet (layer 2) broadcasts (if NOT IP broadcasts) would be accessible between each side. But mDNS is a layer 3 (IP) broadcast, so you end up right back where you started, basically needing something like the Avahi replicator.