IPsec Site-to-Site VPN в pfSense - настройка туннеля

IPsec (Internet Protocol Security) - стандартизированный набор протоколов для организации защищённых соединений поверх публичных сетей. В отличие от проприетарных VPN-решений, IPsec поддерживается практически всеми сетевыми платформами: pfSense, Cisco ASA, FortiGate, MikroTik, Juniper, а также облачными провайдерами - AWS, Azure, GCP. Это делает IPsec основным выбором при построении site-to-site туннелей между площадками с разнородным оборудованием.

Данное руководство описывает полный цикл настройки IPsec site-to-site VPN в pfSense: от согласования параметров шифрования до диагностики неполадок. Материал рассчитан на сетевых инженеров, имеющих опыт работы с межсетевыми экранами и базовое понимание принципов VPN.

Терминология IPsec

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

IKE - Internet Key Exchange

IKE - протокол согласования параметров безопасности и обмена ключами. Существуют две версии:

Рекомендация: при отсутствии требований совместимости с устаревшим оборудованием следует использовать IKEv2.

Security Association (SA)

SA - однонаправленное логическое соединение между двумя узлами, определяющее параметры защиты трафика: алгоритм шифрования, алгоритм хеширования, ключевой материал и время жизни. Для двунаправленной связи создаётся пара SA - по одной на каждое направление.

Phase 1 - канал управления

Phase 1 (IKE SA) устанавливает защищённый канал управления между двумя узлами. На этом этапе происходит:

• Аутентификация сторон (PSK или сертификаты)
• Согласование алгоритмов шифрования и хеширования
• Обмен ключами по протоколу Диффи-Хеллмана
• Создание IKE SA с определённым временем жизни

Phase 1 не передаёт пользовательский трафик - это исключительно служебный канал для согласования параметров Phase 2.

Phase 2 - канал данных

Phase 2 (Child SA / IPsec SA) определяет, какой трафик защищается и каким образом. На этом этапе согласуются:

• Подсети источника и назначения (Traffic Selectors)
• Алгоритмы шифрования и хеширования для пользовательского трафика
• Протокол инкапсуляции (ESP или AH)
• Группа PFS (Perfect Forward Secrecy)

Одна Phase 1 может обслуживать несколько Phase 2 - например, для передачи трафика между различными подсетями.

PSK и сертификаты

Для аутентификации сторон используются два основных метода:

• Pre-Shared Key (PSK) - общий секретный ключ, заданный на обоих узлах. Простой в настройке, но менее безопасный: компрометация ключа на одном узле ставит под угрозу все туннели, использующие этот ключ.
• Сертификаты X.509 - аутентификация на основе PKI. Обеспечивает более надёжную проверку подлинности, упрощает масштабирование при большом количестве туннелей и позволяет отзывать отдельные сертификаты без влияния на остальные соединения.

Для site-to-site туннелей между двумя площадками PSK обычно достаточен при условии использования сложного ключа длиной не менее 32 символов. При подключении более пяти площадок рекомендуется переход на сертификаты.

Предварительные требования

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

Сетевые требования

1. Статические публичные IP-адреса на обоих узлах. При отсутствии статического адреса допускается использование Dynamic DNS (DynDNS), однако стабильность туннеля в этом случае снижается.

2. Непересекающиеся подсети за обоими узлами. IPsec в режиме policy-based не может маршрутизировать трафик между одинаковыми подсетями. Пример корректной конфигурации:

   • Площадка A: LAN 10.1.0.0/24
   • Площадка B: LAN 10.2.0.0/24

   Если подсети совпадают, необходимо выполнить перенумерацию одной из них или использовать NAT/BINAT в Phase 2.

3. Согласованные параметры шифрования - обе стороны должны поддерживать одинаковые алгоритмы шифрования, хеширования и группы Диффи-Хеллмана.

Параметры для согласования с удалённой стороной

Перед настройкой следует согласовать с администратором удалённой площадки:

Внимание:

Все параметры Phase 1 и Phase 2 должны совпадать на обоих узлах. Несовпадение даже одного параметра (например, DH Group) приведёт к отказу в установлении туннеля.

Настройка Phase 1

Phase 1 настраивается в разделе VPN > IPsec > Tunnels. Для создания нового туннеля следует нажать кнопку Add P1.

