Почему не работает Port Forwarding в OPNsense?

Основная проблема с Port Forwarding в вашей конфигурации OPNsense, скорее всего, связана с асимметричной маршрутизацией или проблемами с state table, а также особенностями работы Floating rules в OPNsense. Ваша сложная сетевая архитектура с тремя мостами в Proxmox и DMZ-сегментом создает условия, которые часто вызывают подобные проблемы.

---

Содержание

• Основные причины проблем с Port Forwarding
• Асимметричная маршрутизация и reply-to
• Проблемы с Aliases и state table
• Настройка Floating rules
• Решение через NAT Reflection
• Пошаговая настройка для вашей конфигурации
• Диагностика и проверка

---

Основные причины проблем с Port Forwarding

Исходя из анализа вашего случая и исследований, основные причины, почему не работает Port Forwarding в OPNsense, включают:

1. Асимметричная маршрутизация - самый частый виновник
2. Проблемы с использованием aliases вместо фиксированных IP-адресов
3. Конфликты между автоматическими Floating rules и ручными правилами
4. State table issues, особенно в сложных сетевых конфигурациях
5. Отсутствие NAT Reflection для трафика из DMZ в LAN

Ваша конфигурация с тремя мостами в Proxmox и DMZ-сегментом создает идеальные условия для возникновения этих проблем.

---

Асимметричная маршрутизация и reply-to

Асимметричная маршрутизация - это самая распространенная проблема, с которой сталкиваются пользователи OPNsense при настройке Port Forwarding, особенно в конфигурациях с DMZ.

Причина проблемы: Когда трафик приходит из WAN, проходит NAT и направляется в DMZ, но ответы от DMZ-сервера могут идти напрямую обратно в интернет, минуя OPNsense, что создает асимметричный маршрут.

Решение: В настройках вашего NAT Port Forward правила необходимо убедиться, что установлена опция “reply-to” для WAN интерфейса.

Как указывают в дискуссиях на Reddit: “This is a well-known asymmetric routing problem, you need to make sure the reply-to is set for WAN и если у вас есть NAT Port Forwarding для VPN интерфейса или другого вторичного WAN, отключите автоматическое создание правил файрвола и создайте вручную.”

В интерфейсе OPNsense это настраивается в разделе Firewall > NAT > Port Forward - редактируя правило и проверяя, что поле “Reply-to” установлено правильно.

---

Проблемы с Aliases и state table

Ваши проблемы могут усугубляться использованием aliases в NAT правилах. Как показывают отчеты об ошибках в OPNsense:

“После обновления до OPNsense 18.1.b_273-amd64 мои правила NAT Port Forward перестали работать. Весь трафик внезапно блокировался правилом “Default deny” на WAN интерфейсе… После смены использования Alias на фиксированный IP-адрес во всех правилах NAT Port Forward всё снова заработало.”

Рекомендация: Временно замените все aliases в NAT Port Forward правилах на фиксированные IP-адреса DMZ-сервера (Apache2 VM). Это поможет исключить проблемы с разрешением имен и state table.

Также попробуйте сбросить state table через Firewall > Diagnostics > States > Actions > Reset State Table. Как отмечают пользователи, это часто решает проблемы с “зависшими” состояниями соединений.

---

Настройка Floating rules

В OPNsense при использовании нескольких интерфейсов в Port Forward правилах автоматически создаются Floating rules. Как объясняется в документации OPNsense:

“Если в правиле Port Forward выбраны несколько интерфейсов, связанное правило фильтра появится в Firewall > Rules > Floating.”

Важно: Floating rules в OPNsense имеют приоритет 200000, в то время как обычные интерфейсные правила имеют приоритет 400000. Это означает, что Floating rules обрабатываются раньше.

Если у вас есть конфликтные правила, они могут мешать работе Port Forwarding. Проверьте раздел Firewall > Rules > Floating и удалите или измените любые правила, которые могут блокировать трафик к вашему DMZ-серверу.

---

Решение через NAT Reflection

