Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
Маршрутизация через IPsec-туннель – не работает., UniFi Network
 
У нас есть несколько USG-4, которые делают IPsec VPN-соединения с центральной системой. После обновления ПО контроллера Unifi до версии 5.2.9 мы не можем полностью установить IPsec-подключение — оно, похоже, застревает на исходящей маршрутизации. Я знаю, что VPN работает, потому что могу подключиться к удалённому сайту из основных подсетей и вижу всю сеть на удалённой стороне.

Однако, когда пытаюсь сходить в обратную сторону — с удалённого сайта в основные подсети — USG4, кажется, отправляет весь трафик через PPPoE-соединение вместо IPsec-туннеля. При этом, если выполнить PING/Traceroute прямо с USG4 при входе в систему, он работает, только не через локальную LAN.

Копаясь в конфигурации, вижу, что маршруты вроде бы есть:

protocols {
   static {
       interface-route 0.0.0.0/0 {
           next-hop-interface pppoe0 {
           }
       }
       interface-route 192.168.250.0/24 {
           next-hop-interface vti64 {
               distance 30
           }
       }
       interface-route 192.168.251.0/24 {
           next-hop-interface vti64 {
               distance 30
           }
       }
       table 1 {
           interface-route 0.0.0.0/0 {
               next-hop-interface pppoe0 {
               }
           }
       }
       table 2 {
           route 0.0.0.0/0 {
               next-hop 0.0.0.0 {
               }
           }
       }
   }
}

Я также проверил и сравнил конфигурационные файлы с другими рабочими удалёнными сайтами — разницы, кроме изменений подсетей между сайтами, не вижу. Пробовал полностью удалять Site-to-site сеть и заново настраивать конфиг — в любом случае трафик всё равно идёт через WAN.

IPsec VPN настроен в контроллере (так же, как и рабочие) с включённой динамической маршрутизацией. Хотел сделать так, чтобы не приходилось создавать индивидуальный .json файл для каждого сайта.

vpn {
   ipsec {
       auto-firewall-nat-exclude enable
       esp-group ESP_xx.xx.xx.xx {
           compression disable
           lifetime 3600
           mode tunnel
           pfs enable
           proposal 1 {
               encryption aes256
               hash sha1
           }
       }
       ike-group IKE_xx.xx.xx.xx {
           key-exchange ikev1
           lifetime 28800
           proposal 1 {
               dh-group 5
               encryption aes256
               hash sha1
           }
       }
       ipsec-interfaces {
           interface pppoe0
           interface eth3
       }
       nat-networks {
           allowed-network 0.0.0.0/0 {
           }
       }
       nat-traversal enable
       site-to-site {
           peer xx.xx.xx.xx {
               authentication {
                   mode pre-shared-secret
                   pre-shared-secret xxxxxxxxxxxx
               }
               connection-type initiate
               ike-group IKE_xx.xx.xx.xx
               local-address xx.xx.xx.xx
               vti {
                   bind vti64
                   esp-group ESP_xx.xx.xx.xx
               }
           }
       }
   }
}

Интерфейс vti64 показывает статус up, если выполнить команду show interfaces на USG4:

vti64        -                                 u/u  

Версия конфигурации управления:

unifi {
   mgmt {
       cfgversion fa8ec0e42a4c9e5a
   }
}

Есть идеи, куда копать и что попробовать, чтобы это наконец заработало?
 
@UBNT-cmb

Я только что обновился до версий 5.6.19 и USG PRO 4.4.8.5023700 и получил STUN-ошибку на всех устройствах, которые обновил. При тестировании IPSEC-соединения между сайтами с использованием VTI AUTO мой трафик уходит через WAN. У меня есть несколько сайтов с ручным IPSEC, и я тестировал один сайт с AUTO VTI. Изначально у меня был включён DUAL WAN, и ни одно из IPSEC-соединений не работало. Потом я отключил DUAL WAN — все ручные IPSEC-ссылки заработали, но связь через AUTO VTI всё равно отправляла трафик через WAN-интерфейсы. Я оставил свои комментарии под этим сообщением, потому что в последнем ответе утверждалось, что эта проблема решена. Хотелось бы надеяться, что в 5.6.19 не появятся проблемы, которые уже исправили в версии 5.5.x? Это известная проблема? Должна ли при работе DUAL WAN с IPSEC в последней версии правильно создаваться JSON-конфигурация? Интересно, почему мой трафик должен уходить через WAN? Я пытался добавить ручной маршрут для трафика на тестируемый сайт, как обычно, и, как всегда, любые маршруты, добавленные через GUI, вообще не влияют на работу.
 
Это исправлено, следующие версии 5.4.x и 5.5.x это включат.
 
Спасибо, похоже, на WAN2 был включён резервный выход в интернет. Но так как сейчас мы WAN2 не используем, я отключил эту функцию, и маршрутизация вроде работает правильно. Я понимаю, что скоро нужно будет настроить резервирование/балансировку нагрузки на WAN2 в нескольких местах, поэтому перед запуском внимательно посмотрю заметки к обновлениям.
 
Думаю, у тебя включен мульти-WAN? В этом случае есть баг в policy routing, из-за которого VPN-трафик вынужденно уходит по WAN, а не маршрутизируется через VPN. Сегодня я только что создал баг-тикет по этой проблеме, планирую заняться этим в ближайшее время.

Проблема в команде «set firewall modify LOAD_BALANCE», где отсутствует исключение для VPN-сетей, как это сделано для corporate_network и подобных. В качестве временного решения можно настроить правильный modify ACL через config.gateway.json.
 
У меня теперь есть ещё несколько сайтов с этой же проблемой, которые работают на версии 4.3.23.4913544. Это странно, потому что traceroute/ping с локального сетевого устройства к удалённой подсети, управляемой VPN, игнорирует VPN-маршруты и отправляет трафик через PPPoE (основное) соединение, хотя статический маршрут прописан в конфиге.

Однако, если делать traceroute/ping с самого USG4, ответы приходят как и ожидалось, корректно.

Я уже точно уверен, что это ошибка в этой версии, но никто не предложил способов проверить или на что обратить внимание.

И я не могу найти простой способ откатиться на старую прошивку. На странице загрузок нет ссылок на старые версии прошивки для USG.
 
У меня такая же проблема на одном объекте: там была настроена автоматическая прошивка, и теперь VPN не работает. Есть другой объект с прошивкой 4.3.21.4909458 — там всё работает нормально.
Страницы: 1
Читают тему (гостей: 1)