Входящий ESP не получен сетевым виртуальным устройством Azure

У нас есть виртуальное устройство сети FortiGate-VM в Azure с VPN-подключением IPSec типа «сеть-сеть» к Cisco ISR 4400 бизнес-партнера. Это подключение работало безупречно около года, но около двух недель назад у нас внезапно возникло проблемы, когда наш партнер отправляет трафик ESP, а наш FortiGate не получает ни одного из пакетов ESP.

Эта проблема возникает в периоды низкого трафика, когда наш партнер не отправляет зашифрованные данные в течение нескольких минут. При следующей отправке зашифрованного трафика они могут убедиться, что отправляют исходящие пакеты ESP, но наш FortiGate не получает пакеты ESP. Однако, когда мы инициируем исходящий пинг (но это может быть любой трафик) к узлу за их VPN, мы внезапно начинаем получать от них пакеты ESP. Во время всего этого обе стороны могут проверить, работают ли туннели. Со своей стороны, мы фактически отправляем сообщения R-U-THERE и получаем R-U-THERE подтверждения, пока мы сталкиваемся с этой проблемой.

Вот пример вывода отладки сниффера FortiGate, когда я запускаю исходящий пинг после того, как не получил пакеты ESP от нашего партнера. x.x.x.x это наш партнер IPSec и y.y.y.y их одноранговый IPSec. Запущенная команда отладки FortiGate: diag sniffer packet any ' host y.y.y.y ' 4 0 l.

2020-05-05 23:18:24.569976 port1 out x.x.x.x.500 -> y.y.y.y.500: udp 92
2020-05-05 23:18:24.639714 port1 in y.y.y.y.500 -> x.x.x.x.500: udp 92
2020-05-05 23:18:40.227469 port1 in y.y.y.y.500 -> x.x.x.x.500: udp 92
2020-05-05 23:18:40.234853 port1 out x.x.x.x.500 -> y.y.y.y.500: udp 92
2020-05-05 23:18:41.407030 port1 out x.x.x.x -> y.y.y.y: ESP(spi=0x15c8fe2d,seq=0x1cd60)
2020-05-05 23:18:41.477256 port1 in y.y.y.y -> x.x.x.x: ESP(spi=0x8a68bdf0,seq=0x1e926)
2020-05-05 23:18:42.418246 port1 out x.x.x.x -> y.y.y.y: ESP(spi=0x15c8fe2d,seq=0x1cd61)
2020-05-05 23:18:42.488455 port1 in y.y.y.y -> x.x.x.x: ESP(spi=0x8a68bdf0,seq=0x1e927)

Обычно мы получаем постоянный поток трафика от нашего партнера по VPN, но бывают случаи, когда ночью он замедляется. Что странно, это как если бы что-то блокировало новый входящий трафик ESP после периода простоя. Мои знания IPSec ограничены, но насколько я понимаю, трафик ESP не основан на сеансах, поэтому этого не могло произойти. Общедоступные IP-адреса Azure имеют значение тайм-аута простоя, но оно должно применяться только к трафику TCP, а не к ESP (протокол IP 50).

У кого-нибудь есть объяснение, почему входящие пакеты ESP будут отбрасываться после периода бездействия на виртуальном устройстве сети Azure? Или любые другие идеи по устранению неполадок, которые могут помочь мне определить, что происходит?

Вот еще несколько замечаний.

• Мы подтвердили, что время жизни в фазе 2 одинаково для обеих сторон.
• Обе фазы 1 и 2 остаются активными, как сообщили оба партнера.
• На нашей стороне отключен обход NAT. (Я постараюсь включить обход NAT в ближайшее время в качестве теста, чтобы увидеть, поможет ли это, и доложу об этом.)
• PFS отключен с обеих сторон.
• Группа безопасности сети Azure для общедоступного интерфейса разрешает весь трафик с IP-адреса однорангового партнера.
• Наш FortiGate имеет два виртуальных сетевых адаптера. Первый имеет общедоступный IP-адрес, непосредственно связанный с общедоступной сетевой картой.
• На нашей стороне никакие балансировщики нагрузки не используются.
• Мы не касались настроек VPN в течение года, и наш партнер говорит, что они тоже не трогали (и я не понимаю, почему они это сделали).
• В качестве обходного пути у меня есть непрерывный пинг от узла за нашей VPN до тестового узла за их VPN, что предотвращает падение трафика ESP.
• Чаще всего это происходит около 23:00, но может случиться и ранним утром. Оба времени приходятся на более легкие периоды трафика через VPN, поэтому я считаю, что корреляция связана с бездействием, а не с временем суток.
• Мы используем виртуальное устройство вместо VPN-шлюза Azure, потому что конечная точка приложения, стоящая за нашей VPN, должна быть общедоступным IP-адресом, как того требует наш партнер, а это невозможно сделать с помощью VPN-шлюза Azure. Я считаю, что это выходит за рамки данной проблемы, но при необходимости буду рад обсудить это.