Ошибки при установке VPN соединения с сервером L2TP IPSec Mikrotik

При настройке VPN-сервера на Mikrotik, могут быть ошибки. Некоторые из них не связаны с очепятками и недостатком знаний. Могут встречаться нелогичные или специфичные для какой-то ситуации ошибки.

Освоить MikroTik Вы можете с помощью онлайн-куса «Настройка оборудования MikroTik». Курс основан на официальной программе MTCNA. Автор курса – официальный тренер MikroTik. Подходит и тем, кто уже давно работает с микротиками, и тем, кто еще их не держал в руках. В курс входит 162 видеоурока, 45 лабораторных работ, вопросы для самопроверки и конспект.

Proxy-arp на внутреннем бридже

При подключении по VPN вы можете неприятно удивиться, почему вы можете открыть страницу логина в роутер, 192.168.88.1 (если у вас такой), но не сможете открыть ни один внутренний ресурс. Штука в том, что надо включить proxy-arp на внутреннем интерфейсе, за которым есть нужный вам ресурс. У меня proxy-arp включен на весь bridge-local. Этот параметр позволяет взаимодействовать хостам, находящимся в разных сегментах сети, между друг другом.

Меню Interfaces -> открываете bridge-local, в пункте ARP выбираете proxy-arp.

Глюк default policy на микротик

При абсолютно верных настройках L2TP/IPSec подключения на клиенте (например, Windows 7) и на сервере (Mikrotik), не удается установить VPN-подключение. При этом в лог Mikrotik идет сообщение «failed to pre-process ph2 packet», а на клиенте Windows 7 выходит ошибка 789: попытка L2TP-подключения не удалась из-за ошибки, произошедшей на уровне безопасности. Данная проблема может иметь место на прошивках вплоть до последней стабильной на текущий момент (6.30).

Решение: удалить созданную по умолчанию группу в меню IP — IPSec — Groups, создать новую и указать ее в IP — IPSec — Peers в поле Policy Template Group.

По сообщению Hopy, еще одним решением проблемы с группами может стать выполнение этой команды после пересоздания группы:

ip ipsec peer set 0 policy-template-group=*FFFFFFFF

Возможно, это наследие от старых конфигураций, точного ответа нет, но тем не менее, это вариант. Кстати, возможно по этой причине (и ей подобным) все же стоит выполнять полный сброс устройства перед начальной настройкой. Но требованием это не является, это уж точно.

Ошибки firewall на всех этапах

Ну и не забывайте про то, что в нормальной ситуации при подключении удаленного клиента действуют сразу несколько ограничений, в числе которых брандмауэр клиента, брандмауэр шлюза клиента (или провайдерский прокси), брандмауэр самого микротик (и не только цепочка input — серьезно помешать может цепочка forward), который вы раньше настроили максимально строго, не так ли? Всякие NAT через NAT и траверсом погонять могут. Так что старайтесь всегда разумно и спокойно локализовывать проблему.

Освоить MikroTik Вы можете с помощью онлайн-куса «Настройка оборудования MikroTik». Курс основан на официальной программе MTCNA. Автор курса – официальный тренер MikroTik. Подходит и тем, кто уже давно работает с микротиками, и тем, кто еще их не держал в руках. В курс входит 162 видеоурока, 45 лабораторных работ, вопросы для самопроверки и конспект.

Источник

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

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

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

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

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

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

Решение 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Более детально распишу. К примеру, у нас есть локальная сеть 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

Маршрут на клиенте не будет появляться, но когда вы сделаете запрос к этой сети, пакет отправиться на шлюз local ip l2tp микротика

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

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

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

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

. машина видит, что такой сети она не знает, поэтому отправляет на шлюз l2tp local ip микротика.

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

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

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

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

Все выше сказанные посты имеют свою правду. Дело в том, что я столкнулся с приблизительно такой же проблемой. При создании 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

/ip firewall raw add action=notrack chain=prerouting

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

На сервере по адресу поднимаем 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 повесить!). На Микротике аналога я не нашел.

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

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

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

Источник