# Диагностика IPsec VPN в pfSense - устранение неполадок

> Диагностика и устранение неполадок IPsec VPN в pfSense - анализ логов, типичные ошибки Phase 1 и Phase 2, несовпадение параметров и проблемы с NAT-T

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


IPsec - протокол с жёсткими требованиями к совпадению параметров на обеих сторонах туннеля. Несоответствие даже одного параметра (алгоритм шифрования, группа DH, маска подсети) приводит к отказу в установлении соединения, причём сообщения об ошибках не всегда указывают на первопричину. Систематический подход к диагностике позволяет сократить время поиска проблемы с часов до минут.

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

## Включение отладочных логов

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

### Настройка уровня логирования

Перейдите в **VPN > IPsec > Advanced Settings** и настройте параметры логирования:

| Параметр | Рекомендуемый уровень | Назначение |
|---|---|---|
| IKE SA | Diag | Детальная информация о согласовании Phase 1 |
| IKE Child SA | Diag | Детальная информация о согласовании Phase 2 |
| Configuration Backend | Diag | Загрузка конфигурации и параметров |
| IKE Network Events | Control | Сетевые события (подключения, разрывы) |
| IKE Message Encoding | Control | Кодирование и декодирование IKE-сообщений |
| IKE Manager | Control | Управление IKE SA |
| все остальные | Control | Стандартный уровень |

Нажмите **Save**. Изменение уровня логирования не прерывает существующие IPsec-туннели.

> **Внимание**:
>
> Уровень Diag генерирует значительный объём логов. После завершения диагностики рекомендуется вернуть уровни к Control, чтобы избежать заполнения дискового пространства.

### Просмотр логов

Логи IPsec доступны в **Status > System Logs > IPsec**. Для фильтрации используйте поле поиска в верхней части страницы.

Для просмотра логов в реальном времени через командную строку:

```bash
# Real-time IPsec log monitoring
clog -f /var/log/ipsec.log

# Filter for specific peer IP
clog -f /var/log/ipsec.log | grep "203.0.113.10"

# Filter for errors only
clog -f /var/log/ipsec.log | grep -i "error\|failed\|no proposal"
```

### Ключевые индикаторы в логах

Следующие записи указывают на успешное или неуспешное согласование:

| Запись в логе | Значение |
|---|---|
| `IKE_SA ... established` | Phase 1 успешно установлена |
| `CHILD_SA ... established` | Phase 2 успешно установлена, туннель активен |
| `received NO_PROPOSAL_CHOSEN` | Удалённая сторона отклонила предложенные параметры |
| `received AUTHENTICATION_FAILED` | Ошибка аутентификации (PSK или сертификат) |
| `no matching CHILD_SA config found` | Несовпадение подсетей (Traffic Selectors) |
| `giving up after N retransmits` | Удалённая сторона не отвечает |
| `peer didn't accept any proposal` | Ни один из предложенных наборов параметров не подошёл |

## Типичные ошибки Phase 1

Phase 1 (IKE SA) отвечает за аутентификацию сторон и согласование параметров безопасности. Ошибки на этом этапе полностью блокируют установление туннеля.

### Несовпадение параметров шифрования

| Сообщение об ошибке | Причина | Решение |
|---|---|---|
| `received NO_PROPOSAL_CHOSEN` | Несовпадение алгоритма шифрования, хеша или DH Group | Сравните параметры Encryption Algorithm на обеих сторонах; все три компонента (шифр, хеш, DH Group) должны совпадать |
| `no acceptable ENCRYPTION_ALGORITHM found` | Удалённая сторона не поддерживает предложенный алгоритм | Добавьте алгоритм, поддерживаемый удалённой стороной, или согласуйте общий набор |
| `no acceptable INTEGRITY_ALGORITHM found` | Несовпадение алгоритма хеширования | Установите одинаковый Hash Algorithm (SHA256, SHA384, SHA512) на обеих сторонах |
| `no acceptable DIFFIE_HELLMAN_GROUP found` | Несовпадение группы DH | Установите одинаковый DH Group; рекомендуется Group 14 (2048 bit) или выше |

