Ziptar

Verify client certificate работает только при соединении через sstp двух микротиков. Windows для проверки подлинности клиенским сертификатом (для sstp) должен использовать EAP, который микротик не поддерживает ни в каком виде (для vpn).

Вариантов с проверкой клиентского сертификата в тиках при сочленении с виндовым клиентом только два: openvpn и ikev2

UPD: впрочем, может я и не прав на счёт eap для vpn. Народ в интеретах пишет, что возможно. Но это нужно или иметь radius сервер, или городить его на микротике.
Года два-три назад это точно не работало.

Раз: https://habrahabr.ru/post/188718/
Два: https://habrahabr.ru/post/307214/

Во-первых, микротик для каждого установленного сертификата пытается проверить не отозван ли он, и, соответсвенно, пытается получить crl. Обычно, если микротик не может получить доступ к списку отзывов для сертификата сервера, который он использует - это никак не препятствует работе его сервисов.
Во-вторых, для sstp - клиенты пытаются проверить сертификат сервера, в том числе не отозван ли этот сертификат, и самостоятельно пытаются получить доступ к crl, без участия сервера.
Так какой провайдер блокирует доступ к crl? Провайдер клиентов? В любом случае блокировка доступа к crl RapidSSL является ни много ни мало нарушением сетевой связности, если блокировку осуществляет провайдер, поэтому пинайте его.
Что касается непосредственно вопроса - нет, данные в сертификате не подлежат изменению.

Далее, в функционале микротиковского SSTP есть настройка "verify client certificate". Она предназначена для установки sstp-соединения исключительно между двумя микротиками. Если эта опция включена - выключите.

Для RDP подключений стоит выбирать те виды vpn, которые умеют работать через udp. Для микротов это ipsec / ikev2.

Настраиваете vpn-сервер, назначаете диапазон адресов для vpn-клиентов, далее рулите доступом через фаервол опираясь на этот диапазон и "all ppp" в качестве интерфейса; никакой проброс портов не нужен.
С маршрутизацией роутер сам разрулит, ситуация, судя по всему, простейшая. Единственное что - надо запретить vpn-клиентам ходить в интернет через ваш основной канал; и на клиентах отключить использование vpn-поключение в качестве шлюза, если речь идёт о win-клиентах.

Касательно того, что лучше: pptp небезопасен, равно как и l2tp без ipsec, ipsec сложен для новичков, openvpn в реализации тика неудобен и тоже сложен для новичков; самый простой и надёжный вариант для win-клиентов - sstp. В последнем случае вся "сложность" заключается в генерации самоподписанного сертификата для сервера и добавление его в доверенные на клиентах; ну или если есть свой домен - просто выписать сертификат через let's encrypt.

Ну вообще говоря там есть fail2ban, пользуйтесь им для таких целей. Вручную банить всех, кто пытается подобрать пароль к админке - с ума сойдёте.

1. На виндовом сервере отключить у pptp-клиента использование в качестве шлюза по-умолчанию
2. На виндовом сервере в качестве шлюза по-умолчанию использовать его собственный выход в интернет
3. На виндовом сервере для подсети или подсетей к которым принадлежат pptp-клиенты прописать статический маршрут через pptp-сервер.

error: bind to port 2220 on some.ip.adress failed : Caanot assign requested adress

Само собой. ОС ничего не знает о Вашем внешнем IP, который присвоен wan-интерфейсу роутера.
В sshd_conf нужно оставить прослушивание только на локальном адресе, а на роутере пробросить входящие со стороны провайдера соединения по соответствующему порту на этот самый адрес.

Не могли бы Вы дать пояснения к правилам mangle? На мой взгляд там царит какой-то хаос.

Напрямую - никак.
И Layer7 тут не помощник, т.к. DNS-запрос посылается только при первом обращении к ресурсу, всё остальное время (пока жив днс-кэш) софт работает с ip.

Можно лишь попытаться составить список доменных имён, обновлять периодически их ip-адреса на маршрутизаторе, составляя списки, и уже с этими списками работать. Для клиентов в локальной сети перехватывать через L7 запросы к DNS, и подменять на те адреса, что есть у роутера. Хотя стоит учитывать, что в случае использования клиентами DNSCrypt - перехватить не получится.
На микротиках реализуемо, хотя и нетривиально.

Каким образом проверить какие dns сервера использует микротик

/ip dns print

и подключенные к нему устройства, и в чем собствено проблема ?

Проверяйте фаервол.
Микротик должен иметь возможность послать запрос (output chain) на 53-ий порт udp (dst-port) в сторону провайдера, и, соответственно, получить ответ (input chain) с 53-его udp порта (src-port) с той же стороны.

Значит не сбросили.

Брать и делать, параллельно гуглить и читать книженции, что выше уже рекомендовали. Какой-либо пункт в отрыве от остальных почти полностью бесполезен.

Дурацкий вопрос к сведующим:
Есть препятствия к тому, что бы пробросить iscsi том на винсервер, а уже с него по смб раздавать файлшару?

Другие без самоделкинства не реализовать, и все они локального действия.
Весь остающийся вывод: usb, poe, ssh.

Самый простой и наименее затратный вариант - всё же e-mail уведомления. С МТ на внутренний smtp-сервер, а с него уже с авторизацией и шифрованием на внешний почтовик - хотя бы и тот же gmail. Это если внутрикорпоративного почтовика нет, конечно.
UPD: я невнимательный. Почитал комменты. Ну, можно намутить коннект по ssh, дабы мт посылал команду на рассылку сообщения по корпоративному мессенджеру?... активировал лампочку на столе у босса?... что угодно, но всё равно это из разряда самоделкинства. Готовых решений, скорее всего, нет.

Завсисит от приложений. На уровне протоколов/портов можно разрулить фаерволом. Аутпостом, например.