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

> Настройка IPsec site-to-site туннеля в pfSense - Phase 1, Phase 2, шифрование, маршрутизация, правила файрвола и подключение к оборудованию третьих сторон

Source: https://opennix.org/docs/pfsense/vpn/ipsec/pfsense-ipsec-site-to-site/


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 - протокол согласования параметров безопасности и обмена ключами. Существуют две версии:

| Характеристика | IKEv1 | IKEv2 |
|---|---|---|
| Количество сообщений для установления | 6-9 (Main/Aggressive mode) | 4 |
| Поддержка NAT-T | Требует отдельного согласования | Встроенная |
| Поддержка MOBIKE | Нет | Да |
| Повторная аутентификация | Отсутствует | Встроенная |
| Совместимость | Широкая (legacy-устройства) | Современное оборудование |

Рекомендация: при отсутствии требований совместимости с устаревшим оборудованием следует использовать 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. **Согласованные параметры шифрования** - обе стороны должны поддерживать одинаковые алгоритмы шифрования, хеширования и группы Диффи-Хеллмана.

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

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

| Параметр | Пример значения |
|---|---|
| Публичный IP удалённого узла | `203.0.113.10` |
| Версия IKE | IKEv2 |
| Метод аутентификации | PSK |
| Pre-Shared Key | (сложный ключ, 32+ символов) |
| Алгоритм шифрования Phase 1 | AES-256-GCM |
| Hash Phase 1 | SHA256 |
| DH Group | 14 (2048 bit) |
| Lifetime Phase 1 | 28800 секунд |
| Локальная подсеть | `10.1.0.0/24` |
| Удалённая подсеть | `10.2.0.0/24` |
| Алгоритм шифрования Phase 2 | AES-256-GCM |
| PFS Group | 14 (2048 bit) |
| Lifetime Phase 2 | 3600 секунд |

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

## Настройка Phase 1

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

![Phase 1 configuration](/img/pfsense/pfsense-ipsec-phase1-edit.webp)
<p style="text-align: center;">Рис. 1. Настройка Phase 1 в веб-интерфейсе pfSense</p>

### General Information

| Поле | Значение | Пояснение |
|---|---|---|
| Disabled | Не установлен | Снятие флага активирует туннель |
| Key Exchange version | IKEv2 | Рекомендуемая версия протокола |
| Internet Protocol | IPv4 | Или IPv6, в зависимости от адресации WAN |
| Interface | WAN | Интерфейс, через который устанавливается туннель |
| Remote Gateway | `203.0.113.10` | IP-адрес или FQDN удалённого узла |
| Description | `Site B - Moscow Office` | Описание для идентификации туннеля |

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

### Phase 1 Proposal - Authentication

| Поле | Значение | Пояснение |
|---|---|---|
| Authentication Method | Mutual PSK | Аутентификация по общему ключу |
| My identifier | My IP Address | Автоматически подставляется IP-адрес WAN |
| Peer identifier | Peer IP Address | IP-адрес удалённого узла |
| Pre-Shared Key | (ваш ключ) | Минимум 32 символа, включая буквы, цифры и спецсимволы |

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

### Phase 1 Proposal - Encryption Algorithm

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

| Поле | Значение | Пояснение |
|---|---|---|
| Algorithm | AES-256-GCM | Аутентифицированное шифрование с аппаратным ускорением (AES-NI) |
| Key Length | 256 bits | Максимальная длина ключа |
| Hash | SHA256 | При использовании AES-GCM хеширование выполняется встроенным механизмом GHASH; тем не менее, поле Hash используется для PRF (Pseudo-Random Function) |
| DH Group | 14 (2048 bit) | Минимально рекомендуемая группа |

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

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

### Expiration and Replacement

| Поле | Значение | Пояснение |
|---|---|---|
| Life Time | 28800 | Время жизни IKE SA в секундах (8 часов) |
| Rekey Time | (пусто) | Автоматический расчёт - 90% от Life Time |
| Reauth Time | (пусто) | Автоматический расчёт - 90% от Life Time |
| Rand Time | (пусто) | Автоматический расчёт - 10% от Life Time |

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

### Advanced Options

| Поле | Значение | Пояснение |
|---|---|---|
| Child SA Start Action | Default | Стандартное поведение |
| NAT Traversal | Auto | Автоматическое определение наличия NAT |
| MOBIKE | Disable | Для site-to-site со статическими IP не требуется |
| Dead Peer Detection | Enabled | Обнаружение недоступности удалённого узла |
| DPD Delay | 10 | Интервал между DPD-запросами в секундах |
| DPD Max Failures | 5 | Количество неответов до признания узла недоступным |

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

## Настройка Phase 2

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

![Phase 2 configuration](/img/pfsense/pfsense-ipsec-phase2-edit.webp)
<p style="text-align: center;">Рис. 2. Настройка Phase 2 в веб-интерфейсе pfSense</p>

### General Information

| Поле | Значение | Пояснение |
|---|---|---|
| Disabled | Не установлен | Phase 2 активна |
| Mode | Tunnel IPv4 | Стандартный режим для site-to-site |
| Local Network | LAN subnet | Или указать подсеть вручную: `10.1.0.0/24` |
| NAT/BINAT | None | Без трансляции адресов (при непересекающихся подсетях) |
| Remote Network | Network / `10.2.0.0/24` | Подсеть за удалённым узлом |
| Description | `LAN Site A to LAN Site B` | Описание Phase 2 |

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

