hint000

Потому что download не может работать совсем без ответов от вашего mikrotik - вам приходят пакеты с контентом и вы должны отвечать подтверждением, что эти пакеты получены. Если такого подтверждения нет в течение некоторого времени, то отправляющая сторона может приостановить отправку (зачем зря отправлять, если никто не получает?)

например на download у меня скорость 100 Mbps, на upload скорость 10 Mbps

Например, отправка подтверждений занимает 0.1 Mbps при download на 100 Mbps.
Например, upload забивает канал на 99.99%, т.е. от 10 Mbps остаётся свободно 0.001 Mbps, тогда удаётся отправлять подтверждения в 100 раз реже, чем при свободном канале upload, в результате скорость download падает в 100 раз.

Считаю, что так не должно быть

Ограничивайте (на уровне приложения) скорость отдачи, чтобы канал не забивался полностью. Вероятно, занятие 99% от пропускной способности upload уже позволит нормально качать в обе стороны (если нет, то можно ещё убавить, до 98% или до 95% - экспериментируйте).
Для полноценного Linux можно нагуглить твик, устанавливающий подобное ограничение на уровне операционной системы. Но не уверен, что для mikrotik подобный твик существует (впрочем, погуглите что-нибудь вроде mikrotik traffic shaping).

https://www.expressvpn.com/ru/support/troubleshoot... - Как отключить DNS по HTTPS в веб-браузере
(либо загуглить эту же фразу)

Как настроить маршрутизацию чтобы из vlan20 пинговался шлюз ISP2?

Это не вопрос маршрутизации. Для этого придётся Eth2 и Eth3 собрать в бридж и сделать Eth2 нетегированным участником vlan20.

Если по условиям задачи (мы же их не знаем...) Eth2 и Eth3 нельзя объединять в бридж, то не следует и назначать адреса из одной сети для ISP2 (на схеме IPS2) и для vlan20.

Минимальное изменение схемы - это уменьшить 10.10.10.0/24 до 10.10.10.128/25 (пул DHCP тоже уменьшить);
на Eth3 назначить 10.10.10.129 и объявить его шлюзом внутри 10.10.10.128/25;
на Eth2 назначить 10.10.10.2; тогда всё будет естественным образом, без бриджа.

Файервол не пускает?
/ip firewall filter export

пример 192.168.0.98:9003

на 192.168.0.98 кто-то слушает порт 9003? из локальной сети на 192.168.0.98:9003 удаётся подключиться?
на 192.168.0.98 нет файервола, который блокирует доступ из внешнего мира (например, на виндовых машинах блокируется по умолчанию)?

Как сделать, чтобы все пакеты не попадали в какое то узкое горлышко

Попробуйте копать в эту сторону: https://yandex.ru/search/?text=mikrotik+fasttrack

Дык а вы проверяли, что они сейчас не видят друг друга?
По-моему, у Mikrotik'а хватает ума в таких простых случаях автоматически создавать маршруты, не требуя ручной настройки.

И если таки не видят, то смотрите, является ли Mikrotik шлюзом для тех хостов, на которых проверяете.

Тот же вопрос 8 лет назад:
https://www.linux.org.ru/forum/admin/11122759

Суть проблемы, отсутствие nmap в Mikrotik

:

В метароутер можно поcтавить openwrt, туда в свою очередь поставить nmap и пробовать.

Понимаю, что зело костыльно, подписался, чтобы увидеть более изящное решение.

Как МТ1 может передавать информацию МТ2, о том, чьи пакеты кому принадлежат

Он это делает по-умолчанию, если не задействовать SNAT\маскарадинг на МТ1. Какой адрес был у ПК1, с тем адресом источника и придёт пакет на МТ2. От вас требуется только правильно указать маршруты.

Сначала совет. Чтобы не создавать путаницу, надо сначала настроить всю маршрутизацию; проверить, что действительно никаких косяков с маршрутизацией не осталось; после этого переходить к настройке NAT.

Теперь по существу.

add action=masquerade chain=srcnat dst-address-list=CamsS out-interface=\
L2tpS

А что у нас входит в CamsS?
172.16.110.2 туда входит? Ведь мы пробросили порт именно на 172.16.110.2. Другой вопрос, а зачем нужно пробрасывать порт на двух роутерах, если можно пробросить только на одном? Сразу на адрес регистратора.
Вот вам и два варианта исправления на выбор.

Начать с того, что вытащить из мусорного ведра Dlink DIR-300 или что-нибудь подобное и железобетонно проверить, что проблема в Mikrotik'е. Вот пускаем через другой роутер и проблема исчезает, а вот пускаем через Mikrotik, и проблема снова появляется.

сайт нормально работает на Linux дистрибутиве ThinStation

Разница, например, в том, что на винде TTL исходящего пакета 64, а на Линуксе 128. Т.е. теоретически может быть какая-то сетевая аномалия, приводящая к очень длинному маршруту, на грани 64 хопов (трассировку делали?), и длина маршрута почему-то плавает больше-меньше (не спрашивайте почему такое может быть), а Линуксу при этом пофиг. Но убейте меня - нет идей, что такое происходит, что винда своими пакетами может ломать связь Линуксу.

URL проблемного сайта - секрет?

Посоветуйте пожалуйста куда копать

Копайте в сторону конфликта IP-адресов (выдаваемых по DHCP).
Например, когда 192.168.1.100 перестанет пинговать шлюз, то попробуйте со шлюза пинговать 192.168.1.100.
И с разных других компьютеров пинговать 192.168.1.100.
И если такой пинг пройдёт, то отключите (физически) 192.168.1.100 от сети и снова проверьте пинги до него с разных компов.
Вдруг обнаружите, что кто-то по этому адресу отвечает, даже когда комп отключен от сети.