Если у вас не только в prerouting стоят первые 4 правила, но и в таблице маршрутизации созданы routing mark соответствующие, то картина ничем не отличается от одного аплинка. Эти правила как раз и обеспечивают ответ на входящее соединение именно на тот канал, откуда запрос пришёл.
Я для удобства в nat завёл цепочку port_forward, в которую перебрасывал пакеты по правилам in-interface=ether2 и in-interface=ether3. А в этой цепочке уже обычный форвардинг без привязки к реальному интерфейсу.
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether3-gw0
add action=masquerade chain=srcnat out-interface=ether4-gw1
add action=jump chain=dstnat in-interface=ether3-gw0 jump-target=port_forwarding_udp protocol=udp
add action=jump chain=dstnat in-interface=ether4-gw1 jump-target=port_forwarding_udp protocol=udp
add action=jump chain=dstnat in-interface=ether3-gw0 jump-target=port_forwarding_tcp protocol=tcp
add action=jump chain=dstnat in-interface=ether4-gw1 jump-target=port_forwarding_tcp protocol=tcp
add action=dst-nat chain=port_forwarding_udp dst-port=6891 protocol=udp to-addresses=192.168.5.20
add action=dst-nat chain=port_forwarding_tcp dst-port=80 protocol=tcp to-addresses=192.168.7.10
Если с какого-то аплинка порт остаётся закрыт, попробуйте попинговать сам роутер. Если пингов нет на том же самом провайдере - разбирайтесь с routing-mark. Я не раскурил в своё время, как работает эта магия с check-gateway 8.8.8.8.