При использовании AES-GCM в Phase 1 обратите внимание, что некоторые реализации (Cisco ASA, устаревшие версии MikroTik) не поддерживают GCM для IKE. В этом случае используйте AES-CBC с отдельным алгоритмом хеширования.

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

| Сообщение об ошибке | Причина | Решение |
|---|---|---|
| `received AUTHENTICATION_FAILED` | Несовпадение PSK или ошибка проверки сертификата | При PSK: проверьте точное совпадение ключей (регистр, пробелы, спецсимволы). При сертификатах: убедитесь, что CA-сертификат импортирован на обеих сторонах |
| `PEER_AUTH_FAILED` | Удалённая сторона не прошла проверку подлинности | Проверьте идентификатор удалённой стороны (IP, FQDN, DN) |
| `invalid HASH_V1 payload length, decryption failed?` | Несовпадение PSK (IKEv1) | Пересоздайте PSK на обеих сторонах |
| `could not decrypt payloads` | Несовпадение PSK | Проверьте PSK на обеих сторонах, обращая внимание на невидимые символы (пробелы в конце строки) |

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

### Ошибки идентификаторов

| Сообщение об ошибке | Причина | Решение |
|---|---|---|
| `no IKE config found for ... - ...` | Идентификатор удалённой стороны не совпадает с настройками | Проверьте значения My identifier и Peer identifier на обеих сторонах |
| `remote host is behind NAT, sending keep alives` + отказ | Peer identifier настроен на IP, но NAT подменяет адрес | Измените Peer identifier на ID типа `Distinguished Name` или `User FQDN` вместо `Peer IP Address` |
| `parsed CERT_REQ payload, but no certificate found` | Запрошен сертификат, но он не настроен | Проверьте, что серверный сертификат указан в Phase 1 и не истёк |

### Недоступность удалённого узла

| Сообщение об ошибке | Причина | Решение |
|---|---|---|
| `giving up after 5 retransmits` | Удалённый узел не отвечает | Проверьте: 1) IP-адрес удалённого узла; 2) UDP 500 и 4500 не блокируются; 3) IPsec-сервис запущен на удалённом узле |
| `connection timed out` | Нет сетевой связности | Проверьте маршрутизацию до удалённого узла (ping, traceroute) |
| `sending retransmit N of request message` | Пакеты отправляются, но ответ не приходит | Проблема может быть на промежуточном оборудовании (файрвол ISP, NAT-устройство) |

### DPD-ошибки

| Сообщение об ошибке | Причина | Решение |
|---|---|---|
| `DPD: peer is considered dead` | Удалённый узел не ответил на DPD-запросы | Проверьте сетевую связность; увеличьте DPD Delay (30 секунд) и Max Failures (10) |
| `deleting IKE_SA ... after DPD timeout` | Туннель удалён из-за DPD-таймаута | Если канал связи нестабилен, увеличьте DPD-таймеры или используйте keep-alive ping |
| Частые разрывы и переподключения | Потеря UDP-пакетов на промежуточном оборудовании | Проверьте качество канала; при использовании QoS убедитесь, что UDP 500/4500 не ограничивается |

## Типичные ошибки Phase 2

Phase 2 (Child SA / IPsec SA) согласуется внутри защищённого канала Phase 1. Ошибки Phase 2 возникают при установленной Phase 1 - статус Phase 1 показывает `Established`, но Child SA не создаётся.

### Несовпадение подсетей (Traffic Selectors)

| Сообщение об ошибке | Причина | Решение |
|---|---|---|
| `no matching CHILD_SA config found` | Подсети в Phase 2 не совпадают с предложенными удалённой стороной | Убедитесь, что Local Network на одной стороне соответствует Remote Network на другой (зеркальное совпадение) |
| `TS_UNACCEPTABLE` | Traffic Selectors отклонены | Проверьте маску подсети: `/24` и `/32` - разные значения. Распространённая ошибка - указать хост (`10.1.0.0/32`) вместо сети (`10.1.0.0/24`) |
| `received TS_UNACCEPTABLE notify, no CHILD_SA built` | Удалённая сторона не приняла предложенные подсети | Сравните Traffic Selectors в логах обеих сторон |