Рис. 1. Настройка Phase 1 в веб-интерфейсе pfSense

General Information

При использовании FQDN в поле Remote Gateway pfSense будет периодически выполнять DNS-разрешение, что полезно при динамическом IP-адресе удалённой стороны.

Phase 1 Proposal - Authentication

Внимание:

Ключ PSK чувствителен к регистру. Необходимо убедиться в точном совпадении ключей на обоих узлах, включая пробелы и специальные символы.

Phase 1 Proposal - Encryption Algorithm

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

Допускается добавление нескольких Encryption Algorithm - pfSense и удалённый узел согласуют наиболее стойкий общий вариант. Однако для site-to-site туннелей рекомендуется указывать ровно один набор параметров, совпадающий на обеих сторонах, чтобы исключить неоднозначность.

Внимание:

Алгоритмы DES, 3DES, Blowfish, MD5 и SHA1 считаются устаревшими и не должны использоваться в новых инсталляциях. Группы DH 1, 2, 22, 23, 24 не обеспечивают достаточного уровня безопасности.

Expiration and Replacement

Значение Rand Time вносит случайный разброс во время переключения ключей, предотвращая ситуацию, когда оба узла одновременно инициируют rekeying.

Advanced Options

При включённом DPD pfSense будет обнаруживать недоступность удалённого узла примерно через 50-60 секунд (10 секунд * 5 попыток + накладные расходы) и перестроит туннель при восстановлении связи.

Настройка Phase 2

После сохранения Phase 1 необходимо добавить Phase 2. Для этого следует нажать кнопку Show Phase 2 Entries, затем Add P2.

Рис. 2. Настройка Phase 2 в веб-интерфейсе pfSense

General Information

При необходимости защиты трафика между несколькими подсетями (например, LAN и DMZ) следует создать отдельную запись Phase 2 для каждой пары подсетей.

Phase 2 Proposal - SA/Key Exchange

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

Внимание:

Протокол AH (Authentication Header) обеспечивает только аутентификацию без шифрования. В подавляющем большинстве сценариев следует использовать ESP.

Expiration and Replacement

Время жизни Phase 2 должно быть меньше времени жизни Phase 1. Стандартное соотношение - Phase 1: 28800 секунд, Phase 2: 3600 секунд.

Keep Alive

Автоматический ping предотвращает разрыв туннеля при отсутствии пользовательского трафика. В качестве адреса рекомендуется указывать шлюз по умолчанию удалённой подсети или другой постоянно доступный хост.

Правила файрвола для IPsec

После настройки туннеля необходимо создать правила файрвола, разрешающие прохождение трафика. Требуются правила на двух вкладках: WAN и IPsec.

Правила на WAN-интерфейсе

Для установления IPsec-туннеля через WAN-интерфейс должен проходить следующий трафик:

Если на WAN-интерфейсе действует правило по умолчанию, разрешающее весь исходящий трафик, а входящие подключения инициирует только удалённая сторона, то дополнительных правил на WAN может не потребоваться - pfSense автоматически разрешает входящий IKE-трафик для настроенных IPsec-туннелей.

Внимание:

При использовании NAT-T (UDP 4500) протокол ESP инкапсулируется в UDP-пакеты. В этом случае отдельное правило для ESP (протокол 50) не требуется.

Правила на вкладке IPsec

Вкладка Firewall > Rules > IPsec управляет трафиком, проходящим через все установленные IPsec-туннели. По умолчанию вкладка пуста - весь трафик через туннель блокируется.

Рис. 4. Правила файрвола на вкладке IPsec

Минимальный набор правил для разрешения трафика между площадками:

В производственной среде рекомендуется ограничивать правила конкретными протоколами и портами вместо использования Any. Например, разрешить только ICMP, SSH (TCP 22) и HTTPS (TCP 443).

Более подробно о принципах создания правил файрвола описано в разделе Правила файрвола pfSense .

Проверка подключения

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

Status > IPsec

Перейдите в Status > IPsec для просмотра состояния всех IPsec-туннелей.

Рис. 3. Страница статуса IPsec-туннелей

Страница отображает:

