Обзор IPSec в Mikrotik

    IPSec (IP Security) — набор протоколов и алгоритмов для шифрования данных в IPv4 и IPv6 сетях. Звучит не сложно, но IPSec не устанавливает четких правил для шифрования трафика, вместо этого разработчики реализуют набор инструментов (протоколов и алгоритмов), используя которые администратор создает защищенный канал для данных.


    Я хочу затронуть тему IPSec в RouterOS немного глубже простого HOWTO, с минимальным погружением в теорию и примерами по настройке и отладки IPSec. Это не гайд и без практики на тестовом стенде не рекомендуется приступать к настройке реальных туннелей и VPN серверов.


    Преимущества и недостатки IPSec


    Сильные стороны:


    • Работает на сетевом уровне модели OSI
    • Может шифровать исходный пакет целиком либо от транспортного уровня и выше
    • Присутствует механизм преодоления NAT
    • Большой набор алгоритмов шифрования и хеширования трафика, на выбор
    • IPSec — набор открытых, расширяемых стандартов
    • В случае с Mikrotik, не требует покупку дополнительных плат или лицензий

    Слабые стороны:


    • Сложность
    • Различная терминология и инструменты конфигурации у различных вендеров
    • Использование сильных алгоритмов шифрования требует хорошие вычислительные мощности
    • Легко обнаруживается DPI

    Протоколы в составе IPSec



    Глобально, все протоколы, с которыми вы будете иметь дело при конфигурации, можно разделить на две группы: протоколы обмена ключами и протоколы защиты данных.


    Протоколы обмена ключами (IKE)
    Основная задача — аутентифицировать участников соединения и договориться о параметрах и ключах шифрования для защиты передаваемой информации.


    • IKE (Internet Key Exchange) — определен в 1998 году. Многие возможности (например преодоление NAT) были добавлены позже в виде дополнений и могут быть не реализованы у различных вендеров. Основой для согласования ключей является протокол ISAKMP.
    • IKEv2 (Internet Key Exchange version 2) — последняя редакция от 2014 года. Является развитием протокола IKE, в котором были решены некоторые проблемы, упрощен механизм согласования ключей, расширения (NAT-T, Keepalives, Mode Config) стали частью протокола.

    На практике большая часть IPSec соединений реализуется с использованием IKE, в силу устаревшего оборудования, либо нежелания что-то менять у администраторов.


    Протоколы защиты данных (ESP, AH)
    Основная задача — защищать данные пользователя.


    • ESP (Encapsulating Security Payload) — шифрует и частично аутентифицирует передаваемые данные
    • AH (Authentication Header) — аутентифицирует пакет целиком (за исключением изменяемых полей), не шифрует данные, но позволяет убедиться, что пакет не был изменен при передачи по сети

    Порядок установки IPSec соединения



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


    1. Один из пиров инициализирует соединение IPSec
    2. Происходит обмен ключевой информацией, аутентификация пиров, согласование параметров подключения
    3. На основе полученной ключевой информации формируется вспомогательный шифрованный туннель
    4. Используя шифрованный туннель пиры определяют параметры шифрования данных и обмениваются информацией для генерации ключей
    5. Результатом работы предыдущей фазы является набор правил и ключи для защиты данных (SA)
    6. Периодически пиры производят обновление ключей шифрования

    Одним из ключевых понятий в IPSec является SA (Security Association) — это согласованный пирами набор алгоритмов шифрования и хеширования информации, а также ключи шифрования.


    Иногда можно встретить разделение на:


    • ISAKMP SA — параметры и ключи относящиеся к вспомогательному туннелю
    • Data SA (или просто SA) — параметры и ключи относящиеся к шифрованию трафика

    Порядок работы протоколов согласования ключей


    Протокол IKE может работать в двух режимах: основном (main) и агрессивном (aggressive), протокол IKEv2 содержит один режим.


    IKE Main



    Первая фаза состоит из шести пакетов:
    1-2: Согласование параметров шифрования вспомогательного туннеля и различных опции IPSec
    3-4: Обмен информацией для генерации секретного ключа
    5-6: Аутентификация пиров используя вспомогательный шифрованный канал


    Вторая фаза состоит из трех пакетов:
    1-3: Используя шифрованный вспомогательный канал. Согласование параметров защиты трафика, обмен информацией для генерации секретного ключа


    IKE Aggressive



    Певая фаза состоит из трех пакетов:
    1: Отправка предложения для установки вспомогательного шифрованного канала и информации для генерации секретного ключа
    2: Ответ на предложение, информация для генерации секретного ключа, данные для аутентификации
    3: Данные для аутентификации


    Вторая фаза состоит из трех пакетов:
    1-3: Используя шифрованный вспомогательный канал. Согласование параметров защиты трафика, обмен информацией для генерации секретного ключа


    В агрессивном режиме инициатор отправляет только один набор параметров в предложении. Обмен информацией для аутентификации пиров происходит до установки защищенного вспомогательного туннеля. Агрессивный режим согласуется быстрее, но менее безопасен.


    IKEv2



    В IKEv2 фазы получили имена: IKE_SA_INIT и IKE_AUTH. Но если ниже по тексту я говорю про Phase1 и Phase2, то это относится и к фазам IKEv2.


    Каждая фаза IKEv2 состоит из двух пакетов:
    IKE_SA_INIT: Согласование параметров шифрования вспомогательного туннеля, обмен информацией для генерации секретного ключа


    IKE_AUTH: используя шифрованный вспомогательный канал. Аутентификация пиров, согласование параметров защиты трафика, обмен информацией для генерации секретного ключа


    Security Assotiations Database (SAD)


    Результатом работы IKE (и IKEv2) являются Security Assotiations (SA), определяющие параметры защиты трафика и ключи шифрования. Каждый SA является однонаправленным и соединение IPSec содержит пару SA. Все SA хранятся в базе SAD и доступны администратору для просмотра и сброса.


    Инкапсуляция данных



    IPSec предоставляет два варианта инкапсуляции данных:


    • Транспортный режим — защищается только полезную нагрузку пакета, оставляя оригинальный заголовок. Для построения туннелей транспортный режим обычно используется в связке с ipip или gre, полезная нагрузка которых уже содержит весь исходный пакет.
    • Туннельный режим — полностью инкапсулирует исходный пакет в новый (по аналогии с gre или ipip). Но для туннельного ipsec не создается явного интерфейса в системе, это может быть проблемой если используется динамическая или сложная статическая маршрутизация.

    Security Policy Database (SPD)


    База правил, определяющих какой трафик необходимо подвергать шифрованию, протокол защиты данных, тип инкапсуляции и ряд других параметров.
    Положение проверки пакета SPD можно отобразить на схеме Packet Flow.



    Преодоление NAT


    IPSec использует протоколы сетевого уровня для передачи данных, которые не может обработать NAT. Для решения проблемы используется протокол NAT-T (расширение в IKE и часть IKEv2). Суть NAT-T в дополнительной инкапсуляции пакетов IPSec в UDP пакеты, которые обрабатывает NAT.


    IPSec в Mikrotik


    IPSec доступен бесплатно на любом устройстве под управлением RouterOS с установленным пакетом Security.


    Аппаратное шифрование


    Для разгрузки CPU в некоторые модели маршрутизаторов MikroTik добавляют аппаратное ускорение шифрования, полный список можно найти на wiki.
    Наиболее бюджетные варианты: RB750Gr3, RB3011, HAP AC^2.


    Своими силами проверял скорость IPSec между двумя RB1100AHx2 и между двумя RB750Gr3.


    Для достижения максимального результата на RB1100AHx2 необходимо:


    • Использовать 11 порт, напрямую подключенный к CPU и настроить одно ядро CPU для обработки трафика 11 порта
    • Использовать only-hardware-queues на интерфейсах, отключить RPS
    • Задействовать Layer3 FastPath (около 800mb/sec), либо исключить IPSec трафик из conntrack (около 700mb/sec)
      Без описанных манипуляций на самом медленном порту (ether13) удается получить ~170Mb/sec, на обычном ~400Mb/sec.

    На RB750Gr3 без оптимизаций около 200Mb/sec.


    Маршрутизаторы на одноядерных Qualcomm показывают результат 10-40mb/sec в зависимости от модели, оптимизаций и загруженности другими процессами.


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


    Различия 6.42.X и 6.43.X


    В зависимости от используемой версии RouterOS меню конфигурации IPSec будет различаться.





    В testing версии уже есть новые изменения, так что читайте Release Notes перед обновлением.



    Конфигурация IPSec



    Меню [IP]->[IPSec] не такое страшное, как кажется на первый взгляд. Из схемы видно, что основными пунктами конфигурации являются: Peers и Profiles.
    Вкладки Remote Peers и Installed SAs являются информационными.


    Peers и Peers Profiles


    Конфигурация пиров IPSec для установки IKE соединения и создания вспомогательного защищенного туннеля.


    image


    Настройка удаленных пиров IPSec



    Примечания
    • Начиная с 6.43 RouterOS ругается при использовании PSK без дополнительной аутентификации. Если не хочется дополнительно настраивать ключи, сертификаты или xAuth можно перейти на IKEv2 или игнорировать предупреждение.
    • В качестве пиров можно указывать конкретные IP либо подсети (актуально для Client-Server VPN)
    • При наличии конфликтующих правил, для соединения с пиром будет использовано правило с более точной подсетью (по аналогии с routes)
    • Аутентификация xAuth и rsa key не работает в IKEv2
    • Для IKEv2 Mikrotik сделали свою реализацию xAuth не совместимую с другими платформами
    • Passive режим обычно используется для создания Client-Server VPN (L2TP/IPsec или IKEv2 mode config), но может быть полезен при подключении большого числа Site-to-Site туннелей к одной точке, для снижения паразитного трафика.
    • Если планируете использовать xAuth, то "сервер" должен быть passive. Пользователи для сервера создаются в [IPSec]->[Users]
    • При использовании Generate policy выбирайте режим port-strict

    Настройка профилей (Proposals) для согласования Phase 1


    image



    Примечания
    • Дополнительные опции для IKE стали частью IKEv2, настройки игнорируются
    • Соотношение групп DH с их номерами (номера групп используются у других вендеров)
    • При отправке предложений (Proposals) система сортирует пары алгоритм+группа dh от более стойких к менее стойким

    Policies и Policy Proposals


    Политики проверяют проходящие пакеты на соответствие условиям и применяют указанные действия. Если вернетесь к Packet flow, то блоки с IPSec Policy и есть сверка с политиками. В действиях задается: протокол защиты IPSec (ESP или AH), предложения для согласования SA, режим инкапсуляции.
    image


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


    Настройка политик


    Примчания
    • Обычно не требуется указывать конкретный Src. и Dst. Port, но в целом возможность шифровать трафик отдельного приложения интересна
    • В списке Protocols представлены не все протоколы ip (например нет gre), можно указать номер нужного протокола вручную.
    • Шаблоны не являются политиками! Они используются, если в конфигурации пира установлено generate-policy
    • Что делать, если определенные SA для политики не были найдены. Раньше с L2TP/IPSec была проблема, когда несколько клиентов из-за одного NAT не могли подключиться (при использовании IKE), данный баг решается (при условии, что эти клиенты не windows) если установить level=unique. Иначе переходите на IKEv2
    • При настройке политик используйте [Safe mode], одно неловкое движение и вы рискуете потерять доступ к роутеру по Level3

    Настройка предложений (Proposals) для согласования SA



    Groups


    Используются для связи шаблонов политик и пиров.


    image


    В одной из старых версий RouterOS был баг с нерабочей группой default.


    Mode Config


    Отправка и получение параметров IP без использования дополнительных протоколов. Позволяет создавать самодостаточный Client-to-Server VPN только средствам IPSec.




    Keys и Users


    Используются для расширенной аутентификации пиров.
    Keys
    Ключи RSA: генерация, импорт, экспорт. Не поддерживаются в IKEv2.



    Users
    База данных пользователей xAuth, для "сервера". Клиент указывает настройки xAuth в конфигурации пира. Возможно пересылать аутентификацию xAuth на RADIUS сервер.



    Remote Peers


    Список всех пиров устанавливающих и установивших вспомогательный туннель (Phase 1). Можно удалять пиров для обновления ключей вспомогательного туннеля.


    image


    image


    Installed SAs


    база данных SAD или список всех согласованных SA. Можно посмотреть используемые алгоритмы защиты данных и ключи.


    image


    image


    Флаг Hardware AEAD указывает на использование аппаратного шифрования.


    image


    Администратор может сбросить SA, но только одновременно все одного типа (esp или ah).


    IPSec и Firewall


    В Firewall можно проверить соответствует трафик входящей или исходящей IPSec политики или нет. Очевидное применение — L2TP/IPSec, можно запретить установку L2TP соединений если трафик не был предварительно зашифрован.



    Протоколы и порты, используемые в IPSec


    • IKE — UDP:500
    • IKEv2 — UDP:4500
    • NAT-T — UDP:4500
    • ESP — ipsec-esp(50)
    • AH — ipsec-ah(51)

    IPSec и Endpoinds


    А теперь о наболевшем…
    На wiki mikrotik есть таблицы с алгоритмами хеширования и шифрования для: Windows, iOS, OS-X.


    Про встроенный в android vpn клиент я информации не нашел, но в целом он работает с proposals от windows. Поддержки IKEv2 в Android нет, необходимо использовать StrongSwan.


    Примеры конфигурации


    Схема и базовая конфигурация для примеров с Site-to-Site туннелями:



    #Mikrotik1
    /ip address
    add address=10.10.10.10/24 interface=ether1 network=10.10.10.0
    add address=192.168.100.1/24 interface=ether2 network=192.168.100.0
    /ip firewall nat
    add action=masquerade chain=srcnat out-interface=ether1
    /ip route
    add distance=1 gateway=10.10.10.1 dst-address=0.0.0.0/0
    
    #Mikrotik2
    /ip address
    add address=10.20.20.20/24 interface=ether1 network=10.20.20.0
    add address=192.168.200.1/24 interface=ether2 network=192.168.200.0
    /ip firewall nat
    add action=masquerade chain=srcnat out-interface=ether1
    /ip route
    add distance=1 gateway=10.20.20.1 dst-address=0.0.0.0/0

    IPSec в туннельном режиме



    Пошаговая конфигурация:


    1. Создаем Proposals для IKE Phase1
    2. Создаем пира. Указываем адрес, proposals, режим обмена, ключ PSK. Я выбрал IKEv2, можно использовать main/agressive по желанию
    3. Создаем Proposals для SA
    4. Указываем подсети между которыми создаем туннель
    5. Указываем адреса SA, туннельный режим и proposals для шифрования трафика
    6. Редактируем правило NAT

    Mikrotik1


    Консольный вариант:


    #1
    /ip ipsec peer profile
    add dh-group=modp2048 enc-algorithm=aes-128 hash-algorithm=sha256 name=ipsec-tunnel-ike nat-traversal=no
    
    #2
    /ip ipsec peer
    add address=10.20.20.20/32 exchange-mode=ike2 profile=ipsec-tunnel-ike secret=test-ipsec
    
    #3
    /ip ipsec proposal
    add auth-algorithms=sha256 enc-algorithms=aes-256-cbc name=ipsec-tunnel-sa
    
    #4-5
    /ip ipsec policy
    add dst-address=192.168.200.0/24 proposal=ipsec-tunnel-sa sa-dst-address=10.20.20.20 sa-src-address=10.10.10.10 src-address=192.168.100.0/24 tunnel=yes
    
    #6
    /ip firewall nat
    set 0 ipsec-policy=out,none

    Mikrotik2


    Консольный вариант:


    #1
    /ip ipsec peer profile
    add dh-group=modp2048 enc-algorithm=aes-128 hash-algorithm=sha256 name=ipsec-tunnel-ike nat-traversal=no
    
    #2
    /ip ipsec peer
    add address=10.10.10.10/32 exchange-mode=ike2 profile=ipsec-tunnel-ike secret=test-ipsec
    
    #3
    /ip ipsec proposal
    add auth-algorithms=sha256 enc-algorithms=aes-256-cbc name=tets-ipsec-sa
    
    #4-5
    /ip ipsec policy
    add dst-address=192.168.100.0/24 proposal=tets-ipsec-sa sa-dst-address=10.10.10.10 sa-src-address=10.20.20.20 src-address=192.168.200.0/24 tunnel=yes
    
    #6
    /ip firewall nat
    set 0 ipsec-policy=out,none

    Причем тут NAT?

    Для работы в туннельном режиме необходим фейковый маршрут до удаленной подсети, либо маршрут по умолчанию, иначе пакеты не пройдут дальше Routing decision. С первым вариантом проблем обычно нет, а вот с дефолтным маршрутом и Source NAT (первое и второе присутствует на подавляющем большинстве домашних и офисных маршрутизаторов) будут проблемы.


    Вспоминаем Packet Flow. Пакеты проходят Source NAT раньше чем политики IPSec, правило с masquerade ничего не знает о том что трафик предназначен для отправки в "эфимерный" туннель и будет транслировать заголовки пакетов подлежащих отправки в IPSec, когда пакет с измененным заголовком попадет на проверку в Policies адрес источкина в заголовке не будет подходить под правило и пакет улетит на default route, который увидев адрес назначения из приватной сети вероятнее всего его отбросит.


    Есть несколько решений проблемы:


    • Использование фейкового маршрута
    • Использование дополнительного accept правила перед SourceNAT
    • Подвергать src-nat только те пакеты, для которых нет политик IPSec (в примере)
    • Исключать трафик из connection tracking средствами RAW

    Проверка установленного соединения
    image


    1. Видим соседа в Remote Peers
    2. Видим установленные SA (счетчики трафика не будут меняться, пока вы его не пустите)
    3. В политике статус Established и флаг (A)ctive

    IPIP/IPSec



    Предварительная настройка IPIP туннеля:


    #Mikrotik1
    #Настройка интерфейса ipip
    /interface ipip
    add allow-fast-path=no clamp-tcp-mss=no name=ipip-vpn remote-address=10.20.20.20
    #Установка ip адреса на ipip интерфейс
    /ip address
    add address=10.30.30.1/30 interface=ipip-vpn
    #Статический маршрут до удаленной подсети
    /ip route
    add distance=1 dst-address=192.168.200.0/24 gateway=10.30.30.2
    
    #Mikrotik2
    #Все аналогично, меняются только адреса и подсети
    /interface ipip
    add allow-fast-path=no clamp-tcp-mss=no name=ipip-vpn remote-address=10.10.10.10
    /ip address
    add address=10.30.30.2/30 interface=ipip-vpn
    /ip route
    add distance=1 dst-address=192.168.100.0/24 gateway=10.30.30.1

    Пошаговая конфигурация IPSec:


    1. Создаем Proposals для IKE Phase1
    2. Создаем пира. Указываем адрес, proposals, режим обмена, ключ PSK
    3. Создаем Proposals для SA
    4. Указываем подсети между которыми создаем туннель
    5. Указываем адреса SA, тип трафика который будем шифровать и proposals

    Mikrotik1


    Консольный вариант:


    #1
    /ip ipsec peer profile
    add dh-group=modp2048 enc-algorithm=aes-128 hash-algorithm=sha256 name=ipsec-tunnel-ike nat-traversal=no
    
    #2
    /ip ipsec peer
    add address=10.20.20.20/32 exchange-mode=ike2 profile=ipsec-tunnel-ike secret=test-ipsec
    
    #3
    /ip ipsec proposal
    add auth-algorithms=sha256 enc-algorithms=aes-256-cbc name=ipsec-tunnel-sa
    
    #4-5
    /ip ipsec policy
    add dst-address=10.20.20.20/32 proposal=ipsec-tunnel-sa protocol=ipencap src-address=10.10.10.10/32 sa-dst-address=10.20.20.20 sa-src-address=10.10.10.10

    Mikrotik2


    #1
    /ip ipsec peer profile
    add dh-group=modp2048 enc-algorithm=aes-128 hash-algorithm=sha256 name=ipsec-tunnel-ike nat-traversal=no
    
    #2
    /ip ipsec peer
    add address=10.10.10.10/32 exchange-mode=ike2 profile=ipsec-tunnel-ike secret=test-ipsec
    
    #3
    /ip ipsec proposal
    add auth-algorithms=sha256 enc-algorithms=aes-256-cbc name=tets-ipsec-sa
    
    #4-5
    /ip ipsec policy
    add dst-address=10.10.10.10/32 proposal=tets-ipsec-sa protocol=ipencap src-address=10.20.20.20/32 sa-dst-address=10.10.10.10 sa-src-address=10.20.20.20

    Для невнимательных, реальная разница конфигурации туннельного и транспортного режима в IPSec Policies:
    image


    Проверка соединения аналогична туннельному режиму.


    L2TP/IPSec


    Предыдущие примеры хорошо подходят для создания постоянных VPN между двумя пирами, со статическими внешними IP адресами.


    Если адрес одного из пиров динамический (и обычно находится за NAT'ом), необходимо использовать другую Client-to-Server VPN.
    image


    Предварительная конфигурация L2TP:


    #Создание пула адресов для клиентов
    /ip pool
    add name=pool-l2tp ranges=192.168.77.10-192.168.77.20
    #Создание профиля для клиентов
    /ppp profile
    add change-tcp-mss=yes local-address=192.168.77.1 name=l2tp-ipsec only-one=yes remote-address=pool-l2tp use-compression=no use-encryption=no use-mpls=no use-upnp=no
    #Создание учетных записей
    /ppp secret
    add name=user1 password=test1 profile=l2tp-ipsec service=l2tp
    add name=user2 password=test2 profile=l2tp-ipsec service=l2tp
    add name=user3 password=test3 profile=l2tp-ipsec service=l2tp
    #Включение сервера L2TP (без автонастройки ipsec)
    /interface l2tp-server server
    set authentication=chap,mschap2 default-profile=l2tp-ipsec enabled=yes

    Почему я игнорирую автонастройку IPSec

    В конфигурации ipip,gre,eoip,l2tp присутствует автонастройка ipsec соединения, по сути система создает динамические правила для Peers и Policies за вас, но во-первых — мы не ищем легких путей, во-вторых при обновлении с 6.42 на 6.43 автоматически созданные туннели ломались и не факт, что этого не повторится.


    Пошаговая конфигурация IPSec:


    1. Создаем новую группу (можно использовать default)
    2. Создаем Proposals для IKE Phase1
    3. Создаем пира, точнее подсеть. Ругается на PSK ключ, но если мы имеем дело с windows в качестве клиента, то у нас на выбор: Сертификаты или PSK.
    4. Устанавливаем passive=yes и send-init-contact=no, в generate-policy=port-strict (принимать порт от клиента)
    5. Создаем Proposals для SA
    6. Создаем шаблон для генерации политик
    7. Указываем proposal для SA

    Конфигурация Mikrotik

    image
    На скриншоте ошибка — указывать dst. port и src. port не нужно


    Консольный вариант:


    #1
    /ip ipsec policy group
    add name=l2tp-ipsec
    
    #2
    /ip ipsec peer profile
    add dh-group=modp1024 enc-algorithm=aes-256 hash-algorithm=sha256 name=l2tp-ipsec-ike
    
    #3-4
    /ip ipsec peer
    add address=0.0.0.0/0 generate-policy=port-strict passive=yes policy-template-group=l2tp-ipsec profile=l2tp-ipsec-ike secret=secret-ipsec-pass send-initial-contact=no
    
    #5
    /ip ipsec proposal
    add auth-algorithms=sha256,sha1 enc-algorithms=aes-256-cbc,aes-128-cbc name=l2tp-ipsec-sa pfs-group=none
    
    #6-7
    /ip ipsec policy
    add dst-address=0.0.0.0/0 group=l2tp-ipsec proposal=l2tp-ipsec-sa protocol=udp src-address=0.0.0.0/0 template=yes

    Конфигурация firewall для создания L2TP подключений только после IPSec


    /ip firewall filter
    #Разрешаем IKE, NAT-T и ipsec-esp
    add chain=input protocol=17 dst-port=500,4500 action=accept
    add chain=input protocol=50 action=accept
    
    #Разрешаем L2TP, только если есть политика ipsec для данного трафика
    add chain=input protocol=17 dst-port=1701 ipsec-policy=in,ipsec action=accept
    add chain=input protocol=17 dst-port=1701 action-drop

    IKEv2 VPN


    Вариант с L2TP является популярным, но благодаря mode config можно настроить VPN сервер используя только IPSec. Это перспективный тип VPN, но пока редко используемый, поэтому помимо конфигурации серверной части, я приведу пример настройки клиента strongSwan на android.


    image


    Конечно, не все так радужно. Большинство "пользовательских" ОС (в частности Windows и Android) согласны работать с таким VPN только при условии аутентификации по сертификатам или EAP.


    Сертификаты — это мое слабое место, если кто в курсе как правильно сгенерировать самоподписные сертификат который windows импортирует и будет использовать в соединении — пишите в комментарии.


    Предварительная генерация сертификатов:


    #Root CA и сапомодпись
    /certificate add name=ca common-name="IKEv2 CA" days-valid=6928
    /certificate sign ca ca-crl-host=<IP роутера>
    
    #Сертификат для сервера vpn
    /certificate add common-name=<IP роутера> subject-alt-name=IP:<IP роутера> key-usage=tls-server name=vpn days-valid=6928
    
    #Подпись серверного сертификата
    /certificate sign vpn ca=ca
    
    #Сертификат для клиента
    #Клиенты с одним сертификатам не смогут работать одновременно, поэтому генерируйте по одному для каждого
    #Для отмены доступа необходимо сделать Revoke клиентского сертификата
    /certificate add common-name=client key-usage=tls-client name=client days-valid=6928
    
    #Подпись клиентского сертификата
    /certificate sign client ca=ca

    Пошаговая конфигурация IKEv2 VPN:


    1. Создаем пул адресов для раздачи клиентам
    2. Создаем профиль mode config для раздачи параметров IP клиентам
    3. Создаем группы для связи Peers и шаблонов policies
    4. Создаем Proposals для IKE Phase1
    5. Создаем профиль для подключения пиров. Аутентификация через сертификаты, протокол IKEv2, пассивный режим
    6. Указываем профиль mode config, группу из 3 шага и включаем генерацию политик
    7. Создаем Proposals для SA
    8. Создаем шаблон для генерации политик
    9. Указываем Proposals для SA

    Настройка Mikrotik

    image


    #1
    /ip pool
    add name=pool-ike ranges=192.168.77.10-192.168.77.20
    
    #2
    /ip ipsec mode-config
    add address-pool=pool-ike address-prefix-length=32 name=ikev2-vpn static-dns=77.88.8.8 system-dns=no
    
    #3
    /ip ipsec policy group
    add name=ikev2-vpn
    
    #4
    /ip ipsec peer profile
    add enc-algorithm=aes-256,aes-128 hash-algorithm=sha256 name=ikev2-vpn
    
    #5-6
    /ip ipsec peer
    add address=0.0.0.0/0 auth-method=rsa-signature certificate=vpn exchange-mode=ike2 generate-policy=port-strict mode-config=ikev2-vpn passive=yes policy-template-group=ikev2-vpn profile=ikev2-vpn send-initial-contact=no
    
    #7
    /ip ipsec proposal
    add auth-algorithms=sha256,sha1 enc-algorithms=aes-256-cbc,aes-128-cbc name=ikev2-vpn
    
    #8-9
    /ip ipsec policy
    add dst-address=0.0.0.0/0 group=ikev2-vpn proposal=ikev2-vpn src-address= 0.0.0.0/0 template=yes

    Конфигурация strongSwan на android.

    Предварительно необходимо перенести client и ca сертификаты на телефон.
    https://habrastorage.org/webt/tp/pk/ad/tppkadaifd1k7xi6hf3jxgg7vcs.png


    Для глазастых: Крестик около wi-fi стоит т.к. большая часть системных приложений заблокирована средствами AFWall+.


    Если соединение прошло успешно появятся: динамическая политика, запись в remote Peers и пара SA.


    image


    image


    image


    У RouterOS x86 demo лицензии нет ограничений на число IPSec туннелей, включая IKEv2 VPN. Можно развернуть RouterOS x86 demo (не путайте с RouterOS CHR free, там все грустно) на VPS и получить личный VPN сервер с минимальным напрягом по администрированию, без покупки лицензии на RouterOS или RouterOS CHR.


    Пара слов про анализ логов IPSec


    Логи в Mikrotik — отдельная история, да иногда они достаточно подробные для анализа проблемы, но отсутствие банальных возможностей: очистить, скопировать, найти вынуждает устанавливать отдельный syslog сервер.


    Что касается IPSec, вот вариант быстрого анализа логов (оставляем только нужное на отдельной вкладке):


    image


    /system logging action
    add memory-lines=100000 name=ipsec target=memory
    /system logging
    add action=ipsec topics=ipsec,error
    add action=ipsec topics=ipsec,debug,!packet
    add action=ipsec topics=ipsec,info

    И пара примеров типичных проблем с конфигурацией IPSec:


    Проблема согласования Proposals на Phase1

    image


    1. Читаем сообщение об ошибке. Проблема при согласовании Proposals на первой фазе.
    2. Смотрим выше, роутер сам подсказывает что прислал пир, а что настроено локально

    Проблема согласования proposals IKE_SA_INIT

    В логах вы увидите примерно следующее:



    Анализируем трафик


    В запросе можно посмотреть proposals от пира:



    В ответе видим, что не найдено подходящих proposals:



    Проблема согласования Proposals для SA


    Роутер подсказывает о ошибке proposals на phase2 и показывает что настроено локально, а что удаленно.


    Проблема согласования Proposals IKE_AUTH


    Видим, что произошло соединение и аутентификация пиров, но дальше ошибка proposals. В debug подробностей не увидите, в wireshark тоже (трафик IKE_AUTH зашифрован).


    Ошибка аутентификации PSK

    Для IKE:



    Для IKEv2:


    Неправильный режим IKE

    image
    Видим, что Phase1 рвется по таймауту, хотя пакеты между пирами ходят. Но размер входящего пакета значительно больше, если проанализировать через wireshark, то увидим, что удаленный пир использует aggressive mode.



    Видим, что от нас пакеты отправляются на UDP:500, а приходят на UDP:4500 причем довольно крупные. Тут у удаленного пира стоит режим IKEv2.


    И напоследок почитайте раздел troubleshooting из wiki. И весь материал про IPSec желателен для ознакомления, я описал только базовый набор инструментов и настроек.

    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 52

      0
      Отличная и основательная статья.
      Если бы она появилась года 3 тому назад, то сэкономила мне кучу нервных клеток.
      Пришлось до описанного доходить своей головой…
        0
        Спасибо. Было бы еще прекрасно добавить примеры конфигов strongswan для линукса, а то с примерами из официальной wiki у меня не заработало. Еще я использую для сервера ikev2 сертификаты от letsencrypt, чтобы не приходилось добавить самоподписанные сертификаты в клиенсткую систему. Нет ли на микротик клиента letsencrypt?
          +1
          Я примеры для strongswan/libreswan тащил из официальных тест-сюитов (напр., www.strongswan.org/testing/testresults/swanctl/rw-cert ). И все получалось!
          А в вики… ну, outdated или попросту неполная инфа

          Нет ли на микротик клиента letsencrypt?

          думаю, что это решаемо. Либо напрямую через микротиковский скриптинг, либо через дополнительную прослойку (придется свой (микро-)сервис писать с rest api).
          0
          Сертификаты — это мое слабое место, если кто в курсе как правильно сгенерировать самоподписные сертификат который windows импортирует и будет использовать в соединении — пишите в комментарии.
          Честно говоря, я сам не в курсе подробностей, но есть проект Algo VPN — набор плейбуков Ansible для автоматического разворачивания VPN (IPsec IKEv2 + WireGuard), вот он генерирует рабочие сертификаты и упаковывает их в Powershell-скрипт для автоматической установки, можно подсмотреть, как это сделано там.
            +1

            Отличная инструкция, пригодилась. И всё-таки правильно "Proposals".

              0
              На всякий случай: в Android уже достаточно давно есть поддержка IPSec IKEv2 PSK и IPSec IKEv2 RSA. Первая версия, впрочем, тоже ещё поддерживается.
                0
                Интересная статья. Подскажите, как и чем замеряли скорость аппаратного шифрования? Это пиковая скорость или это скорость в установившемся режиме? Какая нагрузка шифровалась (tcp, udp или что-то другое)?
                  0
                  Ну, я так понимаю, что это несложная история. И более того — спецификации с бенчмарками есть и на сайте микротика, и в других источниках. Т.е. просто вдуваем трафик с какого-то генератора (отдельный ПК с широким каналом) и смотрим сколько трафика пролетает, пока не упремся. От типа нагрузки тоже не должно сильно зависеть, имхо, тем более, что нас вообще интересует пиковая производительность.
                    0
                    По поводу типа нагрузки, допустим у нас tcp и какой-нибудь iperf (как генератор траффика), не будет ли на нём скачков из-за потерь пакетов, повторных пересылок, из-за изменения окна tcp и т.д.? Или замерялось только по факту прихода заданного количества пакетов, а не всего потока данных, т.е. потери не учитывались?
                      0
                      Мы потери не учитывали — только фактический объем перекаченных данных через роутер (в МБ/сек). Хотя в теории в устоявшемся режиме потерь на входе быть не должно, как раз из-за изменения размера окна и т.д.
                      И, да, я с автором статьи никак не связан, но получал примерно такие же значения.
                        0
                        Вас понял, спасибо. Ещё вопрос, это тестировалось в одном направлении или в дуплексе? Девайс в дуплексе тоже такие скорости держит?
                          0
                          Да, я понял вопрос. Эм. К сожалению, не помню, но вроде в одну сторону. По идее — если в обе, то если мы упираемся в проц, то скорость будет та же (скажем, 800Mb/sec), но располовинится на upstream/downstream (400+400).

                          Да, и нужно еще автора статьи попросить привести все измерения к единой базе.
                  +1
                  Автор, спасибо за статью!
                  Не занудства ради, немного опечаток под катом
                  IPSec — набор открытый, расширяемых
                  вы будите иметь
                  вендеров (от англ. vendor)
                  Апапратное шифрование
                  Proposalas
                  Примчания
                  SA для политике
                  IPSec в туннельно режиме
                  имеем дело в windows
                  вынуждает устанавливаеть
                  показыает что настроено

                  Несогласующиеся dst и sa-dst адреса в секции про IPIP/IPsec
                  /ip ipsec policy
                  add dst-address=10.20.20.20/32 proposal=ipsec-tunnel-sa protocol=ipencap src-address=10.10.10.10/32 sa-dst-address=10.10.10.10 sa-src-address=10.20.20.20


                  К слову про RSA сертификаты и IKEv2, я успешно настраивал mikrotik в качестве инициатора по RSA ключу и StrongSwan
                    0
                    Спасибо за внимательность, с орфографией у меня туго)
                    0
                    Хорошая статья, очень сильно выручила и добавила знаний
                      0
                      Появится ли когда-нибудь в микротике поддержка IPSec VTI (вопрос в пространство)? Policy-based IPsec VPN — это довольно грустно.
                        0
                        В linux уже есть экспериментальная поддержка VTI, когда допилят микротиковцы к себе утащат.
                          0
                          В линуксе поддержка VTI есть уже очень давно, и она не экспериментальная. А в микротике его поддержку не могут добавить уже десять лет forum.mikrotik.com/viewtopic.php?f=2&t=65734
                          Тут что-то другое.
                        +1
                        Очередная отличная статья. Большое спасибо!

                        Есть пара вопросов:
                        1. По поводу связывания пира с шаблоном политики IPsec через policy-template-group. Дело в том, что в WiKi описание этого параметра такое: «If generate-policy is enabled, responder checks against templates from the same group.». Т.е. речь идёт про ответчика и ничего не сказано про инициатора. Мои эксперименты с настройкой L2TP/IPsec туннелей с ручным созданием пиров показали, что на стороне ответчика это действительно работает. Тогда как на стороне инициатора — нет. Так и пришлось в итоге для настройки шифрования править дефолтные профили (Peers Profiles и Policy Proposals).
                        Можете это как-то прокомментировать? Это действительно такая фича или я что-то не так делал?

                        2.
                        В Firewall можно проверить соответствует трафик входящей или исходящей IPSec политики или нет. Очевидное применение — L2TP/IPSec, можно запретить установку L2TP соединений если трафик не был предварительно зашифрован.

                        Не логичнее для этого использовать параметр use-encryption=require в параметрах профиля PPP?

                        И некоторые наблюдения (скорее для тех кто в будет читать статью и комменты):
                        1. На роутерах без аппаратного шифрования использование хеширования sha256 вместо sha1 довольно заметно просаживает скорость туннеля. Так что хорошенько подумайте так ли плох sha1 (про проблемы с ним можно почитать на википедии после чего здраво оценить риски). Использование aes 256 вместо aes 128 естественно тоже даёт просадку, но не такую существенную.
                        2. Смотрю на таблицу поддерживаемых Windows 10 алгоритмов (в MikroTik WiKi). И вспоминаю, что когда я ставил эксперименты (с Windows 8.1 правда) я выяснил, что винда на первой фазе использует DH Group modp2048. А здесь написано modp1024. Странно. Может конечно я что-то напутал, но лучше имейте в виду, что бы потом мучительно долго не искать почему VPN-клиент на винде не подключается.
                        Какой алгоритм шифрования винда будет использовать — AES-128 или AES-256 — зависит от настройки «шифрование данных: обязательное» или «шифрование данных: самое стойкое» (соответственно).
                          0
                          Мои эксперименты с настройкой L2TP/IPsec туннелей с ручным созданием пиров показали, что на стороне ответчика это действительно работает. Тогда как на стороне инициатора — нет.

                          У меня такое-же поведение, просто обычно не использую mikrotik в качестве l2tp инициализатора.

                          Не логичнее для этого использовать параметр use-encryption=require в параметрах профиля PPP?

                          Если ничего не поменялось, то эта опция отвечает только за шифрование встроенное в протокол(для l2tp — mppe128). Если использовать автоконфиг ipsec для l2tp, там есть use-ipser=require, вот это уже то.

                          Спасибо про дополнения про алгоритмы шифрования.
                            0
                            У меня такое-же поведение

                            Позволю себе немного расширить описание «проблемы». Возможно кто-то прочитает и предложит решение.
                            Итак, на стороне сервера/ответчика при поднятии L2TP сервера мы можем не использовать автоконфигурацию IPsec (use-ipsec=no в параметрах L2TP сервера). При этом надо руками создать пиры (для 0.0.0.0/0, другой сети или конкретного IP — не важно) и через группу (созданную нами или дефолтную) связать эти пиры с шаблоном политики IPsec. И всё работает — при принятии подключения на основе шаблона создаётся политика.
                            На стороне же клиента/инициатора (я имею в виду если клиентом выступает устройство с RouterOS) если при создании L2TP-клиента мы укажем параметр use-ipsec=yes (т.е. задействуем автоконфигурацию IPsec) происходит следующее — при инициации соединения создаётся динамический пир и политика IPsec, политика в этот момент создаётся и на стороне ответчика. Само собой динамический пир и шаблон для политики используют группу по умолчанию (default) и дефолтные профили с настройками хеширования/шифрования. Если же при создании L2TP-клиента мы укажем параметр use-ipsec=no (т.е. отключим автоконфигурацию) и создадим пир в ручную, а потом инициируем наше L2TP соединение, то в этот момент политика IPsec не создаётся (пир при этом кстати виден как активный и на стороне ответчика).
                            Т.е. тут дело видимо даже не в том, что пир не связывается с шаблоном политики. А в том что если в свойствах L2TP-клиента use-ipsec=yes, то происходит какая-то «магия» которая инициирует создание политики на обеих сторонах. В случае если use-ipsec=no этого не происходит. Что это за «магия» такая мне не хватает знаний понять.
                            В итоге на стороне клиента приходится использовать автоконфигурацию, а если нужно регулировать алгоритмы хеширования и шифрования, то делать это приходится в дефолтных профилях Peer Profiles и Policy Prorosals. Что лично я считаю не лучшей практикой.
                            А с другой стороны можно сказать: «Ну что ты докопался? Всё же настраивается и работает. Что тебе еще надо?».
                              0
                              Я думаю, что это повод написать в саппорт и на форум Микротика.
                              Меня тоже такая неявная магия напрягает.
                              +1
                              Если ничего не поменялось, то эта опция отвечает только за шифрование встроенное в протокол(для l2tp — mppe128).

                              Проверил экспериментально и оказалось, что эта функция способна определять и IPsec шифрование. Но Вы всё равно правы — лучше эту функцию не использовать как защиту от установки не зашифрованного туннеля. Т.к. при определённом стечении факторов может получится, что туннель установится с шифрованием только mppe128 и этой функцией будет считаться зашифрованным. Можно использовать как дополнение к use-ipser=require и защите на уровне файрвола.
                            0
                            А невозможность поднятия второго соединения L2TP + IPsec из-за одного NAT это особенность Микротика или IPsec?

                            P.S. Я пару недель страдал, думал что я где то ошибся, пока на Хабре в комментариях не увидел, что так и должно быть.
                              0
                              ну, так IPsec же умеет обходить NAT!?
                              И по идее можно провести эксперимент с «чистым» L2TP, чтобы проверить, что происходит.
                              По моему мнению, все-таки это особенность микротика, но мне лень делать тестовый стенд, чтобы доказать это или обратное )
                                0
                                Я не скажу, что я сильный спец в IPsec, но насколько я понимаю это именно особенность IPsec.
                                Дело в том, что политика IPsec указывает шифровать трафик от одной точки до другой, а в качестве этих точек белые IP. Если Вы из-за NAT'а пытаетесь поднять два L2TP/IPsec туннеля до одного сервера, то получается что Вы тем самым пытаетесь создать две разные политики с одними и теми же IP на концах, а это не возможно.
                                Если я ошибаюсь, то пусть меня поправят более знающие товарищи.
                                  0
                                  Если Вы из-за NAT'а пытаетесь поднять два L2TP/IPsec туннеля до одного сервера, то получается что Вы тем самым пытаетесь создать две разные политики с одними и теми же IP на концах, а это не возможно.

                                  давайте разделим l2tp и ipsec. IPsec прекрасно работает из-за NAT сам по себе. Просто политика на второй стороне в некотором роде «динамическая» (слаб в терминологии по этой части, т.к. не «сетевик»). Примеры конфигов можно настрелять в оф. репах libre/strongswan:
                                  github.com/libreswan/libreswan/tree/master/testing
                                  wiki.strongswan.org/projects/strongswan/wiki/IKEv2Examples
                                  wiki.strongswan.org/projects/strongswan/wiki/IKEv1StrokeExamples
                                  Вот та самая история: два клиента за одним роутером. Другой вопрос, если оба узла за NAT, но это совсем другом кейс…
                                    0
                                    давайте разделим l2tp и ipsec

                                    Человек спрашивал про туннели L2TP/IPsec. Что не получается установить более одного такого туннеля из-за одного NAT. Я ответил, что причина скорее всего в IPsec. Т.е. речь про IPsec.
                                    IPsec прекрасно работает из-за NAT сам по себе.

                                    С этим никто не спорит. Вопрос в том можно ли подключиться к одному ответчику с двух инициаторов, находящихся за одним NAT'ом (тоже не сильно силён в терминологии (если что).
                                    Вот та самая история: два клиента за одним роутером.

                                    Честно сказать из картинки и описания не очень понял что там вообще происходит. Но мне кажется там не наш случай.
                                      0
                                      С этим никто не спорит. Вопрос в том можно ли подключиться к одному ответчику с двух инициаторов, находящихся за одним NAT'ом (тоже не сильно силён в терминологии (если что).

                                      я же дал ответ на вопрос — да, можно.
                                      Честно сказать из картинки и описания не очень понял что там вообще происходит. Но мне кажется там не наш случай.

                                      очень жаль.
                                      Человек спрашивал про туннели L2TP/IPsec. Что не получается установить более одного такого туннеля из-за одного NAT. Я ответил, что причина скорее всего в IPsec. Т.е. речь про IPsec.

                                      я допускаю, что это кумулятивный эффект (особенности одной и другой технологии, наложенные друг на друга). Пока лень проверять.
                                        0
                                        Вот мы тут сидели гадали, а ответ дан в презентации на которую ссылка в посте была: youtu.be/u1URSgvAxX8?t=490
                                          0
                                          Ну да. Мы это исправили, но работает со всем кроме Windows (нужен другой порт). А Windows сколько процентов рынка занимает?

                                          Ну что же, придется изучать — google.com.ua/search?q=windows+change+l2tp+port

                                          Большое спасибо что внесли ясность в мой вопрос.
                                  0
                                  0
                                  del
                                    0
                                    В настройках IPsec используется шифрование AES и подпись в виде SHA-256 или SHA-1 или MD5, эту подпись еще называют код аутентичности сообщения (MAC).
                                    Дополнительная подпись тратит ресурсы и снижает пропускную способность примерно на 8 Мбит/с на Микротиках без аппаратного шифрования.
                                    Вот тест скорости что получилось сделать (скорости примерные и колеблятся в предела ±2 Мбит/с):
                                    AES-128 CBC + SHA256 = 21 Мбит/с
                                    AES-128 CBC + SHA1 = 21 Мбит/с
                                    AES-128 CBC + MD5 = 22 Мбит/с
                                    AES-128 CBC + NO = 30 Мбит/с — это самый быстрый вариант

                                    На сколько безопасно использовать канал IPsec без подписи только с одним шифрованием AES?
                                      0
                                      Привет, хороший вопрос.
                                      ESP подписывает свои заголовки и шифрованный кусок данных. В теории можно подменить данные, но если они будут зашифрованы другим ключем, то получатель не сможет расшифровать и отбросит, как вариант атаки DoS такое можно использовать конечно, но в плане безопасности отсутствие аутентификации не должно сильно навредить.
                                      0
                                      Сегодня обновили RouterOS на CCR1036-8G-2S+ до версии 6.44
                                      Перестало работать VPN L2TP/IPsec — хотя до этого все работало на различных ОС.
                                      И сервер и клиент находятся за NAT, но попробовали и без NAT уже.
                                      В логах есть только такая ошибка — failed to pre-process ph2 packet
                                      Ошибки no proposal found нет.

                                      Заголовок спойлера
                                      13:27:01 ipsec,debug 0xee368: next=(nil) tnext=(nil)
                                      13:27:01 ipsec,debug proposal #1: 1 transform
                                      13:27:01 ipsec,debug pair 2:
                                      13:27:01 ipsec,debug 0xecc10: next=(nil) tnext=(nil)
                                      13:27:01 ipsec,debug proposal #2: 1 transform
                                      13:27:01 ipsec,debug got the local address from ID payload 192.168.11.2[1701] prefixlen=32 ul_proto=17
                                      13:27:01 ipsec,debug got the peer address from ID payload 172.16.33.85[1701] prefixlen=32 ul_proto=17
                                      13:27:01 ipsec,debug updating policy address because of NAT in transport mode
                                      13:27:01 ipsec searching for policy for selector: 192.168.11.2:1701 ip-proto:17 <=> 172.16.33.85:1701 ip-proto:17
                                      13:27:01 ipsec no template matches
                                      13:27:01 ipsec failed to get proposal for responder.
                                      13:27:01 ipsec,error 172.16.33.85 failed to pre-process ph2 packet.
                                      13:27:01 ipsec,debug compute IV for phase2

                                        0
                                        В 6.44 все переколбасили… думаю не перенеслись настройки автоматом, удали конфигурацию ipsec и настрой по новой
                                          0
                                          Перестало работать только из Windows — из Ubuntu работает.
                                            0
                                            Попробуем как сможем — сейчас в рабочее время не хотелось бы ломать работу людям.

                                            Вот попробовал на старом микротике 6.42.12 — работает, но если в peer убрать 3des — все, виндовые клиенты не хотят подключатся. Как будто в 6.44 несмотря на галочки что он есть, 3des удалили.

                                            Обновил до 6.43.13 — настройки изменились, но все работает даже если убрать 3des везде.
                                            0
                                            В общем заработало — удалил дефолтный peer, остался только мною созданный peer и соединение заработало во всех ОС.
                                            0
                                            В новой версии прошивки 6.44.1 опять решили что-то поломать с L2TP/IPsec
                                            Удаляю дефолтный peer — подключаются клиенты, перезагрузка роутера — появляется дефолтный peer и дефолтный IPsec Identities c Policy template Group — unknown.
                                            Клиенты подключится естественно не могут.

                                            Ответ MikroTik Support на форуме
                                            disable the «use-ipsec» option under L2TP server settings. Make sure you have only one static IPsec peer for 0.0.0.0/0 and exchange-mode=main. Assign multiple identities for this peer with different pre-shared-key secrets. Lastly, make sure only IPsec encrypted traffic is allowed for L2TP traffic.

                                            As I said, you can not mix the «use-ipsec» option under L2TP settings with static IPsec configuration. The L2TP setting will take precedence over all static configuration. So you either go with the dynamic configuration or the static only

                                            Поставили в L2TP server опцию Use IPsec — peer и identities перестали создаваться после перезагрузки роутера и клиенты стали подключатся.
                                              0
                                              А что они поломали? Ничего они не поломали. Они же написали, что нужно использовать либо автоматическую конфигурацию (через use-ipsec в параметрах L2TP сервера), либо ручную (и тогда выключить use-ipsec). Другое дело, что раньше прокатывало и то и другое одновременно. Я и сам так по началу делал по незнанию. Но скорее именно это и было не правильно.
                                              Поставили в L2TP server опцию Use IPsec

                                              Убрали наверно, а не поставили?

                                              А вообще же в 6.44 они добавили Identities. Немного сложнее в настройке стало, зато даёт бОльшую гибкость. Например если у Вас удалённые работники подключаются по VPN (а я так понял это именно Ваш случай), то Вы для пира 0.0.0.0/0 можете теперь сделать несколько pre shared key. Каждому человеку свой, так же как логин/пароль. В то время как раньше он был один на всех. Я, правда, пока не пробовал как это в реальности работает.
                                                0
                                                Поломали потому что после обновления перестало много у кого работать, и через автоматическую конфигурацию не работает и не только у нас.

                                                Попробовал на старом Микротике задизэйблить identities и peer чтобы использовать настройку Use IPsec в настройках L2TP server — не работает.
                                                  0
                                                  Очень сложно так не видя конфигурацию что-то говорить. У меня сложилось впечатление, что у Вас был некий «микс» из автоматической и ручной конфигурации. Такой вывод я делаю на основе фразы «Удаляю дефолтный peer — подключаются клиенты». Т.е. у Вас получается был динамический пир для 0.0.0.0/0 и статический 0.0.0.0/0. До 6.44 это действительно работало. Я предполагаю, что до 6.44 статический пир был в приоритете, поэтому это и работало. После обновления в приоритете стал динамический пир (The L2TP setting will take precedence over all static configuration.), поэтому и поломалось. В любом случае делать такой микс это не правильно и теперь это не работает (you can not mix the «use-ipsec» option under L2TP settings with static IPsec configuration).
                                                  Но я подчёркиваю — это всё только лишь мои предположения.
                                                  Точно могу утверждать только, что при полностью ручной конфигурации обновление прошло без последствий.
                                                  Попробовал на старом Микротике задизэйблить identities и peer чтобы использовать настройку Use IPsec в настройках L2TP server — не работает.

                                                  Корректный pre shared key в настройках L2TP server прописать не забыли при этом?
                                                    0
                                                    Конфигурация изначальная работала года два наверное, в 6.44 начали переделывать товарищи из микротика и много у кого поломалось.

                                                    Shared secret конечно прописал — failed to pre-process ph2 packet ошибка прилетает.
                                                    В динамическом Identities — Policy template Group — unknown. И это явно из-за этого проблема.
                                                      0
                                                      Не буду спорить, очень даже вероятно, что действительно косяк какой-то. Я отказался от автонастройки IPsec на стороне респондера (к сожалению на стороне инициатора это сделать нельзя). Возможно поэтому у меня обновление без проблем прошло.
                                                      Кстати, ведь в посте была об этом речь. Позволю себе процитировать:
                                                      В конфигурации ipip,gre,eoip,l2tp присутствует автонастройка ipsec соединения, по сути система создает динамические правила для Peers и Policies за вас, но во-первых — мы не ищем легких путей, во-вторых при обновлении с 6.42 на 6.43 автоматически созданные туннели ломались и не факт, что этого не повторится.

                                                      Выходит автор как в воду глядел.
                                                      Вообще в 6.44 очень много изменений. Логично ожидать, что и косяков не мало. Один из них я лично репортил и его исправили в 6.44.1.
                                                  0
                                                  Немного сложнее в настройке стало

                                                  дело привычки, когда master-port убрали тоже казалось, что сложнее стало, а потом привык.

                                                  Что меня поразило в 6.44, так это настройка wlan. Теперь security-profile перенесли в advanced settings, мне их логика совсем непонятна…
                                                0
                                                Нельзя так делать обновления.
                                                  0
                                                  Пытаюсь тут у себя на домашнем роутере подружить ProtonVPN и Mikrotik. Всё вроде настроил, но одна проблема осталась. Никак не хочет отдавать трафик. В Firewall во вкладке filter rules появилась строка defconf: accept out ipsec policy и всё по нулям. В NAT есть маскарад с IP Sec out ipsec… Естественно speedtest.net показывает 0 на upload и т.д. Не намекнёте куда хоть смотреть?
                                                    0
                                                    Насколько знаю, ProtonVPN разрешает или OVPN с TLS, или IKEv2. Ни то, ни другое Mikrotik с ROSv6 не поддерживает.
                                                      0
                                                      Поддерживает уже давно. У меня проблема была в MSS. Совсем из головы выпало. Всё поправил, всё работает теперь
                                                        0
                                                        Действительно, с v6.45.1 (27 июня) поддерживается.
                                                        Заголовок спойлера
                                                        !) ike2 — added support for EAP authentication methods (eap-tls, eap-ttls, eap-peap, eap-mschapv2) as initiator;
                                                        mikrotik.com/download/changelogs/stable-release-tree

                                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                  Самое читаемое