В мире сетевых механизмов OPNsense — это не просто фаервол, а настоящий паровой котёл с кучей клапанов и передач. Одним из самых востребованных клапанов остаётся Destination NAT, он же порт-форвардинг. Нужно открыть SSH, веб-сервер, игровой сервер или IP-камеру из интернета — и вот уже внешний трафик должен аккуратно проскочить через WAN и приземлиться на нужный хост внутри LAN.
Я прогонял эту схему на живых инсталляциях от 21.x до свежего 26.7 «Xenial Xenops». Принцип не изменился, хотя интерфейс слегка подкрутили, а связанные правила фаервола стали гибче. Разберём по шагам, с подводными камнями и тем, что обычно забывают в «быстрых» гайдах.
Что происходит под капотом
Когда пакет прилетает на WAN-интерфейс на определённый порт, OPNsense (а точнее pf) переписывает destination-адрес и, при необходимости, порт. Пакет отправляется на внутренний хост. Ответный трафик автоматически проходит через stateful-таблицу — отдельное правило для «обратного хода» обычно не требуется.
Важно помнить: NAT — это не безопасность. Это просто переадресация. Без правильно настроенных правил фаервола вы просто открываете дыру.
Подготовка тестового стенда
Классическая схема, которую я использую в лаборатории:
- OPNsense: LAN 192.168.56.254/24, WAN — реальный или «серый» внешний адрес.
- Внутренний сервер (Ubuntu/Debian): 192.168.56.19/24, шлюз 192.168.56.254.
- Сервисы: SSH (22) и HTTP (80).
Сначала убедитесь, что внутренний хост ходит в интернет через OPNsense:
ip a show
ip route
ping -c 3 192.168.56.254
ping -c 3 8.8.8.8Если всё зелёное — можно крутить вентили.
Создание правила Destination NAT (Port Forward)
- Заходим в веб-интерфейс OPNsense (обычно https://IP:8443 или ваш кастомный порт).
- Идём в Firewall → NAT → Destination NAT (Port Forward).
- Жмём оранжевую кнопку + (Add).
Заполняем поля так (пример для SSH):
- Interface: WAN
- TCP/IP Version: IPv4 (или IPv4+IPv6, если нужно)
- Protocol: TCP
- Source: any (или ограничьте по стране/алиасу, если паранойя сильна)
- Destination: WAN address (или конкретный VIP, если у вас несколько внешних адресов)
- Redirect target IP: 192.168.56.19
- Redirect target port: SSH (или 22)
- Description: SSH to Ubuntu lab server
- Filter rule association: лучше выбрать Add associated filter rule или Pass — в зависимости от того, насколько вы любите контролировать правила вручную. Для простых случаев «Add associated filter rule» удобнее всего.
Сохраняем и жмём Apply changes.

Повторяем почти то же самое для HTTP, только порт HTTP / 80.
Проверка и тонкости, которые любят ломаться
После применения правил проверяем снаружи:
# С внешнего хоста или через мобильный интернет
ssh user@ВАШ_ВНЕШНИЙ_IP
# или
curl -I http://ВАШ_ВНЕШНИЙ_IPЕсли не пускает:
- Проверьте, что на внутреннем хосте сервис реально слушает нужный порт (ss -tulnp).
- Убедитесь, что associated filter rule появилось в Firewall → Rules → WAN и оно выше блокирующих правил.
- Включите логирование на правиле NAT и посмотрите Firewall → Log Files → Live View.
- Если у вас несколько WAN или CARP — destination должен быть именно тот адрес, на который приходит трафик.
- NAT Reflection нужен, если клиенты из LAN обращаются к сервису по внешнему IP. Без него получите «чёрную дыру».
Ещё один нюанс из практики: если вы меняете порт на внешнем интерфейсе (например, внешний 2222 → внутренний 22), не забывайте про это в клиентах и в мониторинге. И никогда не открывайте SSH наружу без ключей или fail2ban/CrowdSec.
Когда лучше не использовать простой порт-форвард
- Если сервис критичный — лучше VPN (WireGuard/OpenVPN) или reverse-proxy с аутентификацией.
- Для веб-сервисов предпочтительнее HAProxy/Nginx Proxy Manager + Let’s Encrypt, а не голый порт 80/443.
- При большом количестве правил — заводите алиасы на IP и порты. Иначе через полгода вы сами не вспомните, куда что ведёт.
Порт-форвардинг в OPNsense — это как правильно отрегулированный паровой клапан: работает тихо и надёжно, пока вы не начинаете крутить гайки наугад. Делайте осознанно, логируйте и периодически проверяйте, что правила ещё актуальны.