### Phase 2 Proposal - SA/Key Exchange

| Поле | Значение | Пояснение |
|---|---|---|
| Protocol | ESP | Шифрование и аутентификация трафика |
| Encryption Algorithms | AES-256-GCM | Должен совпадать с удалённой стороной |
| Hash Algorithms | SHA256 | При AES-GCM не используется для шифрования, но требуется некоторыми реализациями |
| PFS key group | 14 (2048 bit) | Perfect Forward Secrecy - генерация нового ключевого материала для каждого rekeying |

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

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

### Expiration and Replacement

| Поле | Значение | Пояснение |
|---|---|---|
| Life Time | 3600 | Время жизни Child SA в секундах (1 час) |
| Rekey Time | (пусто) | Автоматический расчёт |
| Rand Time | (пусто) | Автоматический расчёт |

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

### Keep Alive

| Поле | Значение | Пояснение |
|---|---|---|
| Automatically ping host | `10.2.0.1` | IP-адрес хоста в удалённой подсети для поддержания туннеля |

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

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

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

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

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

| Протокол | Порт | Назначение |
|---|---|---|
| UDP | 500 | IKE - обмен ключами |
| UDP | 4500 | NAT-T - обход NAT |
| ESP | Протокол 50 | Инкапсуляция зашифрованного трафика (при отсутствии NAT) |

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

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

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

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

![Firewall rules for IPsec](/img/pfsense/pfsense-ipsec-firewall-rules.webp)
<p style="text-align: center;">Рис. 4. Правила файрвола на вкладке IPsec</p>

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

| Действие | Протокол | Источник | Назначение | Описание |
|---|---|---|---|---|
| Pass | Any | `10.2.0.0/24` | `10.1.0.0/24` | Разрешить трафик из удалённой подсети в локальную |
| Pass | Any | `10.1.0.0/24` | `10.2.0.0/24` | Разрешить трафик из локальной подсети в удалённую |

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

Более подробно о принципах создания правил файрвола описано в разделе [Правила файрвола pfSense](/docs/pfsense/firewall/pfsense-firewall-rules/).

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

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

### Status > IPsec

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

![IPsec status page](/img/pfsense/pfsense-ipsec-status.webp)
<p style="text-align: center;">Рис. 3. Страница статуса IPsec-туннелей</p>

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

- **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:

```bash
# 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

| Характеристика | Policy-based | Routed (VTI) |
|---|---|---|
| Маршрутизация | Traffic Selectors | Таблица маршрутизации ОС |
| Динамическая маршрутизация | Не поддерживается | BGP, OSPF через пакет FRR |
| Мониторинг трафика | Ограниченный | Полноценный (tcpdump, traffic graphs) |
| Policy routing | Не поддерживается | Поддерживается |
| Количество Phase 2 | По одной на пару подсетей | Одна на семейство адресов |
| Отказоустойчивость | Ручная | Gateway Groups |

### Когда использовать 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`.

| Проблема | Причина | Решение |
|---|---|---|
| `NO_PROPOSAL_CHOSEN` | Несовпадение параметров шифрования | Убедитесь, что алгоритм, хеш и DH Group идентичны на обеих сторонах |
| `AUTHENTICATION_FAILED` | Несовпадение PSK или идентификаторов | Проверьте PSK (регистр, пробелы) и настройки My/Peer identifier |
| `PEER_AUTH_FAILED` | Ошибка проверки сертификата | Убедитесь, что CA-сертификат импортирован и не истёк |
| Timeout без сообщений | Блокировка UDP 500/4500 | Проверьте правила файрвола на WAN и промежуточных устройствах |

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

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

| Проблема | Причина | Решение |
|---|---|---|
| `NO_PROPOSAL_CHOSEN` | Несовпадение параметров шифрования Phase 2 | Проверьте алгоритм, хеш и PFS Group |
| `TS_UNACCEPTABLE` | Несовпадение Traffic Selectors | Убедитесь, что подсети в Phase 2 зеркально совпадают: локальная подсеть одного узла = удалённая подсеть другого |
| `INVALID_KE_PAYLOAD` | Несовпадение DH Group для PFS | Установите одинаковую PFS Group или отключите PFS на обеих сторонах |

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

| Проблема | Причина | Решение |
|---|---|---|
| Нет ответа на ping | Отсутствуют правила на вкладке IPsec | Создайте правила, разрешающие трафик между подсетями |
| Односторонний трафик | Правила созданы только в одном направлении | Добавьте правила для обоих направлений |
| Пакеты уходят, ответы не приходят | Асимметричная маршрутизация | Проверьте таблицу маршрутизации на обоих узлах |
| MTU-проблемы | Фрагментация из-за IPsec overhead | Уменьшите MSS через **System > Advanced > Firewall & NAT** (MSS Clamping) или настройте MTU на интерфейсах |

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

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

```bash
# 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](/docs/pfsense/firewall/pfsense-firewall-rules/) - принципы создания и управления правилами файрвола, необходимые для корректной работы IPsec-туннелей
- [Алиасы файрвола pfSense](/docs/pfsense/firewall/pfsense-firewall-aliases/) - использование алиасов для упрощения управления IP-адресами и подсетями в правилах IPsec
- [NAT в pfSense](/docs/pfsense/nat/) - настройка NAT, включая особенности взаимодействия NAT и IPsec