IPSec VPN Fortigate застрял на фазе 2.

Вопрос или проблема

Пытаюсь настроить VPN соединение с Office Fortigate, но не могу пройти фазу 2.

Полученная информация от системных администраторов:

  • PSK
  • IKE v1
  • Агрессивный режим

  • Фаза 1 3DES-SHA1

  • Группа DH 5
  • Время жизни ключа 28800

  • XAUTH PAP Сервер (не уверен, нужно ли это знать)

  • Фаза 2 3DES-SHA1

  • PFS нет

Это одна из многих попыток конфигурации, я пробовал добавлять/удалять различные параметры.

config setup
interfaces=%defaultroute
plutodebug="control parsing"
plutoopts="--interface=wlan0"
dumpdir=/var/run/pluto/
nat_traversal=no
virtual_private=%v4:
10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:25.0.0.0/8,%v6:fd00::/8,%v6:fe80::/10
oe=off
protostack=netkey

conn office
left=%defaultroute
right=

phase2=ah
phase2alg=sha1;modp1536
type=transport
authby=secret
pfs=no
compress=no
   keyingtries=%forever

вывод

?  /etc  sudo service ipsec restart
?  /etc  sudo ipsec auto --add office && sudo ipsec auto --up office
104 "office" #1: STATE_MAIN_I1: initiate
003 "office" #1: received Vendor ID payload [Dead Peer Detection]
003 "office" #1: ignoring unknown Vendor ID payload
[8299031757a36082c6a621de00050282]
106 "office" #1: STATE_MAIN_I2: sent MI2, expecting MR2
108 "office" #1: STATE_MAIN_I3: sent MI3, expecting MR3
003 "office" #1: discarding duplicate packet; already STATE_MAIN_I3
010 "office" #1: STATE_MAIN_I3: retransmission; will wait 20s for response
003 "office" #1: discarding duplicate packet; already STATE_MAIN_I3
010 "office" #1: STATE_MAIN_I3: retransmission; will wait 40s for response
031 "office" #1: max number of retransmissions (2) reached STATE_MAIN_I3.
Possible authentication failure: no acceptable response to our first
encrypted message
000 "office" #1: starting keying attempt 2 of an unlimited number, but
releasing whack

Обновление

Добавил агрессивный режим в свою конфигурацию и получил ошибку о неверной хэш информации, как так? Разве параметры установлены неправильно?

conn office 
    aggrmode=yes
     left=%defaultroute
     right=
     phase2=ah
     phase2alg=sha1;modp1536
     type=transport
     ike=3des-sha1;modp1536

     authby=secret
     #esp=3des;modp1536
     pfs=no
     compress=no
     keyingtries=%forever

Вывод

➜  /etc  sudo ipsec auto --up office 
112 "office" #1: STATE_AGGR_I1: initiate
003 "office" #1: received Vendor ID payload [Dead Peer Detection]
003 "office" #1: received Vendor ID payload [XAUTH]
003 "office" #1: ignoring unknown Vendor ID payload [8299031757a36082c6a621de00050282]
003 "office" #1: received Hash Payload does not match computed value
223 "office" #1: STATE_AGGR_I1: INVALID_HASH_INFORMATION

ipsec auto –status

000 "office":     myip=unset; hisip=unset;
000 "office":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0
000 "office":   policy: PSK+AUTHENTICATE+UP+AGGRESSIVE+IKEv2ALLOW+SAREFTRACK+lKOD+rKOD; prio: 32,24; interface: wlan0; 
000 "office":   newest ISAKMP SA: #0; newest IPsec SA: #0; 
000 "office":   IKE algorithms wanted: 3DES_CBC(5)_000-SHA1(2)_000-MODP1536(5); flags=-strict
000 "office":   IKE algorithms found:  3DES_CBC(5)_192-SHA1(2)_160-MODP1536(5)
000 "office":   AH algorithms wanted: SHA1(2)_000; pfsgroup=MODP1536(5); flags=-strict
000 "office":   AH algorithms loaded: SHA1(2)_160
000  
000 #3: "office":500 STATE_AGGR_I1 (sent AI1, expecting AR1); none in -1s; lastdpd=-1s(seq in:0 out:0); idle; import:admin initiate
000 #3: pending Phase 2 for "office" replacing #0

Обновление 2

Удалось пройти фазу 1. Анализ журналов брандмауэра показал, что установленный туннель отличается от ожидаемого и имеет другой PSK.

Теперь ошибки при согласовании фазы 2. Системный администратор говорит, что для фазы 2 требуется пользователь, хотя я не уверен, как я бы это указал?