• Phase 1 - состояние IKE SA (Established / Connecting / Disconnected)
• Phase 2 - состояние Child SA с указанием Traffic Selectors (локальная и удалённая подсети)
• SPI - Security Parameter Index для каждой SA
• Bytes In/Out - объём переданного трафика
• Status - текущее состояние с кнопками Connect / Disconnect

Успешно установленный туннель отображается со статусом Established для Phase 1 и активными Child SA для Phase 2.

Диагностика через командную строку

При необходимости более детальной диагностики доступны команды через Diagnostics > Command Prompt или SSH:

# Status of all IPsec SAs
ipsec statusall

# Detailed status with traffic counters
ipsec status

# Restart IPsec service
ipsec restart

# View IPsec-related logs in real time
clog -f /var/log/ipsec.log

# Ping through the tunnel (from pfSense shell)
ping -S 10.1.0.1 10.2.0.1

Команда ipsec statusall отображает полную информацию о всех SA, включая согласованные алгоритмы, время до истечения и количество переданных байтов.

Проверка прохождения трафика

После установления туннеля рекомендуется выполнить следующие проверки:

1. Ping между подсетями - с хоста 10.1.0.100 выполнить ping 10.2.0.100
2. Проверка маршрутизации - traceroute 10.2.0.100 должен показывать прямой маршрут через туннель (без промежуточных хопов)
3. Проверка счётчиков - в Status > IPsec значения Bytes In/Out должны увеличиваться при прохождении трафика

Подключение к оборудованию третьих сторон

IPsec - стандартизированный протокол, однако реализации на различных платформах имеют отличия, которые могут вызвать проблемы при согласовании параметров.

Общие рекомендации

1. Фиксируйте один набор параметров - не полагайтесь на автоматическое согласование. Укажите идентичные алгоритмы шифрования, хеширования и группы DH на обеих сторонах.

2. Используйте IKEv2 - при поддержке обеими сторонами. IKEv2 устраняет многие проблемы совместимости IKEv1.

3. Проверяйте идентификаторы - некоторые платформы по умолчанию используют FQDN или Distinguished Name вместо IP-адреса в качестве идентификатора. Несовпадение идентификаторов - частая причина отказа Phase 1.

4. Согласуйте время жизни - различие в значениях Lifetime между платформами может привести к ситуации, когда одна сторона пытается выполнить rekeying, а вторая считает SA действующей.

Cisco ASA

• Cisco ASA по умолчанию использует IKEv1 с Aggressive Mode для динамических пиров. При подключении к pfSense рекомендуется явно настроить Main Mode или перейти на IKEv2.
• Идентификатор Phase 1 на ASA задаётся командой crypto isakmp identity address - убедитесь, что pfSense настроен на Peer IP Address.
• ASA поддерживает ограниченный набор DH-групп - проверьте совместимость перед настройкой.

FortiGate

• FortiGate поддерживает как policy-based, так и route-based VPN. При подключении к pfSense в режиме policy-based необходимо точное совпадение Traffic Selectors (подсетей Phase 2).
• FortiGate использует собственные наименования алгоритмов: aes256gcm соответствует AES-256-GCM в pfSense.
• По умолчанию FortiGate включает DPD в режиме on-demand - pfSense отправляет DPD-запросы регулярно. Это не вызывает проблем, но следует учитывать при анализе логов.

MikroTik RouterOS

• MikroTik использует терминологию peer и policy вместо Phase 1 и Phase 2. Параметры peer соответствуют Phase 1, policy - Phase 2.
• В RouterOS необходимо явно указать enc-algorithms и hash-algorithm в разделе proposal - автоматическое согласование может выбрать нежелательный алгоритм.
• MikroTik по умолчанию не включает PFS - параметр pfs-group необходимо задать явно, если PFS используется на стороне pfSense.

AWS Virtual Private Gateway (VGW)

• AWS VGW поддерживает IKEv1 и IKEv2. При создании VPN Connection AWS предоставляет файл конфигурации с рекомендуемыми параметрами.
• AWS использует два туннеля для резервирования - необходимо создать два Phase 1 + Phase 2 в pfSense, по одному на каждый публичный IP-адрес AWS.
• Lifetime Phase 1 на стороне AWS составляет 28800 секунд, Phase 2 - 3600 секунд. Эти значения следует использовать в pfSense.
• AWS не поддерживает AES-GCM в некоторых регионах - проверяйте документацию для конкретного региона.

