Ziptar

>как это работает
Согласно модели OSI это работает. USB модем - обычно L2 (NDIS-адаптер) (хотя фактическая коммуникация по L3 - IP, NAT, все дела). Proxy - как правило подразумевается L7, хотя есть варианты L4

>можно ли как нибудь сделать так, что бы при использовании прокси компьютер думаю что это USB-модем, и работал без всяких прокси-настроек?
Нет, нельзя. Прокси не оперирует протоколами (в основном это IP), характерными для L3. А на L3 нет никакого представления о том, для чего его используют L4-7. VPN же, как раз таки, предназначен для работы на L3.
Можно лишь соорудить прокладку между целевым прокси и взаимодействием с операционной системой, реализующую L2-L3 взаимодействие (те же самые NDIS адаптеры передают привет - это и есть такая прокладка, по большому счёту, только в тех же USB 3g/lte модемах она используется несколько по-другому - в сторону L1 и L2 в сотовых сетях, а не в сторону L7) - но смысла в этом... только в определённых коммерческих целях, разве что. Не для персонального использования точно - мороки и человеко-часов много, толку мало.

1. Коротко: нельзя, провайдер не позволит. Не выдаст вам нужной информации для подключения вашего собственного оборудования.
2. 800 мегабит = 100 мегабайт. Для "типичного домашнего пользователя" 20 мегабит за глаза. Если же активно качаете относительно большие объёмы данных (в пределах, характерных для домашнего пользователя - фильмы, игры) - некогда стандартные 100 мегабит покрывают все потребности.

Без озвучивания конкретных целей любой совет будет "пальцем в небо". Подбирайте под конкретные задачи. Условная "надёжность" у всех примерно одинаковая в своих сегментах.

В свойствах подключения в панели управления вкладка "Общие", снять галку "сначала набрать номер для этого подключения".

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

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

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

Нормально разбивать на подсети, больше никак.

Эти машины просто напросто не находят DHCP сервер при очередной попытке обновления адреса.

Пытайтесь понять почему так происходит, сколько по времени ждут ответа DHCP-сервера клиентские машины, где трафик может идти не туда, etc.

Роутер 2 - просто мост?

Тут микротик советуют - предупреждаю: реализация ovpn оставляет желать на столько лучшего, что даже udp не поддерживает.

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

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

/ip dns print

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

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

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

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