Ziptar

Смотреть в сторону MSS и MTU у PPTP подключения и у L2TP подключения.

Можно отлавливать скриптом поднятие l2tp подключения и прописывать статику в настройки днс. Но я не уверен, что статически прописанные серверы имеют для микротика приоритет над динамическими.
В таком случае можно скриптом отлавливать поднятие l2tp подключения и включать правило для ридиректа запросов на 53/UDP на 8.8.8.8 например.

:if ([:len [/ppp active find name="имя l2tp подключения"]] > 0) do={
/ip firewall nat enable [find comment~"Часть коммента правила с редиректом"]
} else {
/ip firewall nat disable [find comment~"Часть коммента правила с редиректом"]
}
Ну и само правило на редирект создать с соответсвующем комментом, а скрипт запускать каждые 10 сек., предположим.
Как-то так, но это не точно.

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

https://wiki.mikrotik.com/wiki/Manual:Scripting#Gl...

error :error Generate console error and stop executing the script

Два влана между микротиком с вафлей и микротиком-шлюзом; один для управления, второй для гостевой сети.
У меня за раздачу адресов для гостевой сети отвечает микротик-шлюз; раздающий вайфай микротик вовсе не имеет vlan-интерфейса для гостевой сети и, соответственно, никак с ней не взаимодействует. Так меньше сущностей возникает =) А на шлюзе уже разруливается фаерволом.

Для упрощения задачи читать про bridge-vlan.

В роли https-proxy микротик работать не способен, а у подмены dns есть множество обходных вариантов.
Так что в зависимости от скилла пользователей или закрывать обходные пути для подмены dns, что зачастую сложно, и не всегда вообще реально, или делать https-proxy НЕ на микротике.

ЗЫ при наличии домена, белого списка приложений, и исключения загрузки расширений для браузеров - подмена dns вполне себе рабочий вариант.

Если я правильно понял, то требуется только digital signature. Проверим.

Вам зачем?

The EoIP protocol encapsulates Ethernet frames in GRE (IP protocol number 47) packets (just like PPTP) and sends them to the remote side of the EoIP tunnel.

В отличие от PPTP EoIP не использует tcp порты, udp тоже.

"всё запрещенно что не разрешено" делается следующим образом:
1) разрешающее правило для административного input трафика для доверенных интерфейсов
2) разрешающее правило для административного output трафика для доверенных интерфейсов
3) запрещающее правило для всего forward трафика
4) запрещающее правило для всего input трафика
5) запрещающее правило для всего output трафика

Все остальные правила помещаются перед этими правилами.
Актуально в равной степени для mikrotik firewall и iptables.

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.

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

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

/ip dns print

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

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