Windows Firewall: какие порты открыть для каждого протокола VPN
Разворачиваете VPN-сервер на Windows и упираетесь в вопрос: какой конкретно порт открыть в файрволе, чтобы клиент подключился, а всё лишнее осталось закрытым? У каждого протокола свой набор портов и своя специфика — WireGuard обходится одним UDP-портом, а IKEv2 и L2TP требуют ещё и отдельного IP-протокола ESP, про который часто забывают. Ниже — сводная таблица по всем пяти протоколам и готовые команды PowerShell для Windows Defender Firewall, которые можно применить сразу на сервере и на клиенте.
Содержание
Обсудить статью, задать вопрос или начать новую тему
Есть вопрос по этой статье, идея для обсуждения или просто хотите поделиться опытом? Сообщество MAATRIX ждёт. Для общения, пожалуйста, зарегистрируйтесь в нашем личном кабинете.
Перейти в сообщество →Сводная таблица портов по протоколам
Прежде чем открывать что-либо, полезно увидеть картину целиком. В таблице — минимальный набор портов, без которых протокол не заработает, и что каждый из них делает.
| Протокол | Порт(ы) | Транспорт | Назначение |
|---|---|---|---|
| WireGuard | 51820 | UDP | Единственный порт, весь трафик туннеля |
| OpenVPN | 1194 | UDP (реже TCP) | Основной канал данных и управления |
| IKEv2 | 500, 4500 | UDP | 500 — согласование ключей (IKE), 4500 — NAT-T |
| IKEv2 | протокол 50 (ESP) | IP-протокол, не порт | Шифрованные данные, если сервер не за NAT |
| L2TP/IPsec | 500, 4500, 1701 | UDP | 500/4500 — как у IKEv2, 1701 — данные L2TP |
| SSTP | 443 | TCP | Тот же порт, что HTTPS — маскируется под веб-трафик |
Важный нюанс, который путает многих: IKEv2 и L2TP используют не только UDP-порты, но и IP-протокол ESP (номер 50) — это не порт в привычном смысле, а отдельный протокол на сетевом уровне, и правило файрвола под него создаётся иначе, чем под TCP/UDP-порт. Если сервер и клиент оба видят друг друга не через NAT, ESP идёт напрямую; если между ними NAT (а это почти всегда так в облаке и с мобильными клиентами), весь трафик, включая ESP, инкапсулируется в UDP 4500 — тогда номер 50 отдельно открывать не нужно. Дальше разберём каждый протокол по отдельности с готовыми командами.
WireGuard: один порт UDP 51820
WireGuard — самый простой случай: один UDP-порт, никаких дополнительных протоколов. На сервере правило создаётся одной командой:
New-NetFirewallRule -DisplayName "WireGuard Inbound" -Direction Inbound -Protocol UDP -LocalPort 51820 -Action Allow -Profile AnyЕсли меняли порт по умолчанию в конфиге интерфейса (строка ListenPort в .conf), номер в правиле файрвола должен совпадать буквально — WireGuard не подскажет, что порты разошлись, соединение просто не установится, а диагностировать придётся вручную. На стороне клиента отдельное входящее правило обычно не требуется: клиент сам инициирует соединение, а ответные пакеты от сервера проходят по существующей UDP-сессии благодаря механизму stateful-инспекции файрвола. Подробный процесс установки самой службы — в статье про установку WireGuard на Windows Server.
Арендуйте сервер под свои задачи!
Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK, США, Франция и РФ. Оплата картой РФ и по СБП.
Арендовать серверOpenVPN: UDP или TCP 1194
OpenVPN по умолчанию слушает UDP 1194 — это быстрее и лучше подходит для VPN-трафика, потому что UDP не тратит время на переустановку TCP-сессии при потере пакета. Правило для сервера:
New-NetFirewallRule -DisplayName "OpenVPN UDP Inbound" -Direction Inbound -Protocol UDP -LocalPort 1194 -Action Allow -Profile AnyЕсли сеть клиента блокирует произвольный UDP-трафик (частая ситуация в офисных и мобильных сетях, где открыт только HTTP/HTTPS), OpenVPN можно перевести на TCP — обычно на порт 443, чтобы трафик выглядел как обычный HTTPS:
New-NetFirewallRule -DisplayName "OpenVPN TCP Inbound" -Direction Inbound -Protocol TCP -LocalPort 443 -Action Allow -Profile AnyВажно: TCP-режим OpenVPN и SSTP оба используют порт 443, но это разные службы — держать их одновременно на одном порту одного IP-адреса нельзя, нужно либо развести по разным адресам/портам, либо выбрать один протокол. С частыми проблемами именно на этапе установки TCP/UDP-соединения помогает разобраться статья про типичные ошибки OpenVPN на сервере.
IKEv2: UDP 500, UDP 4500 и ESP
IKEv2 — протокол из семейства IPsec, и именно здесь чаще всего путают набор портов. Первое правило открывает IKE — согласование ключей шифрования:
New-NetFirewallRule -DisplayName "IKEv2 IKE Inbound" -Direction Inbound -Protocol UDP -LocalPort 500 -Action Allow -Profile AnyВторое — NAT-T (NAT Traversal), порт, через который проходит инкапсулированный трафик, если между клиентом и сервером есть NAT (а для клиента за домашним роутером или мобильной сетью это правило, а не исключение):
New-NetFirewallRule -DisplayName "IKEv2 NAT-T Inbound" -Direction Inbound -Protocol UDP -LocalPort 4500 -Action Allow -Profile AnyОтдельно — правило для ESP (IP-протокол 50), которое нужно, только если ожидаются прямые подключения без NAT-T:
New-NetFirewallRule -DisplayName "IKEv2 ESP Inbound" -Direction Inbound -Protocol 50 -Action Allow -Profile AnyНа практике при развёртывании через роль RRAS (Routing and Remote Access) Windows Server сама добавляет часть этих правил при включении службы — но если сервер стоит за облачным файрволом хостера (security group, отдельная от файрвола внутри гостевой ОС), те же порты придётся открыть и там, иначе внутреннее правило будет бессмысленным. Если ещё не поднимали сам сервис IKEv2, пошаговая настройка роли RRAS описана в статье про IKEv2 VPN на Windows Server с нуля — там же разбирается выпуск сертификатов, без которых IKEv2 не аутентифицирует клиентов.
L2TP/IPsec: UDP 500, 1701, 4500 — и грабля с двойным NAT
L2TP всегда работает поверх IPsec, поэтому набор портов пересекается с IKEv2: те же UDP 500 и 4500 для согласования ключей и NAT-T, плюс отдельный UDP 1701 для самих данных L2TP:
New-NetFirewallRule -DisplayName "L2TP IPsec IKE Inbound" -Direction Inbound -Protocol UDP -LocalPort 500 -Action Allow -Profile Any
New-NetFirewallRule -DisplayName "L2TP IPsec NAT-T Inbound" -Direction Inbound -Protocol UDP -LocalPort 4500 -Action Allow -Profile Any
New-NetFirewallRule -DisplayName "L2TP Data Inbound" -Direction Inbound -Protocol UDP -LocalPort 1701 -Action Allow -Profile AnyЧастая грабля L2TP — двойной NAT: если и сервер, и клиент оказываются каждый за своим NAT (например, сервер — в облаке за NAT провайдера, а клиент — за NAT домашнего роутера, который сам стоит за NAT мобильного оператора), согласование через порт 500 может пройти, а следующий этап — зависнуть, потому что часть промежуточных узлов режет нестандартные IPsec-пакеты. Смотреть в этом случае нужно не столько в файрвол Windows, сколько в то, действительно ли пакеты вообще доходят до сервера — для этого пригодится журнал файрвола, включённый по инструкции в статье про настройку файрвола Windows для VPN-туннеля. Разворачивание самой роли L2TP/IPsec на RRAS с нуля разобрано отдельно — пошаговая инструкция для Windows Server.
SSTP: TCP 443, маскировка под HTTPS
SSTP (Secure Socket Tunneling Protocol) — единственный из пяти протоколов, который принципиально устроен иначе: он оборачивает VPN-трафик в SSL/TLS-сессию на стандартном HTTPS-порту. С точки зрения файрвола и внешнего наблюдателя SSTP-соединение неотличимо от обращения к обычному защищённому сайту:
New-NetFirewallRule -DisplayName "SSTP Inbound" -Direction Inbound -Protocol TCP -LocalPort 443 -Action Allow -Profile AnyЭто одновременно и сильная, и слабая сторона протокола. Сильная — SSTP почти никогда не блокируется корпоративными и провайдерскими файрволами, потому что закрыть 443 означает закрыть доступ ко всему HTTPS-интернету. Слабая — для работы SSTP на сервере обязательно должен быть установлен доверенный клиентом SSL-сертификат, привязанный к тому же порту 443, что и сам туннель; без правильно настроенного сертификата подключение просто не пройдёт проверку, даже если порт открыт. Про выпуск сертификатов для этого сценария — статья про сертификаты для IKEv2 и SSTP через центр сертификации Windows.
Правила для клиента и типичные ошибки
Всё, что выше, — правила на стороне сервера, для входящих подключений. На стороне клиента (обычный ноутбук или рабочая станция, а не шлюз) отдельные входящие правила почти никогда не нужны: клиент сам инициирует сессию, а весь ответный трафик проходит по уже установленному состоянию соединения, которое Windows Defender Firewall отслеживает автоматически для TCP и UDP. Единственное исключение — если на клиентской машине заранее включена жёсткая политика блокировки исходящего трафика по умолчанию: тогда придётся явно разрешить исходящий UDP или TCP на нужный порт, аналогично серверным командам выше, но с -Direction Outbound.
Три ошибки повторяются чаще остальных. Первая — открыть порт внутри гостевой ОС и забыть про облачный файрвол хостера: у виртуального сервера обычно два независимых слоя фильтрации, и правило в Windows Defender Firewall ничего не даст, если тот же порт закрыт на уровне security group в панели управления. Вторая — перепутать номер порта в конфиге службы и в правиле файрвола после смены значения по умолчанию: файрвол молча пропускает то, что указано в правиле, а служба слушает то, что указано в конфиге, и если цифры разошлись, оба компонента "работают правильно" по отдельности, но вместе — нет. Третья — для IKEv2 и L2TP открыть только порт 500 и забыть про 4500, из-за чего согласование ключей проходит, а сам туннель не поднимается, потому что клиент почти всегда стоит за NAT и нуждается именно в NAT-T. Общая проверка каждого варианта одна: посмотреть, какие порты реально слушает сервер, командой Get-NetTCPConnection и Get-NetUDPEndpoint, и сверить со списком открытых портов в файрволе через Get-NetFirewallRule — если разошлось, разбираться нужно именно с той стороны, где несовпадение.
Арендуйте сервер под свои задачи!
Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK, США, Франция и РФ. Оплата картой РФ и по СБП.
Арендовать серверНужны сами нейросети для контента?
Генерируйте изображения, видео и озвучку нейросетями на falapi.io — десятки моделей в одном окне. Оплата картой РФ и по СБП.
Частые вопросы
Нужно ли открывать все пять протоколов сразу, если сервер использует только один?
Нет, это только увеличивает поверхность атаки. Открывайте порты ровно того протокола, который реально запущен — остальные правила не создавайте вообще.
Почему WireGuard требует один порт, а IKEv2 — сразу три?
Архитектура разная: WireGuard — минималистичный протокол без отдельной фазы согласования ключей поверх IPsec, а IKEv2 построен на стандарте IPsec, где согласование (IKE), обход NAT (NAT-T) и передача данных (ESP) исторически разнесены на разные порты и протоколы.
Можно ли сменить порт по умолчанию у любого из протоколов ради безопасности через "неясность"?
У WireGuard и OpenVPN — да, порт настраивается свободно в конфиге службы с соответствующей правкой правила файрвола. У IKEv2 и SSTP порты 500/4500 и 443 привязаны к стандарту и клиентским реализациям гораздо жёстче, менять их по своей инициативе обычно не имеет смысла.
Как понять, что проблема именно в файрволе, а не в самом VPN-сервисе?
Включить логирование блокировок Windows Defender Firewall (Set-NetFirewallProfile -LogBlocked True) и посмотреть, доходят ли вообще пакеты клиента до сервера. Если в логе нет записей DROP по нужному порту — пакеты не доходят раньше файрвола Windows, и смотреть нужно в облачный firewall хостера или в сеть между клиентом и сервером.
Нужно ли отдельно открывать порт для ping или диагностики после настройки VPN?
Нет, это не относится к самому протоколу VPN. Если нужна проверка доступности по ICMP внутри туннеля, это отдельное правило под протокол ICMPv4/ICMPv6, никак не связанное с портами WireGuard, OpenVPN, IKEv2, L2TP или SSTP.
Обсудить статью, задать вопрос или начать новую тему
Есть вопрос по этой статье, идея для обсуждения или просто хотите поделиться опытом? Сообщество MAATRIX ждёт. Для общения, пожалуйста, зарегистрируйтесь в нашем личном кабинете.
Перейти в сообщество →