Введение
IP in IP — это протокол IP-туннелирования, который инкапсулирует один IP-пакет в другой IP-пакет. Инкапсуляция одного IP пакета в другой IP пакет, это добавление внешнего заголовка с SourceIP — точкой входа в туннель, и Destination — точкой выхода из туннеля. При этом внутренний пакет не был изменен (кроме поля TTL, которое уменьшилось). Поля Don’t Fragment и The Type of Service должны быть скопированы в внешний пакет. Если размер пакета больше чем Path MTU, пакет фрагментируется в инкапсуляторе, это должно быть во внешнем заголовке. Декапсулятор должен будет собрать пакет. Многие маршрутизатора, включая Cisco и Linux-based, поддерживают этот протокол.
Настройка туннелирования (L2TP)
1. IP — Pool / Определям диапазон адресов VPN-пользователей
Name: vpn_poolAddresses: 192.168.112.1-192.168.112.10Next pool: none
Лучше для клиентов vpn использовать отдельную адресацию. Так проще отделять одних от других. И вообще, бест практис.
2. PPP — Profiles / Профиль для нашего конкретного туннеля
General:Name: l2tp_profileLocal address: vpn_pool (а можно указать 192.168.88.1, сами смотрите, как вам больше нравится)Remote address: vpn_poolChange TCP MSS: yes
Protocols:all to default:Use MPLS: defaultUse compression: defaultUse Encription: default
Limits:Only one: default
3. PPP — Secrets / Готовим пользователя VPN
Name: vpn_user1Password: bla-bla-blaService: l2tpProfile: l2tp_profile
4. PPP — Interface — клик на L2TP Server / Включаем сервер L2TP
Enabled — yesMTU / MRU — 1450Keepalive Timeout — 30Default profile — l2tp_profileAuthentication — mschap2Use IPSec — yesIPSec Secret: tumba-yumba-setebryaki (это не пароль пользователя, а предварительный ключ, который надо будет указывать на клиентах в дополнение к логину/паролю)
Certificate file extensions
- .csr A Certificate Signing Request, in PKCS10 format. Often used on web servers to request an SSL certificate from a certificate provider.
- .cer (also named .crt and .der) An X.509 certificate in binary format.
- .key Can be a public or private PKCS#8 keys as binary DER or ASCII PEM. Usually the private key for a .cer certificate.
- .pem (.pub) An X.509 certificate that is Base-64 encoded and have a header and footer added. Can also function as a container that holds several certificates and keys. .pub is usually a public key, while .pem is a private key. Headers used are «BEGIN RSA PRIVATE KEY» and «BEGIN DSA PRIVATE KEY».
- .ppk A container file including public and private key, created by the popular SSH client Putty, originally created for SSH usage on Windows. The public key is stored in plaintext, while the private key is encrypted. Short for «PuTTY private key». # .pub: ssh public key # .pem: ssh private key
- .pfx Originally a Windows certificate container, but have for many years now been an alias for .p12 on Windows. Since the .p12 extension works everywhere on all OSes and all Windows versions, you should use the .p12 extension instead of .pfx.
- .p12 (.pkcs12, PKCS #12) An encrypted container, that usually stores a private key, it’s certificate and the CA certificate chain. You will usually need to supply the encryption password, to access the certificates inside the .p12.
IKEv2 authentication option
- pre-shared key (mac only) Supported on iOS and macOS. Not supported on Windows 7, 8, 10.
- EAP-only (no Windows) EAP username and password without certificate. Windows can only authenticate with EAP-MSCHAPv2.
- PEAP (Protected EAP, Windows 7) Wraps another EAP method (like EAP-MSCHAPv2) in a TLS tunnel.
- EAP-TLS (Windows 7) Also wraps EAP.
-
EAP-TTLS, EAP-AKA, EAP-AKA, EAP-SIM (Windows
Not MikroTik supported, almost all require a trusted certificate on the router.
MikroTik authentication methods
- pre-shared-key — authenticate by a shared password/key/secret.
- rsa-signature — authenticate using client/server RSA certificates.
- rsa-key — authenticate using a RSA key imported in Ipsec key menu.
- pre-shared-key-xauth — mutual PSK authentication + xauth username/password.passive parameter identifies server/client side
- rsa-signature-hybrid — responder certificate authentication with initiator Xauth.passive parameter identifies server/client side
Extended information in the MikroTik IPsec wiki.
Firewall
Давайте уж к консоли, что-ли для разнообразия:
/ip firewall filter
add chain=input action=accept protocol=udp port=1701,500,4500
add chain=input action=accept protocol=ipsec-esp
Если у вас по-умолчанию политика forward установлена в drop (последнее правило для forward «chain=forward action=drop»), вам может быть необходимым разрешить forward с ip-адресов vpn_pool в локальную сеть:
add chain=forward action=accept src-address=192.168.112.0/24 in-interface=!ether1 out-interface=bridge-local comment=»allow vpn to lan» log=no log-prefix=»»
Вот теперь с сервером все.
Обоснование выбора
Речь пойдет про L2TP, как уже понятно из названия статьи. L2TP изначально предоставляет услугу PPP (на канальном уровне модели OSI) с последующей инкапсуляцией, что позволяет работать поверх IP.
Выбор его обусловлен тем, что:
- данный протокол поддерживается почти всеми популярными ОС из коробки (Win, Android, iOS), т.е. ничего не нужно дополнительно устанавливать, как в случае с OpenVPN;
- L2TP можно применять, когда клиент имеет динамический IP-адрес (или находится NAT).
Если бы и сервер и клиент имели статические внешние IP-адреса, то вполне можно было бы использовать чистый IPsec или же IPIP, GRE и EoIP over IPsec. Но чаще всего только с одной стороны имеется белый IP-адрес (например, в одном офисе), А потому все удаленные клиенты могут свободно подключаться через L2TP, будь это пользователи или же удалённые офисы.
Казалось бы, всё хорошо и замечательно с L2TP, но есть и главный его недостаток – отсутствие шифрования. Поэтому для решения этой проблемы и используется IPsec, который работает на сетевом уровне модели OSI и позволяет установить сначала IPsec-соединение, которое будет защищённым, а уже потом внутри него устанавливать L2TP-соединение.
Из минусов такого решения является производительность железки, на которой будет IPsec. CPU маршрутизатора будет интенсивно использоваться для шифрования пакетов и в результате скорость значительно просядет. Но эта проблема также решаема, т.к. у Mikrotik есть модели устройств, которые поддерживают аппаратное шифрование. При выборе маршрутизатора Mikrotik стоит учесть этот момент и рассмотреть модель с поддержкой т.н. hardware acceleration.
Настройка L2TP VPN-сервера на роутере Keenetic
С подробностями настройки L2TP/IPsec сервера на Keenetic Ultra можно ознакомиться перейдя по этой ссылке. Там всё просто, потому не буду повторяться. В дополнение к той статье, необходимо остановиться на паре существенных моментов, без которых не возможна нормальная работа VPN туннелей:
- Отключить NAT для клиентов, оно тут будет только мешать;
- Снять галочку, напротив поля «Множественный вход», если она там стояла. Это позволит точно указать IP адрес, выдаваемый клиенту L2TP сервером при подключении;
Настроить статическую маршрутизацию.
Для удалённых филиалов я выбрал имена office_01 и оffice_02 и назначил им соответсенно статические адреса 172.16.2.35 и 172.16.2.35. Эти адреса, указываются в качестве шлюзов при создании статических маршрутов для сетей, расположенных за ними. У office_01 внутренняя сеть 192.168.11.0/24, office_02 — 192.168.0.0/24
Подключение удаленного клиента
Пробуем подключить Windows 7:
Панель управленияСеть и ИнтернетЦентр управления сетями и общим доступом:
Настройка нового подключения или сети
Подключение к рабочему месту
Создать новое подключение
Использовать мое подключение к интернету (VPN)
Интернет-адрес: ip или имя роутера в сети
Пользователь и пароль из PPP->Secrets. В нашем случае это vpn_user1 и его пароль.
Пытаемся подключиться.
Если не выходит, или просто надо настроить созданное подключение:
Вкладка Безопасность:
Тип VPN: L2TP IPSec VPN
Дополнительные параметры: для проверки подлинности использовать предварительный ключ. В нашем случае это «tumba-yumba-setebryaki» (IP — IPSec — Peers):
Здесь же, в группе «Проверка подлинности», оставляем только CHAP v2:
Жмем ОК и пытаемся подключиться. Должно получиться. Если нет, загляните на страницу ошибок при настройке VPN.
Update 1: часто люди интересуются, как несколько (больше одного) клиентов из одной локальной сети (за nat) могут подключаться к одному удаленному vpn-серверу микротик. Не знаю, как в L2TP/IPSec связке это обеспечить. Можно назвать это багом реализации. Я не нашел простого объяснения и решения проблемы.
Настройки файрвола
Сервер должен принимать: UDP:1701 — L2TP, но только по IPsec UDP:500 — IPsec, установление соединения UDP:4500 — IPsec, для обхода NAT IP протокол 50 — IPsec ESP
Отмечаем ESP пакеты, L2TP будем принимать только в них
/ip firewall mangle add action=mark-packet chain=input new-packet-mark=esp protocol=ipsec-esp
/ip firewall filter add chain=input comment=L2TP dst-port=1701 packet-mark=esp protocol=udp src-address=10.0.0.102 add chain=input comment=IPSEC-NAT dst-port=4500 protocol=udp src-address=10.0.0.102 add chain=input comment=IPSEC dst-port=500 protocol=udp src-address=10.0.0.102 add chain=input comment=IPSEC protocol=ipsec-esp src-address=10.0.0.102
Клиенту достаточно принимать пакеты в состоянии established
Настройка Mikrotik L2TP Server. Главный офис
Создаем профиль подключения
У Mikrotik в меню PPP есть два профиля по умолчанию, которые используются для PPP соединений. Рекомендуется не изменять профили по умолчанию, а создать и использовать под свою задачу новый.
Создадим профиль для подключения, в котором укажем имя для соединения, назначим статические IP-адреса для L2TP сервера и клиента. Отроем Winbox, перейдя:
PPP => Profiles => “+”.
В окне New PPP Profiles, открыв, вкладку “General” укажем информацию:
- Name: l2tp-site-to-site;
- Local Address: 192.168.77.1;
- Remote Address: 192.168.77.10.
Мы указали:
- произвольное имя для профиля(Name);
- присвоили IP для L2TP-Сервера (Local Address);
- IP-Адрес L2TP-Клиента (Remote Address).
Настраиваем Secret
На вкладке «Secrets» мы настраиваем имя, пароль и профиль подключения для L2TP-Клиента. Для этого выполним действия:
- Secrets => “+”;
- Name: office;
- Password: qwas1234;
- Profile: из выпадающего списка выбираем ранее созданный профиль (l2tp-site-to-site).
Включаем L2TP Server и IPSec
Следующим шагом включим L2TP Server на Mikrotik указав профиль, метод аутентификации и ключ шифрования для IPSec. Выберем пункт меню Interface, настроим как показано на рисунке ниже:
Не забываем придумывать сложные пароли.
Создаем интерфейс
Создадим статический интерфейс L2TP Server Binding. Это позволит избежать проблемы с маршрутизацией между сетями, которые могут возникнуть при разрыве соединения.
Заполним открывшееся окно New interface. Вкладка «General»:
Где:
- Name – это произвольное имя интерфейса;
- User – имя пользователя, которое мы назначили на вкладке Secrets.
Настройка firewall
Добавим правила в наш файрвол, тем самым разрешая трафик для L2TP, два правила для IPSec и протокол Ipsec-esp:
IP => Firewall => Filter Rules => “+”.
Добавим разрешающее правило для L2TP, который работает на 1701(UDP) порту:
После нажмем правой кнопкой мыши на созданное правило и добавим комментарий, нажав строку Comment из меню:
Добавим правило для UDP портов 4500, 500:
Добавим комментарий для этого правила, как показано выше.
Разрешим протокол IPsec-esp:
Очень важен порядок расположения правил. Ваш firewall после настроек должен выглядеть примерно следующим образом:
Для более глубокого понимания работы брандмауэра рекомендуем ознакомиться со статьей MikroTik настройка firewall.
На этом настройка L2TP Server Mikrotik закончена, перейдем к настройке клиентской части (филиала).
Mikrotik, virtualization, Linux, servers, networks and more
In the previous post we have shown a Mikrotik router as a L2TP/IPSec server. In this scenario, we are using either Windows clients or mobile devices based on Android or Apple iOS operating systems. Here is a new scenario – we may have a need to use another Mikrotik device as the VPN client.
The most common scenario is that you want to connect a remote network with a main network. Using the L2TP/IPSec VPN connection, you will have in the same time the routable tunnel and the full power of IPSec encryption.
We can see the benefits from this combination. Using the routing tunnel means that we can assign the IP address to it and use it as any other network interface. In the other hand, the IPSec part will protect our tunnel with the strong encryption. Furthermore, we need to use a very simple IPSec policies as we are using the IPSec tunnel in the transport mode.
You can find the following tutorials related to the L2TP/IPSec VPN clients on my blog:
IKEv2/IPsec (VPN Reconnect)
Fast and easy — using pre shared key or certificates. IKEv2 was implemented in MikroTik RouterOS 6.39.
IKEv2 with pre shared key
Only works on macOS and iOS etc. Windows 7, 8 and 10 do not support IKEv2 pre-shared key.
# Create the IP range the users will get and name it VPN
/ip pool add name=VPN ranges=172.16.0.2-172.16.0.20
# Supply IP addresses and send DNS to the VPN user
/ip ipsec mode-config add name=cfg1 system-dns=yes address-pool=VPN address-prefix=32
# Create the IPsec peer (VPN)
/ip ipsec peer add enc-algorithm=aes-256,aes-128 exchange-mode=ike2 generate-policy=port-strict mode-config=cfg1 passive=yes secret=xxxx
1 2 3 4 5 6 7 8 |
# Create the IP range the users will get and name it VPN ip pool add name=VPN ranges=172.16.0.2-172.16.0.20 ip ipsec mode-config add name=cfg1 system-dns=yes address-pool=VPN address-prefix=32 ip ipsec peer add enc-algorithm=aes-256,aes-128exchange-mode=ike2 generate-policy=port-strict mode-config=cfg1 passive=yes secret=xxxx |
IKEv2 with username and password
Windows 7, 8 and 10 do not support EAP-only. That means EAP (Extensible Authentication Protocol) without using certificates are not possible on Windows.
IKEv2 with certificates
First we create certificates, requirements:
- Common name should contain IP or DNS name of the server (required by Windows)
- Subject Alt name should have IP or DNS of the server (required by some VPN clients)
- EKU tls-server and tls-client is required for Windows.
/certificate
add common-name=ca name=ca
sign ca ca-crl-host=2.2.2.2
add common-name=2.2.2.2 subject-alt-name=IP:2.2.2.2 key-usage=tls-server name=server1
sign server1 ca=ca
add common-name=client1 key-usage=tls-client name=client1
sign client1 ca=ca
add common-name=client2 key-usage=tls-client name=client2
1 2 3 4 5 6 7 8 |
certificate add common-name=ca name=ca sign ca ca-crl-host=2.2.2.2 add common-name=2.2.2.2subject-alt-name=IP2.2.2.2key-usage=tls-server name=server1 sign server1 ca=ca add common-name=client1 key-usage=tls-client name=client1 sign client1 ca=ca add common-name=client2 key-usage=tls-client name=client2 |
Now that we have certificates, server can be configured. Note that windows client requires modeconf, so we will use it to give out IP addresses from pool and send DNS, we also need to modify default template a little, to allow policies only from specific source addresses and generate unique level (required by multiple clients behind the same public IP):
# Create the IP range the users will get and name it VPN
/ip pool add name=VPN ranges=172.16.0.2-172.16.0.20
# Supply IP addresses and send DNS to the VPN user
/ip ipsec mode-config add name=cfg1 system-dns=yes address-pool=VPN address-prefix=32
# Create the IPsec peer (VPN)
/ip ipsec peer add auth-method=rsa-signature certificate=server1 generate-policy=port-strict \
mode-config=cfg1 passive=yes remote-certificate=none exchange-mode=ike2
1 2 3 4 5 6 7 8 9 |
# Create the IP range the users will get and name it VPN ip pool add name=VPN ranges=172.16.0.2-172.16.0.20 ip ipsec mode-config add name=cfg1 system-dns=yes address-pool=VPN address-prefix=32 ip ipsec peer add auth-method=rsa-signature certificate=server1 generate-policy=port-strict\ mode-config=cfg1 passive=yes remote-certificate=none exchange-mode=ike2 |
On your client, you should now package the CA, the client certificate and the private key in a .p12 container file, to be able to install the certificates on Windows, macOS, iOS and Android. On your Windows/macOS/Linux client, use the openssl tool to create the file client1.p12:
openssl pkcs12 -export -out client1.p12 -inkey cert_export_client1.key -in cert_export_client1.crt -certfile cert_export_ca.crt
1 | openssl pkcs12-export-out client1.p12-inkey cert_export_client1.key-incert_export_client1.crt-certfile cert_export_ca.crt |
The .
Откройте порты в брандмауэре pfSense
Нам нужно будет создать правило в разделе «Firewall / Rules / WAN» со следующей информацией:
Сохраняем и применяем изменения, следя за соблюдением этого правила.
Когда мы создаем VPN-сервер типа L2TP / IPsec, у нас будут две дополнительные вкладки в «Брандмауэр / Правила», здесь мы можем разрешить или запретить трафик в определенные подсети, определить различные расширенные правила и т. Д. Для первого подключения и во избежание возможных сбои конфигурации на уровне брандмауэра, мы рекомендуем вам создать правило «передать любое любое» и применить изменения. Позже, когда связь будет установлена, если вам нужно будет определить другие правила, вы сможете редактировать более конкретные правила, чтобы они соответствовали всем вашим требованиям.
После того, как мы успешно настроили брандмауэр, нам нужно будет настроить VPN-клиент для проверки соединения.
Настройка L2TP
В данной настройке будет минимум шагов, т.к. особых сложностей нет.
Создаётся пул адресов для VPN-клиентов в меню IP-Pool:
Создается PPP-профиль с дефолтными настройками, указывается только локальный адрес и удаленные адреса из созданного ранее пула:
В разделе PPP-Secrets создается пользователь для созданного выше profile.
И в том же разделе PPP включается L2TP-сервер:
Здесь, собственно, активируется сам сервер и указывается, что требуется использование IPsec с нужным секретом, который был задан при настройке IPsec Identities. Используется mschap2 для авторизации через L2TP. Значение required использовано для того, чтобы убедиться, что принимаются только L2TP-соединения, инкапсулированные в IPsec. Хотя на практике у меня с этим параметром получилось установить соединение с Linux-клиента без IPsec – уж не знаю, где ошибка и что не так, но для верности запретил такие подключения без шифрования ещё на уровне firewall в начале статьи.
На этом всё, настройка IPsec и L2TP-сервера на Mikrotik завершена и можно переходить к настройке клиента.
Настройка
Настройка первого маршрутизатора
Через графический интерфейс
Включить SSTP-сервер. Оставим только аутентификацию «mschap2» как наиболее надежную и отключим проверку клиентского сертификата.
Создать новый аккаунт. Для дальнейшего удобства лучше задавать имена так, что бы сразу можно было определить к кому или чему они относятся. Т. е. имена типа user1, user2, user3 и т. д. не желательны в виду того, что в случае увеличения их количества будет тяжело сопоставить реальных пользователей аккаунтов и сами аккаунты.
Создать статическую запись SSTP сервера. Это действие не обязательно, т. к. если запись не создать вручную, то при каждом подключении она будет создаваться динамически. Но при этом наличие этой записи облегчает дальнейшую настройку и диагностику.
Через консоль
/interface sstp-server server set authentication=mschap2 certificate=none enabled=yes verify-client-certificate=no
/ppp secret add name=user1 password=user1-password local-address=172.16.30.1 remote-address=172.16.30.2 profile=default service=sstp disabled=no
/interface sstp-server add name=»SSTP Server for filial1″ user=user1
Настройка второго маршрутизатора
Через графический интерфейс
Создать интерфейс для подключения к первому маршрутизатору. Здесь так же оставляем только аутентификацию «mschap2«.
Через консоль
/interface sstp-client add authentication=mschap2 connect-to=10.1.100.1 disabled=no name=»SSTP HQ connection» password=user1-password user=user1 verify-server-address-from-certificate=no verify-server-certificate=no
Настройка маршрутизации
Если на предыдущих шагах все было сделано верно, то VPN-соединение между двумя офисами было установлено, но для того, что бы обе сети могли обмениваться информацией друг с другом они должны знать друг о друге, т. е. между ними должна быть настроена маршрутизация. Для этого надо выполнить следующие шаги:
На первом маршрутизаторе
Через графический интерфейс Выполнить следующие настройки: Dst. Address: 192.168.25.0/24 (адрес сети к которой указываем маршрут) Gateway: 172.16.30.2 (интерфейс через который можно «добраться» до сети) Pref. Source: 192.168.15.1 (интерфейс с которого будут идти запросы к сети) Комментарий указать по нажатию кнопки «Comment» (не обязательно)
/ip route add comment=»route to filial1 through VPN» dst-address=192.168.25.0/24 gateway=172.16.30.2 pref-src=192.168.15.1
На втором маршрутизаторе
Через графический интерфейс Выполнить следующие настройки: Dst. Address: 192.168.15.0/24 (адрес сети к которой указываем маршрут) Gateway: 172.16.30.1 (интерфейс через который можно «добраться» до сети) Pref. Source: 192.168.25.1 (интерфейс с которого будут идти запросы к сети) Комментарий указать по нажатию кнопки «Comment» (не обязательно)
Через консоль /ip route add comment=»route to HQ through VPN» dst-address=192.168.15.0/24 gateway=172.16.30.1 pref-src=192.168.25.1
HQ — это аббревиатура от headquarter, что в переводе означает головной офис.
Примечание: Параметр Pref. Source (pref-src) не является обязательным. Он становится нужен, если количество филиалов будет более одного. Без этого параметра не будут проходить ping’и с маршрутизатора одного филиала до хостов и внутреннего интерфейса маршрутизатора другого филиала. Не будут проходить ping’и именно с маршрутизаторов, т. е. между хостами двух филиалов связь будет.
Принципы работы протокола IPsec и базовые термины
IPsec — это набор протоколов, которые можно разделить на следующие основные группы:
- Internet Key Exchange (IKE) — протоколы, которые генерируют и раздают ключи шифрования для AH и ESP;
- Authentication Header (AH) — протокол заголовка аутентификации, предназначен для проверки целостности передаваемого пакета данных (защита от изменения содержимого пакета или подмены исходного адреса);
- Encapsulating Security Payload (ESP) — защищенный протокол инкапсуляции данных, обеспечивает непосредственную защиту данных путем шифрования на общих ключах, а также имеет собственную схему аутентификации подобную AH;
IPsec может работать в двух режимах: транспортном и туннельном:
- В транспортном режиме, ESP-заголовок вставляется между IP-заголовком и полезными данными оригинального пакета, а в конец добавляется ESP-трейлер и ESP-аутентификация. Шифруются только полезные данные и ESP-трейлер. Транспортный режим может быть использован для защиты туннелей, организованных иным способом (например L2TP).
- В туннельном режиме, оригинальный ip-пакет инкапсулируется в новый и таким образом шифруется весь исходный пакет. Туннельный режим используется для создания VPN.
При создании туннеля создается связь, которая называется SA (Security Association).Каждая связь SA создается для однонаправленного соединения. Так как данные необходимо передавать в двух направлениях, то SA создаются парами. Одна пара SA создается для протокола AH, другая для ESP. Созданные SA хранятся в базе данных узлов (роутеров Mikrotik), которые создают туннель.
На каждом узле имеется база данных политики безопасности (Security Policy Database).Политики содержат следующие настройки:
- алгоритмы шифрования/дешифрования;
- способы идентификация узла: pre-shared keys или RSA-сертификат;
- как часто повторять идентификацию узла и менять ключ шифрования;
- использовать режим туннеля или транспорта;
- контрольные суммы целостности данных;
- использовать AH, ESP или оба;
- опция PFS и выбор группы Deffie Hellman.
Установка соединения IPsec происходит в два этапа: Phase 1 и Phase 2.
Первоначальная аутентификация сторон и обмен общими секретными ключами происходит с помощью протокола IKE. Процесс работы протокола IKE состоит из двух этапов:
Phase 1Узлы согласовывают алгоритмы для последующего обмена информацией и аутентифицируются. Происходит обмен общими ключами по алгоритму Deffie Hellman. В результате создается безопасный канал IKE SA.
Phase2Генерируются ключи шифрования IPsec, согласовываются политики. В результате создается соединение IPsec SA
В новой версии протокола IKEv2 процесс происходит за одну фазу в несколько шагов.
Mikrotik devices with RouterOS v5.26 and earlier
Our second Mikrotik device uses RouterOS v5.26. On all RouterOS versions up to 5.26, we can set the L2TP/IPSec connection, but we need to make a few more steps.
I will reveal the secret to you. We need to make the IPSec part manually. This is very similar with this scenario when one side is behind the NAT. But you will see.
The first step is the same. Open the PPP menu. We will see the PPP window, where we can choose the drop-down menu with the list of available PPP interfaces. We will again select the L2TP client.
The newly opened window looks familiar, as it’s a very similar to that in RouterOS v6. The difference is that we don’t have the IPSec section.
Fill all necessary fields and click on the button . Mikrotik will create the new VPN interface and in the short while, we will see the connection status update.
Congratulations again! You’ve successfully made the L2TP tunnel. Alas, we have the tunnel without encryption.
However, the encryption isn’t the problem for us. We knew how to setup the IPSec tunnel. Therefore, we will configure it in a minute. In addition, don’t forget to write down all necessary parameters. The best way is to fill one document about your IPSec configuration.
We need to define the IPSec peer. The biggest change here is that the mode of IPSec operation is main l2tp.
The next step is the IPSec policy. We need to make it manually, too. This is the transport mode. Therefore, the source address will be the same as the SA source address.
On the Action tab we must enter the same IPs as on the General tab. In addition, we need to leave the checkbox Tunnel unchecked.
Please, pay attention that you will use the Default proposal here. You should check it’s settings, as there can be differences between older and newer settings. The newer versions by default use the SHA1 authentication algorithm, while older versions use 3DES.
We will switch to the Installed SAs tab and we can see that tunnel is established.
We will check again the Contoso side. Our new router is connected using IPSec protocol.
The main difference is that this tunnel is not limited only to the port 1701 UDP, used for the L2TP tunneling. If you like, you can specify the port number on the General tab on the client router. Then our IPSec tunnel will protect only the L2TP traffic.
We can also see the SAs for this connection on the Installed SAs tab. We left the default IPSec proposal settings on the client side and the encryption algorithm is ancient 3DES.
Для чего нужен VPN-сервер L2TP / IPsec?
VPN-сервер в нашем pfSense позволит нам получить удаленный доступ к различным подсетям, которые мы настроили, он также позволит нам перенаправить весь интернет-трафик на VPN-сервер для выхода в Интернет через него. Благодаря конфигурации VPN-сервера мы сможем безопасно подключаться к незащищенной сети, потому что весь трафик от источника до VPN-сервера зашифрован и аутентифицирован.
L2TP (Layer 2 Tunneling Protocol) — один из наиболее широко используемых протоколов VPN, он использует протокол PPP для подключения различных каналов, кроме того, он включает механизмы аутентификации PPP, такие как PAP и CHAP, в дополнение к поддержке использование серверов RADIUS для аутентификации клиентов. Этот тип VPN Протокол является многопротокольным и позволяет получить доступ к удаленным локальным сетям. Отрицательной стороной является то, что он не представляет надежной криптографии, поэтому использовать его небезопасно. Он разрешает аутентификацию только между конечными точками туннеля, но не для каждого из пакетов, которые проходят через него, то же самое происходит с целостностью пакетов, это не проверяется. Кроме того, L2TP не шифрует трафик от источника к месту назначения.
Учитывая все это, организация IETF приняла решение использовать криптографические протоколы IPsec в сочетании с L2TP, чтобы обеспечить функции конфиденциальности, аутентификации и целостности туннеля L2TP. По этой причине мы всегда найдем этот протокол, записанный как «L2TP / IPsec» в операционных системах, поскольку он использует оба протокола одновременно.
Как только у нас будет сводка о том, как работают оба протокола VPN, мы продолжим настройку. Имея два протокола для настройки, L2TP и IPsec, мы четко разделим конфигурацию на две части.
Настройки IPsec-сервера на первом роутере
1. Настройка IPsec-пира, IPsec политика будет создаваться автоматически, при подключении клиента (с динамическим созданием политики, роутер может принимать подключения от множества VPN-клиентов без донастройки. В данном случае VPN-канал поднимается между двумя роутерами и можно настроить статическую политику, как на втором роутере). Пароль, который будет использоваться при аутентификации и генерации секрета для шифрования соединения, задается в параметре secret
/ip ipsec peer
add address=0.0.0.0/0 port=500 auth-method=pre-shared-key hash-algorithm=md5 enc-algorithm=aes-256 generate-policy=port-strict exchange-mode=main nat-traversal=no secret=»ipsec-secret» send-initial-contact=no dpd-interval=15s dpd-maximum-failures=2
2. Настройка алгоритмов для шифрования и подписи соединения
/ip ipsec proposal
set defaul auth-algorithms=sha1 enc-algorithms=aes-128 name=default
ПРИМЕЧАНИЕ: 1. Если не указать значение address=0.0.0.0/0 для peer, оно будет подставлено автоматически, но работать IPsec не будет — баг RouterOS.
2. nat-traversal=yes для peer следует указывать, только если часть клиентов будет подключаться из-за NAT.