pfSense как VPN-шлюз: настройка WireGuard

MAATRIX

Если в офисе или дома уже стоит pfSense, вопрос "как раздать VPN на всю сеть" решается не костылями на роутере с урезанной прошивкой, а штатными средствами самого файрвола — он и так стоит на границе сети и видит весь трафик. pfSense умеет быть WireGuard-шлюзом в обеих ролях: клиентом, который заворачивает весь исходящий трафик в туннель до арендованного VPS, и сервером, который принимает удалённых сотрудников или второй офис. Разберём обе схемы по шагам — от включения WireGuard в GUI до маршрутизации, firewall-правил и типичных ошибок, из-за которых handshake есть, а трафика нет.

Зачем именно pfSense, а не бытовой роутер

Разница между "VPN на роутере" и "VPN на pfSense" не в протоколе — WireGuard тот же самый, а в том, что pfSense даёт полноценный firewall с множественными интерфейсами, gateway groups для автоматического failover и policy-based routing на уровне отдельных правил, а не общего тумблера. Для дома с одним провайдером это может быть избыточно, а для офиса, где нужно точечно решать, какой VLAN или подсеть идёт через туннель, а какая — напрямую в интернет, это ровно тот инструмент, которого не хватает большинству прошивок консьюмерских роутеров.

Начиная с pfSense CE 2.7.0 WireGuard встроен в систему как штатный тип VPN — отдельный пакет ставить не нужно, поддержка идёт из коробки через VPN → WireGuard. Если у вас более старая ветка (2.6.x и ранее), WireGuard там всё ещё доступен как отдельный пакет из Package Manager, но логика настройки почти идентична описанной ниже.

У pfSense в этой роли две принципиально разных задачи, и важно сразу понимать, какая нужна вам:

Обе роли можно совмещать на одном pfSense — например, тунель к VPS для исходящего трафика и одновременно приём удалённых сотрудников, — но конфигурировать их стоит раздельными интерфейсами, чтобы не запутаться в маршрутах.

Установка и первичная настройка WireGuard

Заходим в VPN → WireGuard → Settings, ставим галку Enable WireGuard и сохраняем. Дальше идём на вкладку Tunnels и создаём первый туннель:

• Description — понятное имя, например to-vps или road-warriors.
• Listen Port — порт, на котором pfSense будет слушать входящие пакеты (нужен полноценно только для серверной роли, но задать стоит всегда, например 51820).
• Interface Keys — жмём Generate, pfSense создаёт приватный и публичный ключ пары. Публичный ключ понадобится передать на другую сторону туннеля.

После сохранения туннеля появляется его системное имя вида tun_wg0 — именно его вы дальше будете назначать как сетевой интерфейс pfSense.

pfSense как клиент: туннель всей сети до VPS

Эта схема нужна, когда весь трафик офиса или дома должен выходить в интернет через арендованный сервер — например, чтобы получить стабильный IP в нужной юрисдикции или доступ к сервисам, заблокированным для вашего провайдера. Сначала поднимите сам сервер — пошагово это описано в статье как установить и настроить WireGuard на VPS; там же вы получите публичный ключ и порт сервера для следующего шага.

На вкладке Peers созданного туннеля добавляем peer с параметрами сервера:

• Public Key — публичный ключ WireGuard-сервера на VPS.
• Endpoint — публичный IP-адрес VPS.
• Endpoint Port — порт сервера, обычно 51820.
• Allowed IPs — 0.0.0.0/0 для полного туннелирования всего трафика, или конкретные подсети, если нужен только частичный маршрут до определённых ресурсов.
• Keepalive interval — 25, чтобы держать NAT-маппинг живым между pfSense и провайдером.

Дальше нужно превратить туннель в полноценный сетевой интерфейс: Interfaces → Assignments, в списке доступных портов выбираем tun_wg0, добавляем и заходим в его настройки. Включаем интерфейс, задаём IPv4-адрес из тоннельной подсети — например 10.10.10.2/24, если на сервере вы выдали клиенту именно этот адрес. Сохраняем и применяем.

На стороне VPS в wg0.conf должна появиться зеркальная запись peer с публичным ключом pfSense и AllowedIPs = 10.10.10.2/32 (или шире, если через pfSense будет проходить трафик нескольких подсетей LAN).

pfSense как сервер: приём удалённых пиров и site-to-site

Обратная схема: pfSense принимает подключения — от ноутбука сотрудника в командировке, от домашнего роутера второго сотрудника или от pfSense/MikroTik второго офиса. Для этого на WAN нужен публичный IP (или проброс нужного UDP-порта на внешнем маршрутизаторе, если pfSense сидит за NAT провайдера — не поможет только при CGNAT).

Для каждого удалённого пира на вкладке Peers заводится отдельная запись:

• Public Key — публичный ключ конкретного клиента (генерируется на его стороне: wg genkey | tee client.key | wg pubkey > client.pub).
• Allowed IPs — узкий /32-адрес именно этого клиента внутри тоннельной подсети, например 10.10.10.10/32. Так pfSense понимает, какой IP-пакет от какого пира ждать, и не путает пиров между собой.

