Теперь становится интересно. Я зашёл по SSH в USG-PRO-4, чтобы проверить, где именно был задан/установлен роутер (шлюз), и выяснилась странная ситуация.  

(Часть) конфига, когда в GUI показывается только один шлюз (один адрес роутера для обоих WAN-портов):  
protocols {  
 static {  
  interface-route 10.0.x.0/24 {  
   next-hop-interface vti0 {  
    distance 30  
   }  
  }  
  interface-route 192.168.x.0/24 {  
   next-hop-interface vti0 {  
    distance 30  
   }  
  }  
  route 0.0.0.0/0 {  
   next-hop 79.187.xxx.xxx {  
    distance 220  
   }  
  }  
 }  
}  

Та же (часть) конфигурации, когда в GUI оба WAN-порта имеют свои (правильные) шлюзы:  
protocols {  
 static {  
  interface-route 10.0.x.0/24 {  
   next-hop-interface vti0 {  
    distance 30  
   }  
  }  
  interface-route 192.168.x.0/24 {  
   next-hop-interface vti0 {  
    distance 30  
   }  
  }  
  route 0.0.0.0/0 {  
   next-hop 79.187.xxx.xxx {  
    distance 1  
   }  
   next-hop 195.74.xxx.xxx {  
    distance 220  
   }  
  }  
 }  
}  

К моему удивлению, у обоих WAN-портов были корректные шлюзы, поэтому я проверил, что произойдет, если отключить WAN1 (вытащил Ethernet-кабель из WAN1).  

В результате я полностью потерял интернет (до этого команда show load-balance watchdog показывала, что оба WAN-подключения могли пинговать ping.ubnt.com).  

После того как я вытащил Ethernet-кабель из WAN1, в выводе show load-balance status оба шлюза стали «unknown»...  

Подключил кабель обратно в WAN1 — и интернет снова заработал. Но шлюз WAN2 теперь был установлен по-другому — совпадал со шлюзом WAN1.  

Я в тупике. Почему вместо переключения (failover) с WAN1 на WAN2, конфигурация USG-PRO-4 меняет шлюз WAN2 на шлюз WAN1, тем самым фактически блокируя интернет?

Привет!  
В моём случае FW 4.3.37.4967221 решает проблему с шлюзом. Провиженинг больше не влияет. (Я сначала обновил контроллер до версии 5.4.14. Контроллер работает на VPS вне офиса.)  
Интернет и Site2Site VPN продолжают работать с включённым WAN2 (раньше у меня была с этим проблема, которую решил контроллер 5.4.x), переключение на резервный канал тоже работает, интернет и Site2Site VPN остаются в строю.  
USG-PRO-4 виден в контроллере после переключения на WAN2 (читал, что у некоторых это тоже вызывает проблемы).  
Однако порт-форвардинг перестаёт работать при переключении на WAN2, и это явно проблема, потому что, например, внутренний почтовый сервер становится недоступен из интернета...  
С уважением,

Ну... Я нашел этот FW в бета-теме и не хочу говорить, что всё работает идеально (потому что, скорее всего, нет), но, по крайней мере, это временно решает некоторые проблемы. Для меня это нормально — я «король» своего фреймворка и могу делать, что хочу. А вот если говорить об инфраструктуре клиента, которой управляешь удалённо, хмм... на месте клиента я бы расстроился. Поэтому я запускаю свою офисную доменную сеть, чтобы всё проверить перед массовым развертыванием, и ничего страшного, если я «пожарю» свои кластеры или пару клиентов здесь. Но честно говоря, я боюсь проводить такие эксперименты вдали от своего «тестового стенда» и никогда не разворачиваю бета-FW удалённо 😀. Удачи.

Привет! В моём случае переключение на резервный канал и балансировщик нагрузки работают как до, так и после перезагрузки USG4PRO. Это значит, что USG сохраняет шлюз после обновления прошивки до последней версии. Но с переадресацией портов всё по-прежнему плохо, и я могу сказать, что она не работает как резервное решение... Удачи!

Статические маршруты (через GUI) не подходят. Я отправил запрос в поддержку UBNT.

Отключение DPI никак не влияет на ситуацию. Проблема остаётся та же — шлюз одного WAN перезаписывает шлюз другого WAN. (Именно это видно в графическом интерфейсе. Через командную строку видно, что в 'protocols static route 0.0.0.0/0' определён только один шлюз [next-hop], вместо двух.) Последняя попытка — настроить статические маршруты через GUI (Настройки > Маршрутизация и брандмауэр > Статические маршруты), после чего я отправлю запрос в поддержку. Самая свежая стабильная версия контроллера — 5.4.12, у меня установлена 5.4.11, но я не вижу никаких исправлений или изменений между этими версиями, которые могли бы решить проблему с шлюзами.

От команды Ubiquiti никакого ответа так и не последовало.

@wjn

?

Спасибо, @wjn, что дал немного больше контекста. Рад видеть, что я тут не один.