MikroTik L2TP/IPsec сервер не отправляет маршрут клиенту

Август, 06th 2019Рубрика: Безопасность 40593
Подписаться на комментарии по RSS

MikroTik L2TP/IPsec сервер не отправляет маршрут клиенту

После двух дней мучений, готов признать что хвалёный MikroTik не справился с простой задачей, которая на Keenetic Ultra II решается в пару кликов. Возможно, это вовсе не связано с недоработками в RouterOS, а у меня просто не хватило терпения или знании, чтобы заставить L2TP/IPsec на «микротике» добавлять маршрут клиенту при соединении.

Полазив по тематическим форумам и wiki, посвященных настройке оборудования MikroTik, найти решения так и не удалось. Собственно, в чём суть проблемы? При подключении к L2TP/IPsec серверу, клиент не видит компьютеры локальной сети за ним, впрочем как и самого роутера. Пинги дальше виртуальной сети не проходят.

Решение 1: Отправлять весь трафик клиента через VPN

Если в настройке соединения на клиенте указать что следует «Отправлять весь трафик через VPN», локальная сеть за роутером прекрасно видится. Но в этом случае мы гоним весь собственный трафик, вместе торрентами и прочим барахлом через удалённый офис, где запущен L2TP/IPsec сервер. Зачем это всё, если нам требуется просто получить доступ к терминальному серверу в удалённой сети?

macOS. Отправлять весь трафик через VPN

Windows 10 по умолчанию заворачивает весь трафик в VPN канал при создании подключения. Проверить это можно открыв свойства протокола IP версии 4 (TCP/IPv4) и в дополнительных параметрах TCP/IP будет активирован пункт «Использовать основной шлюз удаленной сети».

Настройка VPN в Windows. Использовать основной шлюз удаленной сети

Решение 2: Прописать дополнительный статический маршрут на клиенте

Странно, но по всей видимости, MikroTik не умеет самостоятельно отправлять дополнительный маршрут клиенту при подключении к L2TP/IPsec серверу. Замечу, что Keenetic Ultra II прекрасно справляется с аналогичной задачей и поднять на нём L2TP/IPsec сервер может обычный пользователь. Лишний раз убеждаюсь, что «микроты» придуманы, чтобы наполнять жизнь упоротых любителей копания в настройках смыслом.

Раз не получилось сотворить задуманное в настройках L2TP сервера, придётся добавить требуемый маршрут к удалённой сети на клиенте ручками. Для примера, пусть локальная сеть за MikroTik будет 192.168.88.0/24 и local-address L2TP/IPsec сервера 10.8.0.10:

sudo route -n add 192.168.88.0/24 10.8.0.10

Как ни крути, но такое решение тоже "костыль". И как бы не утверждали на одном из форумов по настройке "микротов", что заворачивать весь клиентский трафик в VPN канал благо, я с этим не согласен. Потому буду рад, если кто напишет как заставить MikroTik самостоятельно назначать маршруты клиентам вместе с выдачей IP.

Подписывайтесь на канал Яндекс.Дзен и узнавайте первыми о новых материалах, опубликованных на сайте.

Если считаете статью полезной,
не ленитесь ставить лайки и делиться с друзьями.

