На ЮГ несколько внешних адресов и он при любом переподключении радномно выбирает любой из них.
Если необходимо устанавливать VPN соединение с виртуального кластерного адреса (VIP), вы можете создать правило NAT со следующими параметрами - SNAT IP: выбрать VIP адрес - зона источника: любая - зона назначения: зона провайдера или та за которой находится VPN peer - адрес назначения: адрес соседнего VPN peer
Можно ли в качестве своей и удаленной сети указать 0.0.0.0/0? Есть подсети, доступ к которым возможен только через туннель, но нет возможности объединить их простым уменьшением префикса.
Нет, тут необходимо явно объявлять локальные сети.
Как настроить несколько вторых фаз для одного L2L соединения?
Для каждой локальной сети создавать отдельное клиентское правило.
Как реализовать вариант, когда UG имеет "белый" адрес, а другое оборудование находится за NAT-ом?
Пусть IPsec клиентом будет оборудование без реального адреса - играйтесь с NAT-T на оборудовании с другой стороны UG. А вообще хорошей практикой построение IPsec является использование реальных ip адресов.
В инструкции приведены самые частые случаи в нашей практике. Лучшим решением будет привлечь инженеров от производителя. Мы со своей стороны в вашем случае можем дать общие рекомендации.
PFS второй фазе необходимо отключить (см. опцию "Enable perfect forward secrecy (PFS)", и чтобы остальные параметры подключения совпадали на обоих концах туннеля.
Локальные сети не проблема, согласуете со второй стороной и прописываете необходимое количество. Со стороны EG прописывайте их в поле "Peer Subnets" через запятую, со стороны UG каждая такая сеть отдельным клиентским правилом.
По п.1 и п.4 больше похоже на баг. Запрос в ТП, возможно, будет какой-то апдейт от вендора.
Попробуйте пройтись еще раз по всем шагам настройки. Вероятнее всего, что-то упущено. Если CP дропает пакет и говорит про клир текст, то пакет приходит не зашифрованный, т.е. UG его не шифрует, а должен. Все к тому, что где-то у вас есть ошибка в параметрах.
Почему Fortigate не добавили в тесты? Интересно было бы посмотреть на его результат по сравнению с текущими игроками на нашем рынке.
Интересно! Ждем продолжения))
Если необходимо устанавливать VPN соединение с виртуального кластерного адреса (VIP), вы можете создать правило NAT со следующими параметрами
- SNAT IP: выбрать VIP адрес
- зона источника: любая
- зона назначения: зона провайдера или та за которой находится VPN peer
- адрес назначения: адрес соседнего VPN peer
Нет, тут необходимо явно объявлять локальные сети.
Для каждой локальной сети создавать отдельное клиентское правило.
Пусть IPsec клиентом будет оборудование без реального адреса - играйтесь с NAT-T на оборудовании с другой стороны UG. А вообще хорошей практикой построение IPsec является использование реальных ip адресов.
В инструкции приведены самые частые случаи в нашей практике.
Лучшим решением будет привлечь инженеров от производителя.
Мы со своей стороны в вашем случае можем дать общие рекомендации.
PFS второй фазе необходимо отключить (см. опцию "Enable perfect forward secrecy (PFS)", и чтобы остальные параметры подключения совпадали на обоих концах туннеля.
Локальные сети не проблема, согласуете со второй стороной и прописываете необходимое количество. Со стороны EG прописывайте их в поле "Peer Subnets" через запятую, со стороны UG каждая такая сеть отдельным клиентским правилом.
По п.1 и п.4 больше похоже на баг. Запрос в ТП, возможно, будет какой-то апдейт от вендора.
Попробуйте пройтись еще раз по всем шагам настройки. Вероятнее всего, что-то упущено. Если CP дропает пакет и говорит про клир текст, то пакет приходит не зашифрованный, т.е. UG его не шифрует, а должен. Все к тому, что где-то у вас есть ошибка в параметрах.
Коллеги из UserGate говорят, что загрузка по ядрам равномерно распределяется. А посмотреть загрузку по конкретному ядру - да, такой возможности нет.