Для вашей конфигурации с DMZ может потребоваться включить NAT Reflection. Как показывают исследования на Reddit:

“Для всех, кто столкнулся с этой проблемой, я решил её, включив ‘Reflection for port forwards’. Этот параметр можно найти в Firewall > Settings > advanced.”

NAT Reflection позволяет внутренним клиентам обращаться к серверам через внешний IP-адрес, решая проблемы маршрутизации.

В документации OPNsense объясняется механизм работы: “Если пакет принят OPNsense на любом из интерфейсов WAN, DMZ и LAN с протоколом TCP… переписать destination IP на 172.16.1.1 и destination port на 443.”

Для вашей конфигурации это может быть критически важно.

---

Пошаговая настройка для вашей конфигурации

Исходя из вашей архитектуры, рекомендую следующий порядок действий:

1. Временно отключите файрвол полностью для теста:

   • Перейдите в System > Settings > Firewall
   • Установите галочку “Disable all firewall (including NAT) features of this machine”
   • Проверьте доступность сайта - если заработает, проблема в правилах файрвола

2. Создайте базовое NAT Port Forward правило:

   • Интерфейс: WAN
   • Внешний порт: 80 (или 443 для HTTPS)
   • Внутренний IP: фиксированный IP Apache2 VM в DMZ (не alias!)
   • Протокол: TCP
   • Установите галочку “Reply-to WAN interface”

3. Проверьте Floating rules:

   • Убедитесь, что нет конфликтующих правил
   • При необходимости создайте ручное правило в Floating для разрешения трафика на внутренний IP

4. Включите NAT Reflection:

   • Firewall > Settings > Advanced
   • Найдите “Reflection for port forwards” и установите в “Enable”

5. Проверьте состояние state table:

   • Firewall > Diagnostics > States
   • Убедитесь, что соединения создаются корректно
   • При необходимости сбросьте таблицу состояний

---

Диагностика и проверка

Для дальнейшей диагностики используйте следующие команды в OPNsense:

1. Проверьте NAT таблицу:

   bash

   pfctl -s nat
   

2. Проверьте правила файрвола:

   bash

   pfctl -s rules
   

3. Мониторьте состояние соединений:

   bash

   pfctl -s states | grep Apache2_IP
   

4. Используйте tcpdump для анализа:

   bash

   tcpdump -i vmbr0 port 80
   tcpdump -i vmbr2 port 80
   

Ваше наблюдение о сбросе соединений (RST) указывает на то, что OPNsense видит входящий трафик, но что-то блокирует обратный путь. Скорее всего, это либо проблемы с state table, либо неправильная маршрутизация в DMZ-сегменте.

Если pfSense работал с минимальными настройками, это подтверждает, что проблема специфична для OPNsense и связана с ее более сложной системой правил обработки трафика.

---

Источники

1. NAT Port Forwarding not working at all - Reddit Discussion
2. Reflection and Hairpin NAT — OPNsense Documentation
3. NAT Port Forward Alias not working · GitHub Issue
4. Rules — OPNsense Documentation
5. Network Address Translation — OPNsense Documentation
6. OPNsense behind ISP router and port forwarding - Reddit

---

Заключение

1. Основная вероятная причина вашей проблемы - асимметричная маршрутизация между WAN и DMZ сегментами, требующая правильной настройки “reply-to” в NAT правилах.

2. Обязательно замените aliases на фиксированные IP-адреса во всех NAT Port Forward правилах для исключения проблем с state table.

3. Включите NAT Reflection в настройках файрвола - это критически важно для вашей конфигурации с DMZ.

4. Проверьте и при необходимости очистите Floating rules - они могут конфликтовать с вашими ручными настройками из-за разницы в приоритетах обработки.

5. Используйте диагностические инструменты OPNsense (tcpdump, pfctl) для точного определения точки сброса соединений.

Если проблема не решается после этих шагов, возможно, стоит рассмотреть альтернативную архитектуру сети или временно использовать pfSense для критически важных сервисов, пока не будет найдено решение для OPNsense.