Привет  
@UBNT-jaffe,  
это ещё актуальная проблема? У меня две линии от одного и того же провайдера, поэтому IP шлюза одинаковый на обоих WAN-портах. Это вопрос доработки или постоянное ограничение? Пока что, чтобы всё работало (и работает нормально), я настроил виртуалку PfSense с VLAN на WAN2, чтобы получить другой IP шлюза для второго WAN-порта на USG Pro. Без PfSense на WAN2 мой роутер просто выбирает один из WAN и направляет весь трафик через него:

show load-balance watchdogGroup wan_failover  
 eth2  
 статус: Работает  
 пинги: 142  
 ошибки: 0  
 неудачные попытки: 0/3  
 пропуски маршрута: 0  
 пинг шлюза: ping.ubnt.com – ДОСТУПЕН  

 eth3  
 статус: Работает  
 пинги: 142  
 ошибки: 0  
 неудачные попытки: 0/3  
 пропуски маршрута: 0  
 пинг шлюза: ping.ubnt.com – ДОСТУПЕН  

show load-balance status  

Группа wan_failover  
 интерфейс: eth2  
 связь: поднята  
 статус: активен  
 шлюз: (шлюз ISP)  
 таблица маршрутов: 201  
 вес: 50%  
 потоки  
     Выход WAN: 2622  
     Вход WAN: 0  
     Локальный исходящий: 4  

 интерфейс: eth3  
 связь: поднята  
 статус: активен  
 шлюз: (тот же шлюз ISP)  
 таблица маршрутов: 202  
 вес: 50%  
 потоки  
     Выход WAN: 2346  
     Вход WAN: 0  
     Локальный исходящий: 0  

Меня не раздражает использовать PfSense впереди одного из WAN, просто интересно — можно ли добавить опцию для двух отдельных WAN-подключений, которые используют один и тот же шлюз ISP? Спасибо!

Мне нравится использовать PPTP или L2TP VPN в USG как способ доступа, чтобы можно было удалённо подключаться к моим airmax-радиостанциям, так как через облачный доступ это сделать нельзя. Чтобы всё работало, у меня настроено обновление записи Dynamic DNS у моего DNS-провайдера (EasyDNS), чтобы я мог легко подключаться к удалённому USG по публичному DNS-имени, хотя у USG динамический публичный IP, выданный провайдером.  

При использовании Dual WAN — как это организовано? Dynamic DNS сработает только на WAN1 или есть возможность обновлять разные DNS-записи для каждого WAN отдельно? Без такой поддержки будет сложно подключаться по VPN к удалённой USG.  

Что касается устройств за USG, использующих VPN, это не так критично. Для site-to-site VPN я использовал его, чтобы дать клиенту с двумя филиалами доступ к контроллеру на удалённом объекте, как если бы он был локальным. OpenVPN отлично с этим справляется. Интересно, как dual WAN влияет на site-to-site VPN.  

Сейчас я не использую IPsec VPN, так что с этим проблем нет.  

Спасибо.

1. WAN1 может переключаться на WAN2 при сбое, но WAN2 не всегда переключается на WAN1. Эта проблема появилась где-то между версиями 4.4.12 и 4.4.21, но у меня ее не было на 4.4.22+2. Трафик, исходящий из USG при мультиWAN, часто теряет более 50% пакетов, потому что USG вроде как начинает посылать пакеты в WAN2 с исходным IP из WAN1 и наоборот.

Это давно исправили в версии 5.7.8:
- "Добавлено NAT для других WAN IP при выходе через WAN, что исправляет несколько проблем с мульти-WAN."
Создаются 2 правила NAT с похожим описанием на "MASQ eth0 out other WAN".

3. S2S VPN со временем ломается, если с одной или обеих сторон используется мультиWAN (вероятно, как следствие пунктов 1 и 2).
Это скорее связано с отсутствием DPD и тем, что трафик не идет постоянно. Автоматические VPN теперь включают DPD в последних версиях контроллера, а настройка DPD появится для ручных IPsec VPN в будущих версиях контроллера.

4. USG не знает, что DNS-серверы, полученные от DHCP ISP на WAN1/2, должны быть доступны только через соответствующий WAN1/2. На самом деле он считает все DNS-серверы доступными с обоих WAN, что часто, но не всегда, верно.  
dnsmasq отправляет запросы на все настроенные DNS-серверы. Если WAN2 не может достучаться до DNS-сервера, доступного только через WAN1 (и WAN1 при этом выключен), он переходит к следующему серверу из списка в /etc/resolv.conf.