➜  /etc  sudo ipsec auto --up office 
104 "office" #2: STATE_MAIN_I1: initiate
003 "office" #2: received Vendor ID payload [RFC 3947] method set to=109 
003 "office" #2: received Vendor ID payload [Dead Peer Detection]
003 "office" #2: ignoring unknown Vendor ID payload [8299031757a36082c6a621de00050282]
106 "office" #2: STATE_MAIN_I2: sent MI2, expecting MR2
003 "office" #2: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): i am NATed
108 "office" #2: STATE_MAIN_I3: sent MI3, expecting MR3
004 "office" #2: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp1024}
117 "office" #3: STATE_QUICK_I1: initiate
010 "office" #3: STATE_QUICK_I1: retransmission; will wait 20s for response
010 "office" #3: STATE_QUICK_I1: retransmission; will wait 40s for response
031 "office" #3: max number of retransmissions (2) reached STATE_QUICK_I1.  No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
000 "office" #3: starting keying attempt 2 of an unlimited number, but releasing whack

Без логов получателя (Fortigate) сложно дать точный ответ.

Начнем с очевидного: перенастройте ваш VPN в основной режим (не агрессивный режим) и измените тип с transport на tunnel.

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

.

Ответ или решение

Для решения проблемы, связанной с застреванием IPSec VPN на Fortigate на фазе 2, важно системно подойти к анализу и устранению неполадок. В данном случае, вы сталкиваетесь с проблемными моментами в переговорах для установления безопасного соединения по IPSec VPN. Рассмотрим теорию, примеры и практическую реализацию для решения вашей задачи.

Теория

IPSec (Internet Protocol Security) — это протокол, используемый для защиты данных на уровне сетевого протокола путем шифрования и проверки целостности данных, обеспечивая конфиденциальность между двумя узлами. Конфигурация IPSec VPN чаще всего делится на две фазы:

  1. Фаза 1 (IKE Phase 1): Основной задачей является установление защищенного канала обмена ключами шифрования с помощью протокола IKE (Internet Key Exchange).

  2. Фаза 2 (IKE Phase 2): Установление окончательных параметров безопасности и образование безопасных каналов, так называемых Security Association (SA), для защиты пользовательных данных.

Основные шаги в процессе настройки и устранения проблем связаны с правильной конфигурацией и отладкой:

  • Проверьте соответствие параметров на обеих сторонах (на клиентском и серверном оборудовании).
  • Используйте соответствующий протокол IKE (в вашем случае IKEv1).
  • Убедитесь в правильности PSK (предварительно согласованного ключа).
  • Соответствие алгоритмов шифрования и аутентификации.
  • Проверьте отсутствие несоответствий в конфигурации (например, модификация DH группы).

Примеры

Вы упоминаете, что конфигурации пробывались в нескольких вариациях. Перед вами один из них с ручной конфигурацией через команду conn office. Давайте выделим некоторые ключевые пункты:

  • Использование aggrmode=yes указывает на агрессивный режим. Этот режим снижает количество обменов сообщениями, но увеличивает уязвимость, так как аутентификация проходит быстрее и с меньшей стойкостью к атакам.
  • Указание phase2=ah, хотя в конфигурации от администраторов говорилось про 3DES-SHA1, что указывает эсп-алгоритм с шифрованием, а не AH (Authentication Header).
  • Проблема с хешем может указывать на несоответствие PSK или аутентификационного алгоритма.

Применение

  1. Переконфигурация:

    • Вернитесь к основному режиму (Main Mode) вместо агрессивного. Это позволит улучшить защиту данных на первом этапе обмена ключами.
    • Убедитесь в использовании правильных параметров в IKE для обоих фаз: 3DES для шифрования и SHA1 для хэширования.
    • Укажите явно PFS. Если PFS не должен быть использован, то pfs=no.
  2. Тестирование и отладка:

    • Перейдите к tunnel вместо transport, чтобы избежать ошибки в типе соединения.
    • Проверьте настройки брандмауэра Fortigate с рассмотрением детальных журналов. Это возможно сделать, если у вас есть доступ к логам сервера.
  3. Используйте Fortigate Логи:

    • Без логов со стороны получателя бывает сложно понять корневую проблему. Попробуйте получить файлы логов на Fortigate, включив подробное логирование или обратившись к системному администратору.
  4. Проверка требований к аутентификации:

    • Если требуется пользователь для фазы 2, возможно, вам потребуется внедрение XAUTH (расширенной аутентификации), где может потребоваться указать имя пользователя и пароль.

На основании этой информации у вас должен появиться более четкий контекст и план действий для использования как диагностических, так и исправительных мер для установления надёжного и безопасного VPN-соединения. Работайте тесно с вашей командой администраторов, чтобы гарантировать все аспекты сетевой безопасности.

Оцените материал
Добавить комментарий

Капча загружается...