> **Внимание**:
>
> Несовпадение подсетей - наиболее распространённая причина отказа Phase 2. Маска подсети должна совпадать побитово: `10.1.0.0/24` на одной стороне и `10.1.0.0/24` на другой (не `10.1.0.0/23` или `10.1.0.0/32`).

### Несовпадение параметров шифрования Phase 2

| Сообщение об ошибке | Причина | Решение |
|---|---|---|
| `NO_PROPOSAL_CHOSEN` (при установленной Phase 1) | Несовпадение алгоритма шифрования или хеша Phase 2 | Проверьте Encryption Algorithm и Hash Algorithm в Phase 2 на обеих сторонах |
| `no acceptable ENCRYPTION_ALGORITHM found` | Предложенный алгоритм не поддерживается | Согласуйте общий алгоритм; AES-256-GCM или AES-256-CBC - наиболее совместимые варианты |
| `no acceptable INTEGRITY_ALGORITHM found` | Несовпадение Hash Algorithm | Установите одинаковый Hash Algorithm в Phase 2 |

### Несовпадение PFS

| Сообщение об ошибке | Причина | Решение |
|---|---|---|
| `no acceptable DIFFIE_HELLMAN_GROUP found` (в Phase 2) | Несовпадение PFS Group | Установите одинаковый PFS key group на обеих сторонах или отключите PFS на обеих |
| `INVALID_KE_PAYLOAD` | Удалённая сторона отправила ключ DH другой длины | Проверьте PFS Group; одна сторона может использовать Group 14, другая - Group 2 |
| Phase 2 устанавливается, но через час падает | PFS включён на одной стороне и отключён на другой | При rekeying PFS-параметры проверяются повторно; обеспечьте совпадение или отключите PFS на обеих сторонах |

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

Если Phase 1 и Phase 2 установлены (статус `Established`), но пользовательский трафик не проходит, проблема лежит за пределами IPsec-согласования.

| Проблема | Причина | Решение |
|---|---|---|
| Нет ответа на ping через туннель | Отсутствуют правила на вкладке **Firewall > Rules > IPsec** | Создайте правила, разрешающие трафик между подсетями |
| Трафик идёт только в одном направлении | Правила файрвола настроены только в одну сторону | Добавьте правила для обоих направлений на обеих сторонах |
| Ответные пакеты не возвращаются | Асимметричная маршрутизация: ответный трафик уходит мимо туннеля | Проверьте таблицу маршрутизации на удалённой стороне; убедитесь, что ответный трафик попадает в Policy SPD |
| Пакеты фрагментируются и теряются | MTU-проблемы из-за IPsec overhead | Уменьшите MSS через **System > Advanced > Firewall & NAT** (MSS Clamping) или уменьшите MTU на интерфейсах |
| Трафик ICMP проходит, TCP зависает | MSS не уменьшен для учёта IPsec overhead | Включите MSS Clamping; IPsec добавляет 50-73 байта к каждому пакету |
| Дублированные SA (два одинаковых Child SA) | Одновременный rekeying обеими сторонами | Перезапустите IPsec-сервис на одной стороне: `ipsec restart` |

## Проблемы с NAT-T

NAT Traversal (NAT-T) необходим, когда между двумя узлами IPsec-туннеля находится NAT-устройство (маршрутизатор, провайдерское оборудование). NAT-T инкапсулирует пакеты ESP в UDP порт 4500, позволяя им проходить через NAT.

### Когда NAT-T необходим

- Один или оба узла IPsec находятся за NAT (имеют приватный IP-адрес на WAN-интерфейсе)
- Между узлами находится маршрутизатор, выполняющий трансляцию адресов
- Провайдер использует Carrier-Grade NAT (CG-NAT)

### Типичные проблемы NAT-T

