Тоже сталкиваюсь с проблемами при подключении к контроллеру через облачный доступ, зависает на sdp, при этом мой контроллер запущен как служба. Насколько я знаю, когда контроллер работает как служба, нужно обязательно отключать брандмауэр Windows, иначе контроллер не увидит точки доступа. Попытаюсь настроить брандмауэр так, чтобы он оставлял открытым порт 8443, потому что как-то тревожно иметь Windows-машину, которая постоянно работает без защиты брандмауэра 😳

Я обновил 64-битную версию Java, но проблемы всё равно оставались. Потом заметил, что у меня стоит обновление 32-битной версии. Когда я его удалил, проблема исчезла.

Вот как я решил эту проблему и что написал в поддержку Unifi (кстати, насколько я понял, менять права доступа на портах не нужно):

Итак, вот решение проблемы, над которой мы потратили несколько часов: Невозможность подключиться к контроллеру Unifi, запущенному на Windows 10, с WAN (облачной) стороны сети, используя правильные учетные данные.

1. После вашего согласия я удалил и заново установил контроллер на машине с Windows 10. При этом после запуска он больше не работал как служба Windows, которую я настроил по одной из ваших статей базы знаний о том, как автоматически запускать контроллер.

2. Однако, когда я попытался запустить контроллер как приложение, изначально он не запустился. Когда я остановил и снова включил его, появилось окно доступа java — судя по всему, от Windows 10 — с вопросом, разрешить ли java взаимодействовать с приложениями в сетях PRIVATE и PUBLIC. По умолчанию стояла галочка только на PRIVATE. Поняв, что контроллер использует java для связи, и прочитав, что у многих была похожая проблема, которая пропадала после переустановки java, я также отметил галочку для PUBLIC сетей. После этого запустил контроллер как приложение на Windows 10 и с компьютера на стороне WAN роутера проверил доступ — сразу получилось! Я смог подключиться к сети через SDP-запрос. Также отмечу, что я ставил x64-версию java, согласно заметке в релизе контроллера 5.07:

Другие заметки: Пользователям Windows необходимо иметь установленную x64 Java, так как мы поддерживаем только 64-битную библиотеку webRTC. Скачайте подходящую версию (64-битный офлайн-инсталлятор для Windows) здесь.

3. Так как я читал, что у многих с выпуском версии 5.07 такая же проблема возникает при запуске контроллера как службы Windows, я затем остановил контроллер как приложение, запустил как службу и снова попытался войти с того же компьютера на стороне WAN. На этот раз SDP-запрос снова таймаутился, как и при первом устранении неполадок. Чтобы проверить, я остановил службу и запустил контроллер как приложение — снова с WAN-стороны удалось подключиться и работать.

После этого я нашел такую запись в релизе контроллера 4.8:

Было замечено, что функция Cloud Access не работает на Windows, если контроллер запущен как служба. Это подтверждено и будет исправлено.

Очевидно, что в релизе 5.07 этого не исправили и про проблему не написали. Поэтому, я считаю, что после ваших собственных тестов целесообразно было бы добавить статью об этой проблеме в раздел поддержки Unifi. Далее, если инженеры смогут разобраться, почему запуск контроллера как службы приводит к сбоям, в отличие от запуска как приложения — и исправить это — будем очень благодарны.

В итоге пока рекомендуемое решение — запускать контроллер как приложение при старте Windows. Например, вот как можно сделать:

https://www.google.com/search?sourceid=chrome-psyapi2&ion=1&espv=2&ie=UTF-8&q=how%20to%20start%20application%20on%20startup%20windows%20­10&oq=how%20to%20start%20application%20on%20start%20up%20&aqs=chrome.1.69i57j0l5.18268j0j1

У меня тоже такая проблема, но с версией 5.0.7 на Windows Server 2012 R2. Раньше всё работало нормально, а потом вдруг перестало. Всегда зависает на этапе Requesting SDP offer.