Просто чтобы вы знали, причина, по которой я отключил vti, в том, что это был единственный способ заставить VPN-подключения удалённых пользователей видеть ресурсы Azure. Именно поэтому я добавил маршрут туннеля 192.168.2.0/24. Если есть более лучший способ сделать это, я готов его изменить.

Я только что проверил, и всё сработало так, как ты сказал... когда я разместил сообщение в том форуме, на который дал ссылку, я не учёл адрес самого USG. Но это не логично и *не должно* работать именно так. В будущем мы планируем добавить правила фаервола для VPN, где будет легко фильтровать входящий VPN-трафик, направленный на USG или устройства за ним в локальной сети.

Это задокументировано в моём сообщении на форуме: https://community.ui.com/questions/6a7f4d46-cd30-4aac-bf5d-cbac88408b7f. Причина, почему этого нет в базе знаний — ваш VPN настроен очень специфично, и это касается, наверное, меньше 1% пользователей. Всё дело в том, что нужно вручную отключить «auto-firewall-nat-exclude», а также использовать VPN без включённого VTI. Но судя по вашему json-файлу, вы не отключали автофаервол вручную, а значит, он всё равно создаёт следующие правила в цепочке iptables:

Chain UBNT_VPN_IPSEC_FW_HOOK (1 ссылка)  
pkts bytes target prot opt in out source destination  
3164 181K ACCEPT udp * * 0.0.0.0/0 0.0.0.0/0 multiport dports 500,4500  
195 32392 ACCEPT esp * * 0.0.0.0/0 0.0.0.0/0  

Второе правило (esp) именно разрешает трафик с удалённого VPN, направленный на адрес LAN-интерфейса USG и его подсеть. Поэтому совершенно не понятно, как добавление правила на WAN_LOCAL реально решило проблему. Можете удалить это правило и попробовать снова подключиться по SSH к LAN-адресу USG?

Ты не увидишь ничего на tcpdump USG, потому что без VTI нет интерфейса, с которого можно захватить трафик. Пакеты будут отображаться в tcpdump, если тестировать клиентов за USG, потому что USG должен переслать пакет через LAN-интерфейс, и ответ тоже приходит через LAN... но если адрес назначения — сам USG, то пакет может «войти» и «выйти» только через интерфейс VTI или, в твоём случае, через WAN-интерфейс... но на WAN-интерфейсе ты не можешь захватить внутренний (нешифрованный) трафик туннеля. Вот почему VTI так полезен. Можешь показать захват пакетов Azure? TCP-повторы передач — обычное дело при асимметричной маршрутизации, интересно, не совпадает ли маршрут к USG и тот, по которому USG отправляет ответные пакеты.

Привет, Brandon! Спасибо огромное! Когда я запускаю команду "show interfaces", у меня отображаются только eth0, eth1, eth2, eth3 и lo. Если кто-то подключается по удалённому VPN, я вижу интерфейс l2tp. Но интерфейс site-to-site я не вижу, и, думаю, это из-за того, что у меня отключена динамическая маршрутизация, потому что это был единственный способ позволить как моим пользователям LAN 192.168.1.x, так и удалённым VPN-пользователям 192.168.2.x получать доступ к ресурсам. Вместо динамической маршрутизации у меня в расширенной конфигурации JSON прописано следующее:

"vpn":{
 "ipsec":{
   "site-to-site":{
     "peer":{
       "104.215.123.192":{
         "tunnel":{
           "10":{
             "allow-nat-networks":"disable",
             "allow-public-networks":"disable",
             "esp-group":"ESP_104.215.123.192",
             "local":{
               "prefix":"192.168.2.0/24"
             },
             "remote":{
               "prefix":"10.1.0.0/24"
             }
           }
         }
       }
     }
   }
 }
}

Так что, думаю, теперь мне стоит пойти по пути wireshark и попытаться понять, что происходит? Как я уже говорил, из Azure у меня есть доступ ко всем остальным локальным ресурсам, только вот к USG — нет. На данном этапе это скорее «хочу понять, почему так», чем реальная большая проблема 😀