| Проблема | Причина | Решение |
|---|---|---|
| Phase 1 не устанавливается через NAT | NAT Traversal отключён | Установите NAT Traversal в `Auto` или `Force` на обеих сторонах |
| Phase 1 устанавливается, Phase 2 - нет | UDP 4500 блокируется промежуточным оборудованием | Проверьте проброс UDP 4500 на NAT-устройстве |
| `remote host is behind NAT` + ошибка идентификатора | Peer identifier настроен на IP-адрес, но NAT подменил адрес | Измените Peer identifier на `Distinguished Name` или `User FQDN` |
| Периодические разрывы через NAT | NAT-таблица на промежуточном устройстве истекает | Включите DPD с интервалом менее таймаута NAT-таблицы (обычно 60-300 секунд); убедитесь, что NAT keep-alive пакеты отправляются |
| Двойной NAT (NAT на обеих сторонах) | ESP не может пройти через два NAT-устройства без NAT-T | Включите Force NAT-T на обеих сторонах; обеспечьте проброс UDP 500 и 4500 на обоих NAT-устройствах |

### Проверка NAT-T

Для проверки работы NAT-T выполните захват пакетов на WAN-интерфейсе:

```bash
# Capture IKE and NAT-T traffic
tcpdump -ni em0 udp port 500 or udp port 4500

# Expected output with NAT-T active:
# 10.0.0.1.4500 > 203.0.113.10.4500: UDP-encap: ESP(spi=0x12345678,seq=0x1)
```

Если трафик виден на порту 4500 с пометкой `UDP-encap: ESP`, NAT-T работает корректно. Если трафик идёт по протоколу ESP (порт 50) при наличии NAT, туннель будет нестабильным.

## Диагностические команды

pfSense предоставляет набор команд для диагностики IPsec через **Diagnostics > Command Prompt** или SSH-подключение.

### Состояние IPsec SA

```bash
# Complete SA status with negotiated parameters
ipsec statusall

# Brief status (established tunnels only)
ipsec status

# View IP addresses assigned to mobile clients
ipsec leases
```

Команда `ipsec statusall` отображает:

- Согласованные алгоритмы шифрования и хеширования
- Группу DH и PFS
- Время до истечения SA
- Traffic Selectors (подсети)
- Количество переданных байтов
- Текущий статус IKE SA и Child SA

### Таблица Security Policy Database (SPD)

```bash
# View installed security policies
setkey -DP

# View installed security associations
setkey -D
```

Команда `setkey -DP` показывает, какие пакеты должны обрабатываться IPsec (направляться в туннель). Если политика отсутствует для нужной пары подсетей, трафик не будет зашифрован.

### Правила файрвола

```bash
# View all active firewall rules
pfctl -sr

# View rules for IPsec interface (enc0)
pfctl -sr | grep enc0

# View blocked packets in real time
tcpdump -ni pflog0
```

### Захват пакетов

```bash
# Capture IKE negotiation on WAN
tcpdump -ni em0 udp port 500 or udp port 4500

# Capture ESP traffic (without NAT-T)
tcpdump -ni em0 proto 50

# Capture decrypted traffic on IPsec interface
tcpdump -ni enc0

# Capture with detailed output and write to file
tcpdump -ni em0 -vvv -s 0 -w /tmp/ipsec-capture.pcap udp port 500 or udp port 4500
```

Захват на интерфейсе `enc0` показывает расшифрованный трафик внутри туннеля. Это позволяет определить, доходят ли пакеты до pfSense через туннель и в каком виде.

### Просмотр маршрутов

```bash
# View routing table
netstat -rn

# Check if route for remote subnet exists
netstat -rn | grep "10.2.0.0"

# View gateway groups status
pfctl -vvsA
```

### Управление IPsec-сервисом

```bash
# Restart IPsec service (drops all tunnels)
ipsec restart

# Reload configuration without dropping tunnels
ipsec update

# Terminate specific IKE SA
ipsec down <connection_name>

# Re-initiate specific connection
ipsec up <connection_name>
```

> **Внимание**:
>
> Команда `ipsec restart` разрывает все активные туннели. В производственной среде предпочтительнее использовать `ipsec update` для применения изменений конфигурации без разрыва существующих соединений.

## Проблемы при переустановлении (Rekeying)

Туннели IPsec имеют ограниченное время жизни. По истечении этого времени происходит rekeying - согласование нового ключевого материала. Ошибки при rekeying приводят к периодическим разрывам туннеля.