Для site-to-site с другим офисом логика та же, но Allowed IPs для peer второго офиса — не /32, а вся его LAN-подсеть целиком (например 192.168.20.0/24), чтобы pfSense знал, что пакеты в эту подсеть нужно заворачивать в туннель именно к этому пиру. Подробный разбор именно связки двух офисов через WireGuard, включая маршруты в обе стороны, есть в статье site-to-site VPN между офисами на WireGuard.

На WAN обязательно нужно открыть входящий UDP-порт для WireGuard — правило в Firewall → Rules → WAN: протокол UDP, destination port — тот, что задан в Listen Port туннеля.

Маршрутизация: как не потерять доступ к самому pfSense

Частая ошибка — поменять системный default gateway на WireGuard-интерфейс целиком. Если туннель до VPS оборвётся, вы вместе с трафиком локальной сети теряете и доступ к веб-интерфейсу самого pfSense, потому что у него у самого пропадает маршрут наружу.

Правильный порядок для схемы "весь LAN через VPS":

1. System → Routing → Gateways — создаём новый gateway на интерфейсе tun_wg0 (обычно IP-адрес peer'а на стороне сервера, например 10.10.10.1). Мониторинг по умолчанию использует ICMP до этого адреса — если сервер не отвечает на пинг внутри туннеля, отключите Disable Gateway Monitoring для этого gateway, иначе pfSense будет считать его "мёртвым" и постоянно переключаться.
2. Системный default gateway оставляем на WAN — так сам pfSense (обновления пакетов, DNS-резолвер, NTP) продолжает работать напрямую, даже если туннель ляжет.
3. На вкладке Firewall → Rules → LAN создаём (или правим существующее) правило, разрешающее нужный трафик, и в Advanced Features → Gateway указываем созданный WG-gateway. Это policy-based routing: конкретно это правило отправляет трафик через туннель, а не через системный default gateway.

Такой подход даёт побочный бонус: можно точечно исключить часть LAN-подсети или конкретный VLAN из туннеля, оставив для него отдельное правило без выбранного gateway — то, что на бытовом роутере обычно требует куда более неудобной настройки по MAC-адресам, а на pfSense делается парой правил в GUI. Похожий сценарий на роутере без такой гибкости разобран в статье VPN на роутере для всего дома.

Если критична доступность самого туннеля (например, VPN до VPS — единственный канал доступа сотрудников к рабочим ресурсам), имеет смысл настроить резервный сервер и Gateway Group с автоматическим переключением — общий подход к резервированию VPN-сервера описан в статье резервный VPN-сервер: автопереключение.

NAT и firewall-правила, которые часто забывают

WireGuard-интерфейс в pfSense по умолчанию попадает под общее правило "запретить всё", как и любой новый интерфейс — это стандартное поведение pfSense, и добавить туда фактические разрешающие правила нужно вручную:

• На вкладке firewall для самого WG-интерфейса (появится в списке после назначения tun_wg0) добавьте правило, разрешающее нужный трафик от тоннельной подсети — иначе даже при успешном handshake пакеты будут молча дропаться, и снаружи это выглядит как "VPN подключился, но ничего не работает".
• Если pfSense выступает сервером и удалённые клиенты должны выходить в интернет через ваш WAN, нужен outbound NAT: Firewall → NAT → Outbound, режим Hybrid или Manual, правило с Source = тоннельная подсеть (10.10.10.0/24), Interface = WAN, Translation = Interface Address.
• Для схемы "pfSense — клиент к VPS" отдельный outbound NAT на стороне pfSense обычно не нужен — трансляция уже происходит на VPS, где WireGuard-сервер настроен с MASQUERADE для исходящего трафика клиентов.
• При множестве пиров удобно группировать их адреса в Firewall → Aliases и писать правила по алиасу, а не по десятку отдельных /32.

Диагностика: handshake есть, а трафика нет

Первая точка проверки — Status → WireGuard, там видно время последнего handshake и счётчики переданных байт по каждому peer. Если handshake свежий (обновляется каждые 2 минуты при keepalive 25 секунд), но трафика нет, порядок проверки такой:

1. Firewall-правила на самом WG-интерфейсе. Самая частая причина — правило на интерфейс tun_wg0 не создано, и pfSense дропает пакеты по правилу "deny all" в конце цепочки. Смотрите Status → System Logs → Firewall — блокировки с интерфейса tun_wg0 укажут именно на это.
2. MTU. WireGuard по умолчанию использует MTU 1420. Если на WAN у вас PPPoE или дополнительная инкапсуляция, эффективный MTU может быть меньше, и крупные пакеты будут теряться без явной ошибки — понизьте MTU туннеля до 1380–1400 и проверьте заново.
3. Asymmetric routing. Если трафик уходит через WG-gateway, а ответ пытается вернуться другим путём (актуально при нескольких WAN), включите Reply-to на нужном правиле.
4. Время на pfSense. WireGuard чувствителен к рассинхронизации часов между сторонами — убедитесь, что NTP (System → General Setup) реально синхронизирован, особенно после перезагрузки без доступа в интернет.

Точных цифр по задержке или скорости через конкретный туннель заранее не даём — это зависит от канала до VPS, загрузки CPU pfSense (без AES-NI шифрование ощутимо ест ресурсы) и локации сервера; после настройки стоит сделать контрольный замер именно в вашей связке.

Частые вопросы