Ziptar

https://wiki.mikrotik.com/wiki/Manual:IP/SMB

Собственно, последняя версия 6.45.9 (long term) / 6.47 (stable). 6.45.6, на сколько я понимаю, для скачивания недоступна, поэтому not found. А вот почему он последнюю версию не видит - вопрос (хотя по-моему они там что-то химичили на эту тему в районе 6.45, так что при попытке обновиться с 6.43.8 вполне может быть затык; но это не точно)
БТВ, вам уже рассказали как через винбокс прошивку залить.

Попробуйте так: объедините в бридж два интерфейса - на который приходит кабель провайдера, и который с микрота уходит на voip-шлюз; на микроте pppoe-подключение устанавливаете с бриджа, на шлюзе как обычно.

UPD: а, простите, не увидел, что в комментах к соседнему ответу уже разобрались со всем.

Фильтровать multicast и broadcast можно отключив в параметрах портов бриджа соответсвующие опции. Если именно следить - только сниффером, на сколько я знаю. Ну или через mangle, но... хм.

https://www.v13.gr/blog/?p=386
В разделе The "bug" есть подробности почему нужна определенная комбинация. Тем не менее, статья могла устареть, т.к. с тех пор сменилось несколько версий openvpn.
Что касается самих по себе key usage - это больше административная история, нежели техническая. Можно стандарт соблюдать, а можно не очень. Можно даже произвольные OID'ы создавать и использовать.

Исходя из конфига, на который дана ссылка в комментариях к посту, могу сказать следующее:
Переделывайте правила mangle. Они у нас просто напросто не работают. Вы пытаетесь ловить транзитный трафик на input цепочке - это бессмысленно. dst-nat трафик, если он не заворачивается на локальный айпишник микрота, в input цепочку не попадает. Это транзитный трафик, он у вас должен уйти на forward цепочку. При этом ловить вы его можете на форварде, но когда он уже пойдёт в обратную сторону, поскольку маршрут определяется сразу после prerouting цепочки, до попадания в forward или input. Ознакомьтесь с packet flow диаграмами, включая routing diagram и packet flow chains.
В итоге, по всей вероятности, микрот ответы от сервера попросту маршрутизирует не туда, куда вы ожидаете, согласно main routing table.

https://habr.com/ru/post/244385/
Я PCC использую, но есть неколько "но" и граблей, по которым вам придётся пройтись самостоятельно, в зависимости от потребностей.

как их адаптировать их на резервирование при использовании pppoe (основной провайдер) и dynamic ip (запасной провайдер)

Возможно, придётся написать скрипт на динамическое переписывание маршрута для второго провайдера, если там шлюз меняется.

По поводу первого - policy base routing. В mangle лезть в таком простом случае не требуется.
По поводу второго - смотрите в первую очередь правила фаервола, и учитывайте, что на dst-nat применяется до фильтра, то есть правила фильтра должны применяться на цепочке forward. Это при условии, разумеется, что правила nat настроены верно.

Вопрс первый:

virtual wlan

Вопрос второй:

Это зона ответсвенности RADIUS-сервера, не микротика и не базы данных.

На клиентах нужно так или иначе прописывать маршрут к ресурсам сети через vpn.

Как пример:
Ресурсы удалённой сети лежат в подсети 192.168.0.0/24
Конечная точка vpn со стороны сервера у вас имеет адрес 192.168.1.1
Конечная точка vpn со стороны клиента у вас имеет дрес вида 192.168.1.x/32
Вам нужно так или иначе показать клиенту маршрут к 192.168.0.0/24 через 192.168.1.1. Учтите, что если у клиента домашняя подстеть так же 192.168.0.0/24 - так или иначе будут проблемы, даже если частично что-то будет работать.

Если речь идёт о роутере с RouterOS на борту, то не оперирует она такими понятиями, как транк или аксес порты. Если у вас на порте есть несколько вланов - он транковый, если один - аксес. Причём настроить всё это можно аж тремя разными способами.

/interface bridge port
add bridge=bridge interface=ether1

/interface list member
add comment=defconf interface=ether1 list=WAN

/ip upnp
set enabled=yes

/ip upnp interfaces
add interface=bridge type=internal
add interface=ether1 type=external

У вас wan интерфес в бридже с lan интерфейсами, да ещё при всём при этом с включённым upnp. Я бы ничему тут не удивлялся.

Если клиенты подконтрольны - настраивать ipsec или pppoe/vpn. Оба варианта требуют настройки на клиентских машинах. Оба варианта прожорливы по ресурсам, громоздко, муторно. ipsec будет слегка аккуратнее.
Если клиенты неподконтрольны - только избавляться от неуправляемого свитча. Хотя этот вариант и в первом случае предпочтительнее.

Отдельная подсеть для виртуальной wlan, policy base routing по src-addr

Как это правильно организовать

В простейшем случае таблицу маршрутизации для определённого трафика проще переназначить через мангл, имхо.

Впрочем, я не вполне понимаю что вы хотите сделать.

при этом весь трафик отправить в другой шлюз(провайдера)

Трафик чего?

Регулярка на L7 не умеет работать по схеме, всё кроме выражения.

- Помечаете через mangle соединения, соответствующие попыткам подключения этого компьютера к серверам windows update и нужному сайту на прероутинге либо на форварде, со снятой галкой passtrought
- В фаерволе на форварде разрешаете промаркированные таким образом соединения, и запрещаете все прочие для этого компьютера (не забыв разрешить dns и ntp, конечно)