Комментариев: 37

  1. 2019-08-07 в 11:02:05 | Сергей Мусалимов

    А не проще взять Д-линк или другой нормальный роутер ?

  2. 2019-08-07 в 11:13:59 | dre@mer]]>avatar]]>

    Сергей, не подскажете что подразумевается под "нормальными" роутерами? На Keenetic данная конкретная задача решается проще, но микротик, как ни крути, более функционален.

  3. 2019-08-13 в 15:13:09 | Ирина

    Я не надеялась, но обновление решило проблему. Спасибо огромное

  4. 2019-08-20 в 15:45:56 | Alexander

    длинк давно перестал быть нормальным....

  5. 2019-09-13 в 09:34:30 | Юрий Беляев

    Была задачи в филиальной сети заменить роутеры на DD-WRT в которых уже использовался OpenVPN. Приобрели хваленый микротик, т.к. в нем заявлена поддержка OpenVPN. И что же оказалось - она есть, но куцая и нам не подошла, т.к нам бы пришлось все переделывать. Взяли Zyxel Keenetic, а вот там поддержка OpenVPN оказалась той что нужно. На них и остановились. Keenetic'и замечательно справляются со свое задачей не только с OpenVPN, но и без особых заморочек строить туннели Ipsec.

  6. 2019-09-19 в 10:35:27 | Павел Казарцев

    правила надо было прописавать и masquerade настроеть под vpn. и все на тиках ходит....

  7. 2019-09-19 в 10:37:26 | dre@mer]]>avatar]]>

    Павел, не подскажите какие именно правила отправляют маршрут клиенту? и как на это влияет masquerade?

  8. 2019-10-07 в 20:53:10 | Павел Казарцев

    вот правила для фаервола

    /ip firewall filter
    add chain=input action=accept protocol=udp port=1701,500,4500
    add chain=input action=accept protocol=ipsec-esp

    пускаем IP нашего VPN-пула в локалку:

    /ip firewall filter
    add chain=forward action=accept src-address=*.*.*.0/24 in-interface=!sfp1 out-interface=bridge comment="allow vpn to lan" log=no log-prefix=""

    По-умолчанию masquerade настроен для физического WAN-интерфейса(sfp1/ether1 и тд) , а нам надо запустить все через L2TP

    Делаем следующее правило:

    Chain=srcnat
    Out. Interface=l2tp_client
    Action=masquerade

    Еще есть ньюанс, что локальные интерфейсы в бридже надо перевести в proxy-arp

  9. 2019-10-08 в 11:57:01 | dre@mer]]>avatar]]>

    Павел, а вы сами пробовали так делать? Как это влияет на отправку маршрута клиенту?

  10. 2019-10-11 в 20:26:51 | Роман Терехов

    Совершенно дилетантский подход к настройке железа. Ды, сударь, с кошками или джунами работали? Прежде чем написать статью - загуглите что и как настраивается, дело двух строк (и вам уже подсказали их) . А то круто получается: графоманством пострадать - норм, время есть, а в гугле настройку канала найти - "ай-яй-яй, микрот гавно"

  11. 2019-10-11 в 20:48:05 | dre@mer]]>avatar]]>

    Роман, ну а вам что мешает написать эту пару строк настроек сюда, раз так хорошо владеете гуглом? Готов признать себя дилетантом, если поделитесь вашим тайным знанием.

  12. 2019-10-13 в 22:49:23 | Роман Терехов

    dre@mer, а на хрена? Статью написать, хайпануть, получить бабло за просмотр - это мы запросто, а изучить матчасть по настройке железа - "нафиг надо, хомячки схавают". Тем более, что вам уже подсказали как это сделать.

  13. 2019-10-13 в 23:40:20 | dre@mer]]>avatar]]>

    Роман, отвечу в вашем стиле: "Все пи##Rасы, один я Дартаньян..." Ну а по сути, вы сами пробовали то что написано? Почитайте внимательно о чём статья. Проблема в том, что "микрот" не умеет отправлять маршрут клиенту при L2TP/IPsec, как Keenetik. Поэтому и приходится заворачивать весь пользовательский трафик в канал.

    И насчёт хайпа... вы реально считаете данную тему хайповой и что на ней можно заработать? Да она интересна только узким специалистам.

  14. 2019-10-14 в 10:30:42 | Роман Терехов

    если бы я не обслуживал парк порядка 30 микротов в 8 офисах, двух датацентрах (site-to-site ipsec, обычные l2tp каналы (с шифрование и без) , включая l2tp дублирующие, с распределенной маршрутизацией) - я бы молчал. Суть моего негодования сводится к тому, что не разобравшись с матчастью клепается чудо-статейка о том, какое говно этот микрот, и ничего он не умеет *рукалицо*.

    И, да, у меня все прекрасно работает, только дело в том, что микрот отправляет клиенту дефолт (если в курсе что это) , а сам трафик рулится маршрутам уже на микроте, и там его можно завернуть в любую дырку, но важно ещё понимать принцип работы firewall. А сравнивать его с длинком или зухелем, млять, это как сравнить инвалидку и болид формулы-1: и то и то машина, но какая разница между ними....

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

  15. 2019-10-14 в 10:41:28 | dre@mer]]>avatar]]>

    Роман, я очень рад что вы освоили дефолтные маршруты, только статья не об этом

  16. 2019-10-15 в 11:21:02 | Аноним

    Сколько баталий, интриг и войн. Предложение с firewall и nat это лишние костыли, все гораздо проще решается. Микротик умеет выполнять данное требование, желательно пройти курс MTCNA, после которого все вопросы данного рода отпадут. PPP - Secrets, когда создаете запись, в этой записи есть такая настройка, как Routes, именно здесь и указывается необходимая Вам сеть, куда надо попасть. Эта сеть добавляется в таблицу маршрутизации микротика и после и все запросы к этой сети, будут отправляться через local ip l2tp микротика. Easy win

  17. 2019-10-15 в 11:36:28 | dre@mer]]>avatar]]>

    Вы путаете, я знаю про поле Routes и в нём прописывается сеть клиента, который подключается к L2TP серверу, а вот отправлять маршрут клиенту, Mikrotik пока не умеет. Не верите мне, почитайте форумы или задайте вопрос преподавателям курсов. Возможно это будет решено в 7-ой версии прошивки.

  18. 2019-10-15 в 11:59:50 | Аноним

    Вы неправильно понимаете работу поле Routes. Оно прописывает дополнительный маршрут, куда должны попадать пакеты через vpn туннель. Маршрут на клиенте не будет появляться, но когда вы сделаете запрос к этой сети, пакет отправиться на шлюз local ip l2tp микротика, а там уже будет динамическая запись к вашей сети, куда надо попасть. Я эту схему реализовал, это работает. А вы вместо того, чтоб спорить, возьмите и проделайте. Если в боевую сеть страшно запускать, тогда соберите стенд с одним микротиком и проверьте.

  19. 2019-10-15 в 12:12:20 | Аноним

    Более детально распишу. К примеру, у нас есть локальная сеть 192.168.1.0/24

    подключенная к ether2 микротика. Так же есть сеть 192.168.2.0/24, подключенная в другой порт, порты между собой независимы. Для сети 192.168.1.0/24 на микротике Вы создаете туннель, допустим, loсal ip 10.0.0.1 and remote ip 10.0.0.2. Так вот, чтобы из сети 192.168.1.0/24 попасть в сеть 192.168.2.0/24, мы прописываем в это поле Routes 192.168.2.0/24. После того, как клиент подключиться по впн, в таблице маршрутизации появится динамическая запись о сети 192.168.2.0/24 через созданный туннель. А маршрутизатор в свою очередь знает о сети 192.168.2.0/24 и как туда добраться. Соответственно компы из сети 192.168.1.0/24 смогут увидеть сетку 192.168.2.0/24

  20. 2019-10-15 в 12:16:16 | dre@mer]]>avatar]]>
    Маршрут на клиенте не будет появляться, но когда вы сделаете запрос к этой сети, пакет отправиться на шлюз local ip l2tp микротика

    Каким образом клиентская машина поймёт, что пакеты для другой, неизвестной ей сети, следует отправлять именно в VPN-канал, если такого маршрута у клиента нет? Ещё раз обращаю внимание, что он НЕ ЯВЛЯЕТСЯ ШЛЮЗОМ ПО УМОЛЧАНИЮ!

    И уж поверьте, я не раз проверил что там передаётся, а что нет.

  21. 2019-10-15 в 12:56:09 | Аноним

    Что могу сказать, плохо вы проверяли. Клиентская машина отправляет пакет в Вашу необходимую сеть, машина видит, что такой сети она не знает, поэтому отправляет на шлюз l2tp local ip микротика. А сам уже микротик знает про этот маршрут и доставит его именно в нужную сеть, таким же образом пакет вернется обратно к источнику.

    Я смотрю, что Вы любите спорить. Вам отписываю готовое решение, а Вы его не можете реализовать. Если не хватает знаний в микротике, либо идите обучайтесь, либо пользуйтесь железкой Keenetic

  22. 2019-10-15 в 13:46:15 | dre@mer]]>avatar]]>
    ...машина видит, что такой сети она не знает, поэтому отправляет на шлюз l2tp local ip микротика.

    Данное утверждение справедливо в случае, когда VPN-интерфейс выступает шлюзом по умолчанию. Так что это не мне не хватает знаний по микротикам, а вам по сетевой маршрутизации, либо вы упорно игнорируете то, о чём я пишу.

    Мне кажется вы пытаетесь описать ситуацию с объединением сетей, где клиентами выступают сами микротики и являются шлюзами для локальных сетей за ними. Тогда, действительно, все запросы идут к ним.

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

  23. 2019-10-15 в 14:53:15 | Аноним

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

  24. 2019-10-23 в 10:56:12 | Сергей

    Все выше сказанные посты имеют свою правду. Дело в том, что я столкнулся с приблизительно такой же проблемой. При создании VPN L2TP Server Mikrotik с использованием IpSec и VPN клиенте Windows без использования основного шлюза в удаленной сети, локальная сеть за сервером L2TP недоступна через сеть сделанную для VPN соединения. Добавление постоянных маршрутов на клиенте решало эту проблему, но при разрыве VPN соединения и при установке нового соединения сеть была не доступной. Решение оказалось простым. Необходимо сделать маршрут в созданном VPN в локальную сеть за микротиком. Что для этого необходимо:

    1. Для каждого пользователя VPN назначить ip address клиента и сервера, т.е. в PPP Secret указать в поле Local Address -это адрес сервера при создании тунеля из пула адресов созданных для данного VPN, в поле Remote Address - это адрес клиента. При установке VPN пользователи будут получать именно те адреса которые вы укажите.

    2. В поле Routes указать сеть куда необходимо маршрутизировать трафик (локальная сеть за микротиком).

    3. Прописать постоянный маршрут на Windows VPN-клиенте через адрес полученный при установке VPN.

  25. 2019-12-16 в 12:52:29 | Комментатор 184]]>avatar]]>

    Люди добрые, почитал эту ветку и ужаснулся.

    А для чего на микроте протоколы динамической маршрутизации RIP, OSPF?

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

    Кому интересно, пишите.

  26. 2019-12-16 в 14:59:09 | dre@mer]]>avatar]]>

    Расскажите как это настраивается в данном случае?

  27. 2019-12-16 в 15:09:58 | Комментатор 184]]>avatar]]>

    Включите прослушиватель RIP на винде.

    Создайте server binding для vpn клиента.

    Запустите протокол RIP на роутере Routing-Rip-Interfaces - добавьте интерфейс vpn клиента, далее в Networks пропишите ip адрес туннеля vpn клиента и там же анонсируйте маршрут (подсеть), который хотите передать. Вот и всё!!!

  28. 2019-12-19 в 09:49:46 | lenar

    Доброго времени суток! Комментатор 184, а как быть mac os и ios

  29. 2020-01-30 в 14:35:38 | 2life]]>avatar]]>

    Тоже бился с данной проблемой, пока добрые люди с чатика Mikrotik Training ссылкой не поделились на доку. https://mum.mikrotik.com/presentations/KZ18/presentation_6153_1539617171.pdf

  30. 2020-11-16 в 14:57:59 | Alkseyka

    хех, и как мне допустим к 9.9.9.9 на клиенте получить доступ через vpn, а потом к 34.34.34.34 и т.д при снятом флаге что весь трафик через vpn

  31. 2020-11-22 в 09:17:54 | Александр

    DHCP сервер Микротика никак не заставить работать с PPP, а вот направить запрос DHCPInfo из PPP на другой DHCP сервер в сети предприятия -- можно. На этом сервере настраивается область, из которой никаких IP рааздаваться не будет, но можно раздать маршруты (опция 121) и суффикс DNS, чтобы на рабочие компьютеры ходить по коротким именам. Работает с любым PPP интерфейсом, проверено

  32. 2020-11-23 в 00:07:10 | Александр

    Делается примерно так:

    /ip firewall nat add action=dst-nat chain=dstnat \

    dst-address=255.255.255.255 dst-port=67 in-interface=all-ppp protocol=udp \

    src-address= to-addresses=

    /ip firewall raw add action=notrack chain=prerouting

    dst-address= protocol=udp src-address= \

    src-port=67

    На сервере по адресу поднимаем DHCP для области (адреса реально раздаваться не будут, их раздаст Микротик), задаем нужные опции и радуемся.

    Лучше бы, конечно, если бы сам Микротик это умел, но разработчики отвечают, что DHCP с PPP никогда работать не будет, поскольку в PPP не бывает бродкаста. На самом деле с подачи Майкрософта все распространенные PPP-клиенты выдают запрос DHCPInform на бродкаст (255.255.255.255). И он доходит до PPP-сервера (а куда ему еще деваться), и если сервер ответит -- полученные опции используются! Насколько я знаю, именно так всегда раздаются маршруты в PPTP, L2TP и т. д. (кроме OVPN). Самое смешное, что и в RRAS от MS тоже нужно трясти бубном, чтобы это заработало! Но там удается использовать DHCP на самом сервере удаленного доступа, установив Loopback Adapter. (Не тот loopback, который 127.0.0.1, а отдельный драйвер, эмулирующий Ethernet, на который можно DHCP повесить!). На Микротике аналога я не нашел.

  33. 2020-11-23 в 00:16:09 | Александр

    Угловые скобки вместе с содержимым съелись :(. В первом правиле to-address и во втором правиле src-address -- адрес сервера DHCP. В первом правиле src-address и во втором dst-address -- диапазон адресов клиентов PPP.

  34. 2020-12-14 в 21:29:36 | Комментатор 198]]>avatar]]>

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

  35. 2020-12-16 в 11:43:24 | dre@mer]]>avatar]]>

    И не поможет. Задавал вопрос про отправку маршрута клиенту с Микротика сертифицированным тренерам по программе обучения микротов и там сказали, что никто не заявлял такого функционала. Так что увы, Кинетики оказались лучше, хоть и подороже.

  36. 2022-01-18 в 17:04:28 | 6ypaTuH0

    Комментатор 198, сделайте бридж, в профиле впн(на микроте) настройте добавление в этот бридж, после на микроте надо настроить Routing-RIP, при настройке RIP используйте тот бридж который сделали для впн, на винде установить прослушиватель RIP, и если есть брандмауэр(или какие-либо антивирусы), то открыть порт udp 520.

    https://www.youtube.com/watch?v=JgsN_qPnEBw

    https://www.youtube.com/watch?v=kRvDgudmMFo

  37. 2023-01-24 в 22:27:39 | НастройкаМикротик.рф

    Ни L2TP, ни L2TP IPsec, ни PPTP, ни SSTP не умеют push route в принципе. То, что у вас работает на кинетике - это кинетик даёт интернет через себя. Чтобы так же было на микротике, нужно настроить правильно nat.

    Push route умеет ТОЛЬКО OpenVPN и IKEv2, а так же сторонние протоколы и приложения типа циско коннект.

ваш комментарий будет опубликован после проверки
на указанный адрес будет отправлено письмо с кодом активации. Вы можете настроить собственный профиль и стать активным участником или автором.