Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
Как включить IPsec passthrough на USG 3P?, UniFi Network
 
Привет! Только что установил блестящий новый USG 3P дома и хотел бы узнать, может кто-нибудь подскажет, как включить IPsec VPN passthrough? Раньше у меня был Virgin Media SuperHub, и там просто была галочка для включения этой функции, что позволяло мне использовать мой программный VPN-клиент для подключения к офису. Понимаю, что здесь возможностей гораздо больше, но не подскажете, куда копать? Не боюсь покопаться в CLI через SSH, если через GUI это сделать нельзя. Спасибо!
 
@UBNT-jaffe

Потрясающе. Ваше предложение «решило» мою проблему, хоть и временно — теперь я могу справляться с ситуацией. Спасибо! После перезапуска службы VPN я смог подключиться к VPN-серверу в офисе (работающему на ER-X) с моих клиентов Windows 7 и Windows 10 напрямую через домашнюю локальную сеть и Wi-Fi. Есть ли планы обновления модуля ipsec от strongSwan в USG/ER в ближайшем будущем?

Решил поделиться выводом команды для других участников с такой же проблемой:

ubnt@edgerouter:/usr/sbin$ sudo ipsec statusall  
Статус демона IKE charon (strongSwan 5.2.2, Linux 3.10.14-UBNT, mips):  
uptime: 16 дней, с 05 мар 07:23:43 2018  
malloc: sbrk 376832, mmap 0, использовано 269176, свободно 107656  
рабочих потоков: 11 из 16 свободны, 5/0/0/0 заняты, очередь задач: 0/0/0/0, запланировано: 0  
загруженные плагины: charon ldap sqlite pkcs11 aes des sha1 sha2 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs8 pem openssl agent xcbc cmac ctr ccm gcm curl attr kernel-netlink resolve socket-default stroke vici updown eap-identity eap-md5 eap-mschapv2 eap-radius eap-tls xauth-generic xauth-eap addrblock  
IP-адреса для прослушивания:  
local.lan.ipv4.address  
wan.ipv4.address  
local.vpn.pool.address  
Подключения:  
remote-access: wan.ipv4.address...%any IKEv1, dpddelay=15s  
remote-access: локально: [wan.ipv4.address], используется аутентификация по предварительно разделённому ключу
remote-access: удаленно: используется аутентификация по предварительно разделённому ключу  
remote-access: child: dynamic[udp/l2f] === dynamic[udp] TRANSPORT, dpdaction=clear
Сессии безопасности (3 активных, 0 подключающихся):  
remote-access[63]: УСТАНОВЛЕНО 3 часа назад, wan.ipv4.address[wan.ipv4.address]...remote.vpn.client.wan.ipv4.address[remote.vpn.client.lan.address]
remote-access[63]: IKEv1 SPIs: c392e56aa3df2bf2_i df0879fcf390f13d_r*, повторное ключевание отключено
remote-access[63]: IKE предложение: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/ECP_384
remote-access{42}: УСТАНОВЛЕНО, TRANSPORT, ESP в UDP SPIs: c1d210f1_i 1869e194_o  
remote-access{42}: AES_CBC_128/HMAC_SHA1_96, 1588423 байт входящих (9990 пакетов, 278 секунд назад), 18514926 байт исходящих (15874 пакета, 12797 секунд назад), повторное ключевание отключено  
remote-access{42}: wan.ipv4.address/32[udp/l2f] === remote.vpn.client.wan.ipv4.address/32[udp/l2f]
remote-access[15]: УСТАНОВЛЕНО 7 дней назад, wan.ipv4.address[wan.ipv4.address]...remote.vpn.client.wan.ipv4.address[[remote.vpn.client.lan.address]
remote-access[15]: IKEv1 SPIs: b25d063e83edc979_i 0e2d2d4c08e1567a_r*, повторное ключевание отключено
remote-access[15]: IKE предложение: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/ECP_384
remote-access{2}: ПЕРЕКЛЮЧЕНИЕ КЛЮЧЕЙ, TRANSPORT, истекает через 16 дней  
remote-access{2}: wan.ipv4.address/32[udp/l2f] === remote.vpn.client.wan.ipv4.address/32[udp/l2f]
remote-access{2}: УСТАНОВЛЕНО, TRANSPORT, ESP в UDP SPIs: c132fe2a_i fc60cd70_o  
remote-access{2}: AES_CBC_128/HMAC_SHA1_96, 594785 байт входящих (3019 пакетов, 40303 секунды назад), 1877864 байт исходящих (2143 пакета, 685702 секунды назад), повторное ключевание отключено  
remote-access{2}: wan.ipv4.address/32[udp/l2f] === remote.vpn.client.wan.ipv4.address/32[udp/l2f]
remote-access{2}: УСТАНОВЛЕНО, TRANSPORT, ESP в UDP SPIs: c90e1462_i 6a38e4db_o  
remote-access{2}: AES_CBC_128/HMAC_SHA1_96, 1062101 байт входящих (5590 пакетов, 40303 секунды назад), 6758737 байт исходящих (6307 пакетов, 685702 секунды назад), повторное ключевание отключено  
remote-access{2}: wan.ipv4.address/32[udp/l2f] === remote.vpn.client.wan.ipv4.address/32[udp/l2f]
remote-access[8]: УСТАНОВЛЕНО 10 дней назад, wan.ipv4.address[wan.ipv4.address...remote.vpn.client.wan.ipv4.address[[remote.vpn.client.lan.address]
remote-access[8]: IKEv1 SPIs: f453a96fb716025f_i f7bb84cd0a747cd2_r*, повторное ключевание отключено
remote-access[8]: IKE предложение: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/ECP_384
remote-access{1}: УСТАНОВЛЕНО, TRANSPORT, ESP в UDP SPIs: c82ee76e_i b4b8e708_o  
remote-access{1}: AES_CBC_128/HMAC_SHA1_96, 149798901 байт входящих (157937 пакетов, 896129 секунд назад), 33400731 байт исходящих (109797 пакетов, 896129 секунд назад), повторное ключевание отключено  
remote-access{1}: wan.ipv4.address/32[udp/l2f] === remote.vpn.client.wan.ipv4.address/32[udp/l2f]

Я пару раз переподключался после перезапуска VPN-сервиса — при отключении VPN-клиента подключения не зависали.
 
Сообщение «unable to install policy» в логах swanctl, похоже, и есть корень проблемы. Я уже сталкивался с похожим у @UBNT-cmb. Если посмотреть на «sudo ipsec statusall», там, вероятно, будет показан установленный туннель удаленного доступа, даже если вы отключились. По крайней мере, в той проблеме, которую мы решали раньше, что-то застревало на этом уровне. Функция модуля connmark, добавленная в strongswan 5.4.0, может предотвратить подобные ситуации (текущая версия в USG/ER, насколько я знаю, 5.2.2). Если выполнить ручную команду «restart vpn», а потом попробовать подключиться с ваших Windows-машин сначала через Wi-Fi — подключится успешно?
 
Ха, рад это слышать. Да, добавление нескольких подсетей к одному адаптеру в Windows может по-разному сказываться, я обычно просто меняю IP полностью или использую другой (второй) адаптер, чтобы не забыть об этом.
 
Ха, смешно получилось. Раньше я добавил на свой ноутбук вторую подсеть, чтобы подключиться к устройству в своей сети, которое было на схеме 192.168.1.x, чтобы потом переключить его на схему 192.168.12.x. И так её и оставил. По какой-то причине ноутбук стал использовать именно эту подсеть как ответ при VPN-соединении. Как только я удалил 192.168.1.x из настроек, всё заработало. Думаю, это какая-то особенность Windows? Спасибо @UBNT-jaffe за то, что направил меня в правильное русло!

17:55:09.565093 IP 192.168.1.2.500 > 76.10.202.122.500: isakmp: phase 1 I ident  
17:56:55.146743 IP 65.60.168.164.500 > 76.10.202.122.500: isakmp: phase 1 I ident  
17:56:55.158065 IP 76.10.202.122.500 > 65.60.168.164.500: isakmp: phase 1 R ident
 
Также хочу отметить, что я не вносил никаких изменений в USG, кроме двух обновлений прошивки. Я использую свой домашний компьютер для подключения к рабочему VPN. Раньше это работало, когда у меня был роутер Asus. Спасибо. Кларк
 
Я не эксперт по SSH. Вот что получается, когда я запускаю эту команду. Извини.  
ubnt@192.168.12.1's password:  
Linux USG3P 3.10.20-UBNT #1 SMP Wed Apr 19 20:11:32 CDT 2017 mips64  
Welcome to EdgeOS  
ubnt@USG3P:~$  
ubnt@USG3P:~$ sudo tcpdump -npi <wan_interface> port 500 -v  
bash: wan_interface: Нет такого файла или каталога  
ubnt@USG3P:~$
 
@Clark_Caldwell

Ты сказал, что раньше всё работало, что-то заметное менялось? Можешь подключиться по SSH к USG и ввести:
sudo tcpdump -npi <wan_interface> port 500 or port 4500
а потом
sudo tcpdump -npi <lan_interface> port 500 or port 4500
После этого попробуй подключиться к VPN с внешнего клиента и вставь результаты сюда в виде кода. Спасибо!
 
@UBNT-jaffe свяжется и узнает, что там происходит.
 
У меня такая же проблема после перехода с беспроводного роутера Asus RT66U на USG 3P. Раньше всё работало, а теперь нет. Контроллер версии 5.4.11, прошивка USG 4.3.41.4975503. В журнале событий Windows 10 при сбое возвращается код ошибки 789, что означает, что фаервол блокирует VPN-трафик, например UDP-порты 500 (IKE) и 4500 (IPsec NAT-T). VPN-сервис от Meraki на MX60. Спасибо.
Страницы: 1
Читают тему (гостей: 1)