| Проблема | Причина | Решение |
|---|---|---|
| Туннель падает каждые N часов | Ошибка при rekeying Phase 1 или Phase 2 | Проверьте, совпадают ли Lifetime на обеих сторонах; проверьте логи в момент rekeying |
| Туннель падает и не восстанавливается | Child SA Start Action не настроен | Установите Child SA Start Action в `Start` для автоматического переподключения |
| Двойные SA после rekeying | Обе стороны одновременно инициируют rekeying | Установите разные Lifetime на разных сторонах (например, 28800 и 28200 для Phase 1) или убедитесь, что Rand Time не обнулён |
| Односторонний rekeying работает, двусторонний - нет | Настройки принимаются при инициации с одной стороны, но не с другой | Все параметры должны совпадать; проверьте, не добавлены ли дополнительные алгоритмы на одной стороне |

## Чек-лист диагностики

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

### 1. Сетевая связность

- [ ] Удалённый узел доступен: `ping <remote_public_ip>`
- [ ] Маршрут до удалённого узла существует: `traceroute <remote_public_ip>`
- [ ] UDP 500 не блокируется: `nc -uzv <remote_public_ip> 500`
- [ ] UDP 4500 не блокируется: `nc -uzv <remote_public_ip> 4500`

### 2. Параметры Phase 1

- [ ] Версия IKE совпадает (IKEv1 или IKEv2)
- [ ] Алгоритм шифрования совпадает
- [ ] Hash Algorithm совпадает
- [ ] DH Group совпадает
- [ ] Lifetime совпадает (допускается разница; меньшее значение используется)
- [ ] Метод аутентификации совпадает (PSK или сертификаты)
- [ ] PSK идентичен на обеих сторонах (при использовании PSK)
- [ ] Идентификаторы (My/Peer) настроены корректно

### 3. Параметры Phase 2

- [ ] Подсети (Traffic Selectors) зеркально совпадают
- [ ] Маски подсетей корректны (`/24` vs `/32`)
- [ ] Алгоритм шифрования Phase 2 совпадает
- [ ] Hash Algorithm Phase 2 совпадает
- [ ] PFS Group совпадает или отключён на обеих сторонах
- [ ] Протокол ESP (не AH)

### 4. Сертификаты (при использовании)

- [ ] CA-сертификат импортирован на обеих сторонах
- [ ] Серверный сертификат не истёк (проверьте дату)
- [ ] SAN в серверном сертификате содержит IP или FQDN сервера
- [ ] Цепочка доверия сертификатов полная
- [ ] Для Apple-устройств: Lifetime серверного сертификата не более 825 дней

### 5. Правила файрвола

- [ ] UDP 500 и 4500 разрешены на WAN
- [ ] Правила на вкладке IPsec разрешают трафик между подсетями
- [ ] Нет конфликтующих плавающих правил
- [ ] NAT Traversal включён (Auto или Force) при наличии NAT

### 6. Маршрутизация и SA

- [ ] В `ipsec statusall` отображаются установленные SA
- [ ] В `setkey -DP` присутствуют политики для нужных подсетей
- [ ] В `netstat -rn` присутствует маршрут до удалённой подсети (для VTI)
- [ ] Счётчики байтов в Status > IPsec увеличиваются при прохождении трафика

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

- [IPsec Site-to-Site VPN в pfSense](/docs/pfsense/vpn/ipsec/pfsense-ipsec-site-to-site/) - настройка site-to-site туннелей, терминология IPsec и параметры Phase 1/Phase 2
- [IPsec IKEv2 для мобильных клиентов в pfSense](/docs/pfsense/vpn/ipsec/pfsense-ipsec-mobile-clients/) - настройка IKEv2 для удалённого доступа, сертификаты и конфигурация клиентских устройств
- [Правила файрвола pfSense](/docs/pfsense/firewall/pfsense-firewall-rules/) - принципы создания и управления правилами файрвола для VPN-трафика
- [NAT в pfSense](/docs/pfsense/nat/) - настройка NAT, включая взаимодействие NAT и IPsec