Почему возникает ошибка ipsec,error phase1?

Question

[Андрей]

Добрый день, Друзья!

Прошу Вашей помощи, в таком вопросе: Пытаюсь сделать банальную, пережеванную 100 раз схему по подключению доп.офиса к головному офису.
Связка микротик-микротик. Головной офис статика. Доп.офис - динамический адрес.
Связываюсь с головным по l2tp. (10.10.183.1 локальный адрес туннеля головного офиса. 10.10.183.2 адрес доп.офиса)
Внутри тунеля поднял ipsec (увы, в тунельном режиме).
Когда соединение установлено, всё работает.
Но когда туннель разрывается, в логах начинают появляться вот такие ошибки:

15:07:04 l2tp,ppp,info <l2tp-TEST_LENIN_JD>: terminating...
15:07:04 l2tp,ppp,info,account TEST_LENIN_JD logged out, 737777 9633472 8828785 144970 137188
15:07:04 l2tp,ppp,info <l2tp-TEST_LENIN_JD>: disconnected
15:07:04 route,ospf,info OSPFv2 neighbor 10.10.183.2: state change from Full to Down
15:10:35 ipsec,error phase1 negotiation failed due to time up 212.12.134.77[500]<=>10.10.183.2[500] 948c48daee
d1bfbd:0000000000000000
15:11:45 ipsec,error phase1 negotiation failed due to time up 212.12.134.77[500]<=>10.10.183.2[500] 925b3f56c4
f67467:0000000000000000

Подскажите, почему они появляются?
Почему тут фигурирует внешний адрес, если он нигде в настройках ipsec не фигурирует?

Comments

[Saenara]

Если тунель упал, то адрес 10.10.183.2 скорее всего будет недоступен (или приведёт в неизвестные неожиданные дали).

[Андрей]

Saenara: Это очевидно-логично. Просто причем тут внешний? И почему на "клиенте" нет таких же сообщений?

[Saenara]

Внешний IP тут притом, что когда упал тунель, то пропал маршрут до 10.10.183.2 и пакеты отправились по default route, который у вас, естественно, через внешний интерфейс настроен.

[Андрей]

Saenara: Хм. Ну в принципе как вариант объяснения происходящего - это пока самый лучший!

А можно ли как-то избавиться от этих записей в логах?
Это моя вторая попытка победить эту проблему... первая закончилась переходом на sstp, но он не быстр...

[Saenara]

Поднимите IPSec на внешних адресах, а не в туннеле.

[Андрей]

Saenara: На другом конце динамический ip + работаете из-за NAT. Как вариант ещё попробовать набросать скрипт, который бы отключал политику, если туннель разорвался. Но почему на клиенте нет таких записей? Там же аналогично всё...

Answer 1

[PaulC]

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

Answer 2

[Алексей Русаков]

Попробуй использовать для своих целей EoIP.

Comments

[Андрей]

Алексей, в силу определённых обстоятельств, не хотелось бы "светить" удалённую точку подключения. По этому туннель не подойдёт. Клиент-сервер - это идеальный вариант для меня.

Answer 3

[Андрей]

Друзья, всем кто ищет ответ на этот вопрос, спешу поделиться вариантом избавления от этих строк в логах.

Я на тестовых девайсах, с последней прошивкой 6.38.1 и с дефолтной конфигурацией собрал схему.
L2TP сервер - клиент, поставил галочку использовать IPSEC, все политики создаются динамически, всё в таком режиме работает отлично!
При дисконнекте лог чист.

НО! Как только я создал динамическую маршрутизацию - пропало шифрование :(
SA не устанавливаются.

Может кто сталкивался с такой бедой?

Comments

[strelok_aka_vc]

Как то решился вопрос?
Схема та же. Проблема тоже. Причем схема работала несколько лет без проблем. Сейчас отвалился IPSec с записью в логах:
на сервере:
phase1 negotiation failed due to time up SERVER_WAN_IP[500]<=>CLIENT_WAN_IP[500] GUID

на клиенте:
initiate new phase 1 (Identity Protection): CLIENT_WAN_IP[500]<=>SERVER_WAN_IP[500]
L2tp Client (vpn-name): terminating... - session closed

[Андрей]

strelok_aka_vc, Если честно, то уже и не помню. Хорошо запомнил момент с прошивкой, от неё версии зависело очень многое.