Exactly what I was afraid of. In your OP, you say:
but your configuration doesn’t match this:
In fact you have the 10.104.104.0/22 subnet attached only to bridge1; to ether7 and ether8, you have attached /32 “subnets” with unrelated /32 addresses of the gateways.
I suspect I understand the purpose, as you want the hosts in 10.104.104.0/22 to use Mikrotik’s own IP as their default gateway, and let the Mikrotik choose the “real” gateway out of 10.104.104.99 and 10.104.104.1 on its own. Which does work, but it also implies that the NAT must be done at the Tik, as without the NAT, the VPN router and the internet router would assume the other destinations within 10.104.104.0/22 to be in their own subnet, so instead of routing the responses via Tik’s IP as a gateway, they would send an ARP request to get a MAC address of the destination. Except if these two routers were configured symmetrically, i.e. if they had an equivalent of
/ip address add address=10.104.104.99/32 network=10.104.104.23
/ip route add dst-address=10.104.104.0/22 gateway=10.104.104.23
in their own configuration. But I assume the latter is not the case, as otherwise you wouldn’t need the NAT at Mikrotik side.
So what I write from now on assumes that the Tik-facing interfaces of the internet router and the VPN router are indeed configured with 10.104.104.99/22 and 10.104.104.1/22, respectively.
There are two ways how to adjust the Tik configuration alone to make things work without the need for a NAT rule on the Tik.
One is to keep just the single IP, 10.104.104.9/22, on the bridge, remove the two IP configurations attached to ether7 and ether8 completely, and make ether7 and ether8 member ports of the bridge as well.
This way, the first packet from the client towards each particular destination address will be sent to the Tik’s 10.104.104.9 (because that’s what the clients have got as a default gateway via manual config or DHCP); using its own routing table, the Tik will find out that the gateway IP for such packet is in the same subnet like the source IP of that packet, and will thus inform the sender via ICMP that it can send the packet directly to that gateway IP (.1 or .99). Most devices will understand this, make a note in their routing cache, and use the real gateway for that destination address (or rather the whole subnet matching the dst-address field of the route at Mikrotik) for some time until the note times out; then, the same cycle will repeat. So effectively, the routing table of Mikrotik will be dynamically replicated in the hosts’ routing caches.
The VPN router and internet router will both have a direct L2 path to the hosts, so no NAT will be necessary at the Tik (nor possible because the bulk of the packets will bypass the L3 handling at Tik and will be just bridged between ether1 and ether7/ether8). But this also means that the IP firewall of the Tik will not be able to affect that traffic; since you mention hotspot functionality, I suspect this method may not suit your intention.
So aside of forcing bridged traffic through the IP firewall, which is possible but unusual, another way to get rid of the NAT while keeping Mikrotik in the L3 path between the two routers and the clients connected to ether1 without modifying the settings of the two other routers is to keep your IP configuration at the Tik unchanged and just set arp-proxy to yes at ether7 and ether8. This way, the internet router and VPN router will get their ARP request for any IP address from 10.104.104.0/22 responded by the Tik with its own MAC address, so they will send the packets for anything from that subnet to the Tik, and Tik will forward these packets. In this case, Mikrotik will handle all packets at L3, but you still won’t need to do NAT at Tik to have the backward path from outside to any IP address in 10.104.104.0/22 working because the Tik will mimic the whole subnet towards the two routers.
