↩️ Назад

Категории

Как я подключал UDM Pro к pfSense через WireGuard

19.02.2026 | из категории: Сети LAN

Обьединение офисов с роутерами UDM Pro и Keenetic к pfSense

📡 Что мы строили

Связать три сети через VPN:

⚠️ Важно: В статье про UDM Pro, но на самом деле устройство — UDM (Dream Machine), не Pro. Но суть та же.

🔧 Основные действующие лица

Устройство Роль IP в VPN Локальная сеть
pfSense (центр) Сервер WireGuard 172.30.99.1 10.88.33.0/24
UDM (Жуково) Клиент WireGuard 172.30.99.140 192.165.40.0/24
Keenetic (Строгино) Клиент WireGuard за pfSense 172.30.99.11 192.165.10.0/24

🗺️ Маршрут наших мучений

Шаг 1. Базовые настройки WireGuard на UDM

На UDM создали WireGuard-клиента:

💡 Важно: В интерфейсе UDM нет поля AllowedIPs — оно заменяется "Связанными политиками" (политики маршрутизации). Но для работы достаточно, чтобы на pfSense в пире были прописаны нужные сети.

Шаг 2. Настройка AllowedIPs на pfSense

В Peer для UDM прописываем:

AllowedIPs = 172.30.99.140/32, 192.165.40.0/24, 10.88.33.0/24

В Peer для Keenetic (Строгино):

AllowedIPs = 172.30.99.11/32, 192.165.10.0/24, 10.88.33.0/24, 192.165.40.0/24

Шаг 3. Правила файрвола на UDM (главная боль 🔥)

Создали несколько правил, но работает только одно:

Правило: Allow VPN to LAN all Action: Разрешить Protocol: Все Source Zone: Внешняя зона (где интерфейс wireguard) Source IP: Любое (или 172.30.99.0/24) Destination Zone: Внутренние (marshalajukova) Destination Network: 192.165.40.0/24 Priority: 8000
⚠️ Критический момент: Правила с конкретным IP-источником (например, 172.30.99.1) могут НЕ РАБОТАТЬ! UDM не всегда сопоставляет IP с зоной правильно. Используйте подсети (172.30.99.0/24) вместо отдельных IP.

Шаг 4. Статический маршрут на UDM

Добавили маршрут до офиса Строгино:

Сеть: 192.165.10.0/24 Шлюз: 172.30.99.1 (pfSense) Интерфейс: wireguardtopfsense

Шаг 5. Проблема с ICMP Redirect от pfSense

При пинге с Keenetic (172.30.99.11) на устройство в Жуково (192.165.40.213) получали:

"Redirect message" ICMP packet received from 172.30.99.1 (type = 5, code = 1).

Причина: pfSense говорил Keenetic'у «шпи пакеты напрямую на UDM (172.30.99.140)», но Keenetic не мог пинговать UDM, потому что на UDM не было разрешения для ICMP от 172.30.99.11.

Шаг 6. Решение проблемы Redirect

Вариант А (рабочий): Добавить на UDM правило, разрешающее ICMP от всей подсети 172.30.99.0/24:

Правило: Allow ICMP from VPN Action: Разрешить Protocol: ICMP Source Zone: Внешняя зона Source Network: 172.30.99.0/24 # !!! именно подсеть, а не отдельный IP Destination Zone: Внутренние Destination Network: 192.165.40.0/24 Priority: 8000

Вариант Б (альтернативный): Отключить ICMP Redirect на pfSense:

System → Advanced → Network Optimizer → Disable ICMP Redirect # или через консоль: sysctl net.inet.ip.redirect=0 echo "net.inet.ip.redirect=0" >> /etc/sysctl.conf
💡 Инсайт: В нашем случае помогло просто расширение правила с 172.30.99.1 до 172.30.99.0/24. После этого Keenetic смог пинговать UDM, и Redirect перестал мешать.

Шаг 7. Неожиданный финал

После всех плясок с бубном оказалось, что правило ykhyjk (ICMP от 172.30.99.1) вообще не нужно — его отключение ничего не сломало, а пинги продолжали работать.

⚡ Вывод: На UDM лучше не создавать лишних правил. Часто достаточно одного широкого правила между зонами, а остальное закрывается системными правилами (Allow Return Traffic и т.д.).

✅ Финальная конфигурация

На pfSense (сервер, центр):

На UDM (Жуково):

На Keenetic (Строгино):

🎯 Результат

✅ UDM пингует офис Строгино (192.165.10.1)

✅ pfSense пингует UDM (172.30.99.140) и устройство в Жуково (192.165.40.213)

✅ Keenetic (Строгино) пингует устройство в Жуково (192.165.40.213)

✅ Устройство в Жуково пингует Keenetic (192.165.10.1)

✅ ICMP Redirect больше не мешает

💡 Главные выводы (из реального опыта)

  1. AllowedIPs должны быть прописаны на всех пирах и включать все сети с обеих сторон. Иначе пакеты не будут уходить в туннель.
  2. На UDM правила с конкретным IP-источником могут не работать. Всегда используйте подсети (/24), даже если источник один.
  3. ICMP Redirect от pfSense — не ошибка, а подсказка. Он появляется, когда есть более прямой путь. Решается либо настройкой этого пути, либо отключением Redirect.
  4. Не создавайте лишних правил. Иногда одно широкое правило между зонами решает все проблемы.
  5. Проверяйте пинг от каждого узла до каждого. Это быстро локализует проблему.
  6. На Keenetic в AllowedIPs обязательно добавлять 172.30.99.0/24, иначе он не сможет общаться с другими пирами в VPN-сети.

🔍 Полезные команды для проверки

# На UDM (SSH) wg show ping 192.165.10.1 ping 10.88.33.1 ip route show | grep -E "192.165.10|10.88.33" # На pfSense (Diagnostics → Ping) ping 172.30.99.140 ping 192.165.40.213 ping 192.165.10.1 # На Keenetic (через CLI или веб-интерфейс) ping 172.30.99.140 ping 192.165.40.213 # Проверка логов на UDM tcpdump -i wgclt1 -n icmp iptables -L -n -v | grep -E "192.165.40|172.30.99"

📚 Словарик терминов

Термин Значение
ICMP Redirect Сообщение от роутера: «есть более прямой путь, шли туда»
AllowedIPs В WireGuard — список сетей, которые доступны через этого пира
UBIOS Система файрвола на UDM (цепочки iptables с префиксом UBIOS_)
Зоны (Firewall Zones) Группировка интерфейсов на UDM для правил файрвола
✏️ Послесловие: Эта статья родилась из реального 3-часового сражения с маршрутами, файрволами и ICMP Redirect. Надеемся, она сэкономит вам несколько часов жизни и пару нервных клеток. 🚀
Теги: #keenetic #pfsense #udm_pro #vpn #wireguard
👍 Оцените статью
Всего голосов: 0


Категории:

Категории

Комментарии

Пока нет комментариев. Будьте первым!

Оставить комментарий

← Назад к списку

Обратная связь

Посетителей сегодня: 0
о блоге | карта блога | 📡 Подписаться на RSS

© Digital Specialist | Не являемся сотрудниками Google, Яндекса и NASA