5. Балансировка нагрузки — помимо множества проблем с маршрутизацией — на самом деле не балансирует нагрузку.  
На самом деле балансирует, я за последний год собрал много статистики и дампов, чтобы это доказать. Счетчики WAN_IN / WAN_OUT / LOCAL_OUT в команде "show load-balance status" точны и подтверждаются tcpdump/pcap. "Липкие" соединения отдают предпочтение одному WAN для одиночных соединений, чтобы избежать повторных передач TCP и прочего, поэтому идеального деления 50/50 не будет — одна сессия не может быть разделена между двумя разными физическими интерфейсами.

6. Проброс портов при мультиWAN будет работать ЛИБО на WAN1, ЛИБО на WAN2, но не на обоих одновременно.  
Это верно в GUI, но через config.gateway.json можно задать кастомные DNAT-правила, чтобы пробросы работали на обоих WAN одновременно. В будущем в GUI появятся более тонкие настройки SNAT/DNAT, которые решат этот вопрос.

Один из обсуждаемых вами тредов уже отмечен как решённый, а по большинству остальных @UBNT-cmb дал свои комментарии.

@firefi

Я тестировал все версии, какие только можно, в данный момент на 4.4.22 и 5.9.4. Пробовал также 4.5.1, 4.5.2 и 4.5.3 на USG. Скопирую из другой темы мой краткий отчёт по проблемам с multiwan, с которыми столкнулся:

«multiwan страдает целым набором абсурдных проблем, включая:
1. WAN1 может переключаться на WAN2, но WAN2 не всегда переключается обратно на WAN1;
2. Трафик, идущий с USG в режиме multiwan, часто теряет более 50% пакетов, потому что USG иногда начинает отправлять пакеты на WAN2 с исходным IP WAN1 и наоборот;
3. Site-to-Site VPN рано или поздно ломается, если multiwan включён хотя бы на одной из сторон (возможно, из-за пунктов 1 и 2);
4. USG не понимает, что DNS-серверы, полученные от ISP по DHCP на WAN1/2, должны быть доступны только через соответствующий WAN. На самом деле он считает, что все DNS-серверы доступны с обоих WAN интерфейсов, что часто, но не всегда, неправильно;
5. Балансировка нагрузки — помимо кучи проблем с маршрутизацией — по факту не балансирует нагрузку;
6. Проброс портов в сценарии multiwan работает ЛИБО через WAN1, ЛИБО через WAN2, но не одновременно через оба.

Все эти проблемы существуют с августа прошлого года — с тех пор как я впервые купил оборудование Unify. Насколько мне известно, ничего из этого до сих пор не исправлено, поэтому во всех моих сетях WAN2 отключён уже несколько месяцев.»

Вот несколько тем, где люди тоже пытаются разобраться с multiwan:

https://community.ui.com/questions/fb64ab59-b296-4d5a-a773-e697ffaaa1f2#comment/60915ff2-ba9d-4eaf-90d1-efd92d46e926  
https://community.ui.com/questions/acd459db-9ca7-4fb1-9dc6-3943a6cdec9a  
https://community.ui.com/questions/7c9b9d12-a749-4b2c-abd8-7e9a95a2b2e3#comment/98b2013c-022c-4381-a0ff-98a608acc097  
https://community.ui.com/questions/75d0855c-77c8-4c42-89c2-f7b20a5313d1#comment/488f1cad-4f50-4262-9f83-2b80fce7546d  
https://community.ui.com/questions/77335130-2e68-4bcb-ba7d-c03f092ac645  
https://community.ui.com/questions/c856cf65-58fe-4e61-94cb-af38ff5e85ec#comment/de72f0df-8d2a-4722-993c-d8ae7e1137a6  
https://community.ui.com/questions/9b52288a-e812-4fa3-a829-b73ae477be77#comment/8d6ffed5-440d-4d7b-94a8-e7f0f3c09547  
https://community.ui.com/questions/bcf8f2c2-c2f7-4f51-a302-a0bc2cdcd1ed#comment/2feb0a21-37ce-43d4-bd3b-6611ac89ba87  
https://community.ui.com/questions/d6da1ce9-973a-42b4-bb75-1c645be5d426#comment/7013312d-80ca-41ac-b463-ceaf9e9845ac  
https://community.ui.com/questions/e8e96e4c-fe56-48b7-9074-08172341abee#comment/06379f33-9235-4c07-86c4-4fdfe6638600  
https://community.ui.com/questions/3fd6579d-6537-4be8-96d5-60bad10bde70#comment/09fe36a9-d072-425a-a85f-4329e8536ac6

Интересно читать, как сотрудник UBNT советует вам пробовать мульти WAN с балансировкой нагрузки, учитывая, что всем известно — реализация мульти WAN на USG довольно сырая (мой опыт говорит, что она вообще сломана, но некоторые утверждают, что у них работает). Так что, если вы вдруг начнёте биться головой об стену после включения мульти WAN, помните — у многих из нас это не работает, так что, возможно, это не ваша вина.

Да, это всё ещё ограничение: у каждого WAN-интерфейса должен быть уникальный IP-адрес шлюза.