Azure VPN Gateway

• Azure VPN Gateway поддерживает IKEv2 с policy-based и route-based конфигурацией.
• Для подключения pfSense к Azure рекомендуется route-based VPN Gateway с конфигурацией VTI на стороне pfSense.
• Azure предоставляет список поддерживаемых криптографических параметров в документации - параметры pfSense должны входить в этот список.
• BGP через IPsec поддерживается только с route-based VPN Gateway и VTI на стороне pfSense.

Routed IPsec (VTI)

Описанная выше конфигурация использует policy-based IPsec, где трафик направляется в туннель на основании совпадения с Traffic Selectors (подсетями Phase 2). Альтернативный подход - routed IPsec с использованием Virtual Tunnel Interfaces (VTI).

Принцип работы

При использовании VTI pfSense создаёт виртуальный сетевой интерфейс ipsecX, который функционирует как обычный интерфейс операционной системы. Трафик направляется в туннель через таблицу маршрутизации, а не через Security Policy Database.

Преимущества VTI перед policy-based

Когда использовать VTI

Routed IPsec рекомендуется в следующих случаях:

• Требуется динамическая маршрутизация (BGP/OSPF) через туннель
• Количество подсетей на удалённой стороне велико или часто изменяется
• Необходима интеграция с Gateway Groups для отказоустойчивости
• Требуется policy routing через VPN-туннель

Настройка VTI

Настройка VTI отличается от policy-based в Phase 2:

1. В Phase 2 установите Mode в значение Routed (VTI)
2. В поле Local Network укажите локальный IP-адрес туннельного интерфейса (например, 10.255.0.1/30)
3. В поле Remote Network укажите удалённый IP-адрес туннельного интерфейса (например, 10.255.0.2/30)
4. После сохранения перейдите в Interfaces > Assignments и назначьте интерфейс ipsecX
5. Включите назначенный интерфейс и при необходимости настройте статические маршруты или FRR

Внимание:

Для использования VTI обе стороны должны поддерживать этот режим. При подключении к устройству, не поддерживающему VTI, следует использовать policy-based IPsec.

Устранение неполадок

Phase 1 не устанавливается

Симптомы: статус Phase 1 - Connecting, в логах сообщения NO_PROPOSAL_CHOSEN или AUTHENTICATION_FAILED.

Phase 2 не устанавливается

Симптомы: Phase 1 в статусе Established, но Phase 2 не появляется или отображается со статусом no child SA.

Туннель установлен, но трафик не проходит

DPD и периодические разрывы

• Частые DPD-таймауты при стабильном канале связи могут указывать на перегрузку удалённого узла или потерю UDP-пакетов. Увеличьте DPD Delay до 30 секунд и Max Failures до 10.
• Туннель не восстанавливается после разрыва: проверьте параметр Child SA Start Action - значение Start обеспечивает автоматическое переподключение.
• Одновременный rekeying обоими узлами может привести к дублированию SA. Убедитесь, что Rand Time не обнулён.

NAT-T и двойной NAT

При наличии NAT между узлами IPsec-туннеля:

1. Убедитесь, что NAT Traversal установлен в Auto или Force.
2. При двойном NAT (NAT на обеих сторонах) может потребоваться проброс UDP 500 и 4500 на обоих маршрутизаторах.
3. NAT-T инкапсулирует ESP в UDP 4500 - убедитесь, что этот порт не блокируется промежуточными устройствами.

Полезные команды диагностики

# View IKE SA details
ipsec statusall

# View routing table
netstat -rn

# Capture IPsec traffic on WAN
tcpdump -ni em0 esp or udp port 500 or udp port 4500

# Check for IPsec-related kernel messages
dmesg | grep -i ipsec

# View strongSwan logs
cat /var/log/ipsec.log | tail -100

Связанные разделы

• Правила файрвола pfSense - принципы создания и управления правилами файрвола, необходимые для корректной работы IPsec-туннелей
• Алиасы файрвола pfSense - использование алиасов для упрощения управления IP-адресами и подсетями в правилах IPsec
• NAT в pfSense - настройка NAT, включая особенности взаимодействия NAT и IPsec