Ipsec Ikev2 road warriors (mobile) - разрыв соединения через 8 часов
-
Всем привет!
Настроил ipsec mobile c ikev2, аутентификация пользователей через RADIUS (AD)
клиенты Windows 10, соединение разрывается после 8 часов работы туннеля, в целом для работы на весь рабочий день хватает, но есть задачи, которые требуют соединения почти 24x7 с файловым сервером, который за pfВ 1 фазе, время жизни выставил до 24 часов (86400sec) - но все равно происходит разрыв через 8 часов. во второй фазе время жизни ключа стандартно, 3600 (т.е 1 час)
подскажите, где еще нужно донастроить что-то?
может быть на клиенте? -
@mikeroygbiv
Здр
Покажите логи в момент разрыва соединения
С вероятностью 99% "дурит" windows , странно только то , что 8 часов именно . Обычно через час "рвет" соединение.
Попробуйте установить параметр "disable rekey" в настройках фазы 1 vpn сервера.
тогда клиент windows будет сам инициировать процесс обновления ключей. -
Спасибо за ответ!
вот кусок лога,
100.100.100.100 - клиент
200.200.200.200 - серверTime Process PID Message
Apr 29 07:33:35 charon 07[NET] <con-mobile|3> received packet: from 100.100.100.100[4500] to 200.200.200.200[4500] (580 bytes)
Apr 29 07:33:35 charon 07[ENC] <con-mobile|3> parsed CREATE_CHILD_SA request 22 [ EF(2/3) ]
Apr 29 07:33:35 charon 07[ENC] <con-mobile|3> received fragment #2 of 3, waiting for complete IKE message
Apr 29 07:33:35 charon 09[NET] <con-mobile|3> received packet: from 100.100.100.100[4500] to 200.200.200.200[4500] (164 bytes)
Apr 29 07:33:35 charon 09[ENC] <con-mobile|3> parsed CREATE_CHILD_SA request 22 [ EF(3/3) ]
Apr 29 07:33:35 charon 09[ENC] <con-mobile|3> received fragment #3 of 3, reassembled fragmented IKE message (1152 bytes)
Apr 29 07:33:35 charon 09[ENC] <con-mobile|3> parsed CREATE_CHILD_SA request 22 [ SA KE No N(FRAG_SUP) ]
Apr 29 07:33:35 charon 09[IKE] <con-mobile|3> received retransmit of request with ID 22, retransmitting response
Apr 29 07:33:35 charon 09[NET] <con-mobile|3> sending packet: from 200.200.200.200[4500] to 100.100.100.100[4500] (304 bytes)
Apr 29 07:33:45 charon 09[IKE] <con-mobile|3> sending DPD request
Apr 29 07:33:45 charon 09[IKE] <con-mobile|3> queueing IKE_DPD task
Apr 29 07:33:45 charon 09[IKE] <con-mobile|3> activating new tasks
Apr 29 07:33:45 charon 09[IKE] <con-mobile|3> nothing to initiate
Apr 29 07:33:55 charon 07[IKE] <con-mobile|3> sending DPD request
Apr 29 07:33:55 charon 07[IKE] <con-mobile|3> queueing IKE_DPD task
Apr 29 07:33:55 charon 07[IKE] <con-mobile|3> activating new tasks
Apr 29 07:33:55 charon 07[IKE] <con-mobile|3> nothing to initiate
Apr 29 07:34:05 charon 07[IKE] <con-mobile|3> sending DPD request
Apr 29 07:34:05 charon 07[IKE] <con-mobile|3> queueing IKE_DPD task
Apr 29 07:34:05 charon 07[IKE] <con-mobile|3> activating new tasks
Apr 29 07:34:05 charon 07[IKE] <con-mobile|3> nothing to initiate
Apr 29 07:34:11 charon 07[IKE] <con-mobile|3> destroying IKE_SA in state REKEYED without notification
Apr 29 07:34:11 charon 07[IKE] <con-mobile|3> IKE_SA con-mobile[3] state change: REKEYED => DESTROYING
Apr 29 07:42:18 charon 07[IKE] <con-mobile|5> sending DPD request
Apr 29 07:42:18 charon 07[IKE] <con-mobile|5> queueing IKE_DPD task
Apr 29 07:42:18 charon 07[IKE] <con-mobile|5> activating new tasks
Apr 29 07:42:18 charon 07[IKE] <con-mobile|5> activating IKE_DPD task
Apr 29 07:42:18 charon 07[ENC] <con-mobile|5> generating INFORMATIONAL request 0 [ ]
Apr 29 07:42:18 charon 07[NET] <con-mobile|5> sending packet: from 200.200.200.200[4500] to 100.100.100.100[4500] (80 bytes)
Apr 29 07:42:22 charon 07[IKE] <con-mobile|5> retransmit 1 of request with message ID 0
Apr 29 07:42:22 charon 07[NET] <con-mobile|5> sending packet: from 200.200.200.200[4500] to 100.100.100.100[4500] (80 bytes)
Apr 29 07:42:29 charon 07[IKE] <con-mobile|5> retransmit 2 of request with message ID 0
Apr 29 07:42:29 charon 07[NET] <con-mobile|5> sending packet: from 200.200.200.200[4500] to 100.100.100.100[4500] (80 bytes)
Apr 29 07:42:42 charon 07[IKE] <con-mobile|5> retransmit 3 of request with message ID 0
Apr 29 07:42:42 charon 07[NET] <con-mobile|5> sending packet: from 200.200.200.200[4500] to 100.100.100.100[4500] (80 bytes)
Apr 29 07:43:06 charon 07[IKE] <con-mobile|5> retransmit 4 of request with message ID 0
Apr 29 07:43:06 charon 07[NET] <con-mobile|5> sending packet: from 200.200.200.200[4500] to 100.100.100.100[4500] (80 bytes)
Apr 29 07:43:48 charon 10[IKE] <con-mobile|5> retransmit 5 of request with message ID 0
Apr 29 07:43:48 charon 10[NET] <con-mobile|5> sending packet: from 200.200.200.200[4500] to 100.100.100.100[4500] (80 bytes)
Apr 29 07:45:03 charon 10[IKE] <con-mobile|5> giving up after 5 retransmits
Apr 29 07:45:03 charon 10[CFG] <con-mobile|5> RADIUS server 'radius' is candidate: 210
Apr 29 07:45:03 charon 10[CFG] <con-mobile|5> sending RADIUS Accounting-Request to server 'radius'
Apr 29 07:45:03 charon 10[CFG] <con-mobile|5> received RADIUS Accounting-Response from server 'radius'
Apr 29 07:45:03 charon 10[IKE] <con-mobile|5> IKE_SA con-mobile[5] state change: ESTABLISHED => DESTROYING
Apr 29 07:45:03 charon 10[CHD] <con-mobile|5> CHILD_SA con-mobile{15} state change: INSTALLED => DESTROYING
Apr 29 07:45:03 charon 10[CFG] <con-mobile|5> lease 10.80.5.1 by 'vpnuser' went offline -
@mikeroygbiv
Попробуйте сделать , как я написал
Судя по логам это происходит в момент обновления ключей
Эта проблема обычно вылезает на windows 7+ikev2+клиент за NAT-ом ( и ,как правило,через 1 час соединения ) -
@Konstanti
да, я уже ранее включил эту опцию, но и с ней не помогло..после включения этой опции, в статусе ipsec соединений, в поле Reauth появился символ - (прочерк), т.е по идее да, разрыва не должно происходить
через час ни разу не разрывалось, у всех клиентов соединение со статусом ESTABLISHED держится примерно 7:49 часов..
все клиенты windows 10 (1607, 1903) да и на windows 7 тоже через час не разрывается, (я так полагаю, на это влияет настройка в Фазе 2, время жизни ключа, 3600 сек) -
@Konstanti
В логах, каждый час идет обмен ключами, при этом соединение не разрывается -
Добрый.
Версия пф?
Смотрите баг-трекер пф. Если найдется что-то, то смените временно на Openvpn. -
@werter
добрый !версия 2.4.4_p3
да, видимо придется задействовать еще один OpenVPN сервер с широким доступом.
один сервер уже запущен, на нем основная группа пользователей, там все порезаноipsec конечно быстрее, поэтому особо требовательным пользователям к пропускной способности решил дать его.
-
@mikeroygbiv
Обновитесь. -
@werter
надеюсь это поможет))
но думаю врядлиа вы не сталкивались с таким на Windows+PF ?
при условии, что ipsec соединение устанавливается нативно.возможно, надо попробовать сторонний клиент
Shrew Soft например.
спасибо за ответы!!
буду сюда отписываться по результатам -
@mikeroygbiv
Пользую, где возможно ovpn. Он гораздо гибче. -
@mikeroygbiv
Я бы разбирался все-таки с клиентом Windows , есть ли там логи ( не знаю ) . Не может быть такого , чтобы у всех одновременно проблемы начинались
Я вот вижу в логах , что клиенты перестают отвечать (con-mobile<3>). как следствие ike_sa удалили.а второй клиент почему-то перестает отвечать на dpd запросы
Всей картины не видно , Вы же кусок лога "вырезали", судя по всему
-
@Konstanti said in Ipsec Ikev2 road warriors (mobile) - разрыв соединения через 8 часов:
Я бы разбирался все-таки с клиентом Windows , есть ли там логи ( не знаю ) .
Может в "Просмотре событий" Вин что-то есть.
-
В Event Viewer ничего путного не нашел..может конечно не те параметры выбирал для поиска
но все что касается VPN, RasMan итд - ни очем не говорящие ошибки отключения туннеля да и только.пока что сделал новый сервер Ovpn
по дефолту там тоже каждый час разрыв, но reneg-sec 0 решает этот вопрос
только что наверное это не совсем правильно.. -
@werter
Обновился на тестовом стенде
посмотримда, версия strongswan теперь посвежее, за декабрь 2019
5.8.2хотя в самой свежей, 5.8.3 есть изменения, которые я предполагаю, возможно, исправлют эти ошибки, не факт конечно..
https://www.strongswan.org/blog/2020/03/25/strongswan-5.8.3-released.html
но это уже будет в новом апдейте PF
-
@mikeroygbiv
По-моему , тут дело в клиенте Windows
Обращу еще раз Ваше внимание , что в журнале событий оба обрыва связаны с неответом второй стороны
1 раз при обновлении ключей - клиент не ответил на сообщение
2 раз клиент перестал отвечать на dpd запросы ( попробуйте их отключить )Сегодня на ночь специально поставлю телефон с включенным удаленным доступом ( посмотрим , сколько продержится соединение )
-
@Konstanti Спасибо большое)!!)
попробую dpd отключить, ок.!
-
@mikeroygbiv said in Ipsec Ikev2 road warriors (mobile) - разрыв соединения через 8 часов:
по дефолту там тоже каждый час разрыв, но reneg-sec 0 решает этот вопрос
У вас, наверное, auth-nocache в конфиге клиента. Без этой директивы коннект, IMHO, не обрывается.
-
@pigbrother это если с сохраненным паролем, не разрывается? (в GUI, на винде, маке итд)
нет, эта директива не была включена. -
@mikeroygbiv Извинтите, могу и ошибаться. В свое время экспериментировал с auth-nocache, соединение рвалось каждый час с запросом логина -пароля. Помогло reneg-sec 0 на стороне сервера.
Позже auth-nocache у клиентов убрал, а reneg-sec 0 на сервере, оказывается, осталось.
Сейчас экспериментировать неуместно , многие работают через OVPN из дому.