Port forwarding HTTP/HTTPS from WAN2 to VLAN

PTZ-M

@pigbrother
Включил: Pure NAT, NAT Reflection for 1:1 NAT, automatic outbound NAT for Reflection - теперь страница PFSense не грузиться, но и порты нужные мне недоступны.
Проброс портов из LAN вместе с NAT Reflection ещё надо сделать?

pigbrother

This post is deleted!

pigbrother

@ptz-m Когда пользовался - включал только
NAT Reflection mode for port forwards - NAT+proxy
Enable NAT Reflection for 1:1 NAT - не включал

@ptz-m said in Port forwarding HTTP/HTTPS from WAN2 to VLAN:

Проброс портов из LAN вместе с NAT Reflection ещё надо сделать?

Нет. Работало и без этого.

Примечание. У меня проброс был сделан в DMZ. Но разницы быть не должно, что VLAN, что DMZ - это просто интерфейсы.

PTZ-M

@pigbrother said in Port forwarding HTTP/HTTPS from WAN2 to VLAN:

Работало и без этого.

Сработало :-) Даже при том что я указал "блокировать" в правилах для интерфейса WEB (VLAN 100) на доступ к LAN, и использование дефолтного шлюза (чтобы нельзя было ломанув сервак пробиться куда-то ещё, или ботнет подсадить). Косяков пока не выявлено, т.ч. снова закрываю вопрос.

PTZ-M

@ptz-m said in Port forwarding HTTP/HTTPS from WAN2 to VLAN:

Косяков пока не выявлено

Упс, выявился жёсткий косяк - отвалился SIP (нет самой регистрации на станции, показывает, что номер в дауне), который коннектился из VLAN 10 (Wi-Fi) на Asterisk в LAN адресуясь через внешний IP на WAN1 (что-бы можно было бесшовно переходить на мобильный канал, когда вафля вне зоны действия смартфона). При этом аналогичная схема с видеонаблюдением работает. Похоже трафик UDP дропается; не похоже на дроп диапазона для RTP, поскольку там звонок бы просто срывался.

pigbrother

@ptz-m "Правильный" способ, все же - split DNS.

@ptz-m said in Port forwarding HTTP/HTTPS from WAN2 to VLAN:

максимально изолировать хотелось ту машину.

Однако при split DNS придется разрешать доступ к нужным хостам в VLAN100 из LAN. Можно только по нужным портам

PTZ-M

@pigbrother said in Port forwarding HTTP/HTTPS from WAN2 to VLAN:

split DNS

В моём случае трогать всё что, касается DNS - категорически не рекомендуется. Только "гвоздями прибивать".

PTZ-M

@ptz-m said in Port forwarding HTTP/HTTPS from WAN2 to VLAN:

Упс, выявился жёсткий косяк - отвалился SIP (нет самой регистрации на станции, показывает, что номер в дауне), который коннектился из VLAN 10 (Wi-Fi) на Asterisk в LAN адресуясь через внешний IP на WAN1 (что-бы можно было бесшовно переходить на мобильный канал, когда вафля вне зоны действия смартфона). При этом аналогичная схема с видеонаблюдением работает. Похоже трафик UDP дропается; не похоже на дроп диапазона для RTP, поскольку там звонок бы просто срывался.

Проблема с отвалом SIP при глобальном "отражение NAT" в режиме NAT + Proxy cтала весьма ощутимо мешать.

Попробовал в NAT (для проброса порта 5060 из WiFi) менять настройки отражения NAT - нет никаких изменений поведения). Если вбивать локальный IP, то всё так и работает из под VLAN 10 (Wi-Fi); с мира то же нет проблем с коннектом при вводе IP от WAN1; а вот через VLAN 10 (Wi-Fi) так и не может подцепиться.

Примерная схема, которая работала до начала изменений в NAT, в здании офиса:
сотовый -> SIP-модуль -> VLAN 10 (Wi-Fi) -> PfSense -> WAN1 IP -> LAN -> Asterisk

Примерная схема, которая работет до начала изменений в NAT и после, вне здания офиса:
сотовый -> SIP-модуль -> мобильная сеть -> WAN1 -> PfSense -> LAN -> Asterisk

Примерная схема, которая работает после изменений в NAT, в здании офиса:
сотовый -> SIP-модуль -> VLAN 10 (Wi-Fi) -> PfSense -> LAN -> Asterisk

Примерная схема, которой добивались изменяя NAT, в здании офиса:
компьютер -> LAN -> PfSense -> WAN2 -> сервер

Последние эксперименты проводил уже на 2.6.0.

Любые мысли?

Konstanti

@ptz-m

Здр
Мысль проста - начните анализ с простой диагностики
Те - запустите tcpdump на PF , и посмотрите , что происходит на нужных Вам интерфейсах в момент соединения

tcpdump -netti имя_интерфейса udp and port 5060

если можно , покажите результат тут

werter

Добрый
@ptz-m
С этим сравнивали?
https://docs.netgate.com/pfsense/en/latest/recipes/nat-voip-phones.html
https://docs.netgate.com/pfsense/en/latest/recipes/nat-voip-pbx.html

Используя ссылки выше никогда не имел проблем с voip+nat.
Кроме случаев, когда у клиентов есть роутер с sip helper (из последнего был микротик). Отключение sip helper решило проблему с sip.

PTZ-M

@konstanti извечный вопрос - где смотреть и что искать? В VLAN 10 (Wi-Fi)?
Выше я писал, что видеонаблюдение приложения iVMS-4500 в такой же ситуации (VLAN 10 (Wi-Fi) -> WAN1 IP) работает, т.е. пакеты прекрасно ходят. А в Asterisk даже регистрация линии не проходит при таких же настройках проброса порта в NAT.

PTZ-M

@werter said in Port forwarding HTTP/HTTPS from WAN2 to VLAN:

С этим сравнивали?
https://docs.netgate.com/pfsense/en/latest/recipes/nat-voip-phones.html
https://docs.netgate.com/pfsense/en/latest/recipes/nat-voip-pbx.html

Там вода для чайников. Надо копать в сторону настроек NAT

Konstanti

@ptz-m
Ну , так посмотрите на нужных интерфейсах с помощью tcpdump , какой обмен пакетами происходит , и все ли верно ?
Получает ли Аsterisk пакет SIP Register , и что и куда он на него отвечает
Я бы лично начал бы с изучения трафика на интерфейсе , на котором висит Asterisk .
Те , Ваша задача состоит в том , чтобы определить , нет ли проблем передачи нужного трафика ( и изучение самого трафика ) в момент установления соединения ( на всех интерфейсах , которые участвуют в этом процессе )

PTZ-M

В общем ситуация с SIP похожа на лабиринт Минотавра для пакетов UDP, поэтому плюнул, сижу через мобильную сеть.

Сейчас интересно другое, уже несколько раз pfSense вис наглухо. Сегодня zabbix успел выдать "Too many processes on pfsense", а в логах постоянно висит "Service 19009-tcp: server exit with 0 running servers" и такое:

Nov 29 09:31:55 xinetd 29375 Service 19009-tcp: server exit with 0 running servers
Nov 29 09:31:55 kernel config_aqm Unable to configure flowset, flowset busy!
Nov 29 09:31:55 php-fpm 9500 /rc.filter_configure_sync: Not installing NAT reflection rules for a port range > 500
Nov 29 09:31:55 php-fpm 9500 /rc.filter_configure_sync: Not installing NAT reflection rules for a port range > 500
Nov 29 09:31:55 xinetd 29375 Starting reconfiguration
Nov 29 09:31:55 xinetd 29375 Swapping defaults
Nov 29 09:31:55 xinetd 29375 readjusting service 19000-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19000-udp
Nov 29 09:31:55 xinetd 29375 readjusting service 19001-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19001-udp
Nov 29 09:31:55 xinetd 29375 readjusting service 19002-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19002-udp
Nov 29 09:31:55 xinetd 29375 readjusting service 19003-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19003-udp
Nov 29 09:31:55 xinetd 29375 readjusting service 19004-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19004-udp
Nov 29 09:31:55 xinetd 29375 readjusting service 19005-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19006-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19007-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19008-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19009-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19010-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19011-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19012-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19013-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19014-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19015-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19016-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19017-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19018-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19019-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19020-udp
Nov 29 09:31:55 xinetd 29375 readjusting service 19021-udp
Nov 29 09:31:55 xinetd 29375 readjusting service 19022-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19023-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19024-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19025-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19026-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19027-tcp
Nov 29 09:31:55 xinetd 29375 readjusting service 19028-tcp
Nov 29 09:31:55 xinetd 29375 Reconfigured: new=0 old=34 dropped=0 (services)
Nov 29 09:31:56 xinetd 29375 Service 19009-tcp: server exit with 0 running servers
Nov 29 09:31:57 xinetd 29375 Service 19009-tcp: server exit with 0 running servers
Nov 29 09:31:58 xinetd 29375 Deactivating service 19012-tcp due to excessive incoming connections. Restarting in 10 seconds.
Nov 29 09:31:59 xinetd 29375 Service 19009-tcp: server exit with 0 running servers
Nov 29 09:32:00 sshguard 70811 Exiting on signal.
Nov 29 09:32:00 sshguard 71823 Now monitoring attacks.
Nov 29 09:32:01 xinetd 29375 Service 19009-tcp: server exit with 0 running servers
Nov 29 09:32:01 xinetd 29375 Service 19009-tcp: server exit with 0 running servers
Nov 29 09:32:02 xinetd 29375 Service 19009-tcp: server exit with 0 running servers
Nov 29 09:32:04 xinetd 29375 Activating service 19009-tcp
Nov 29 09:32:06 xinetd 29375 Service 19009-tcp: server exit with 0 running servers

нашёл смежную тему [Resolved]"Service 19050-tcp: server exit with 0 running servers" = ??
10 месяцев назад, как раз и трогали NAT reflection и NAT+proxy mode, что бы пропихнуть трафик в обратку.

Обновления никакие не ставил последний месяц. IPSec так и не использую, только OpenVPN по сертификатам.
Идеи?

werter

@ptz-m
Да все, что угодно может быть. Гадалки в отпуске.
Нес-ко раз настриваил прохождение voip на пф по оф. доке - проблем не было.
Зы. У тебя там и шейпер включен?

PTZ-M

Подниму тему, хотя наверное немного и то. Надеюсь поправят.

Итак, ситуация на вложенном изображении

В 1-ом случае "внешний" SIP-телефон почему-то проброшен на IAX порт, хотя он работает по портам SIP. Такое видел один раз, но не факт, что не проскакивает в принципе.

Ниже указанные правила в экране. Как видим Asterix (это уже не старая коробка, как раньше, а последняя версия на FreePBX на новом Ubuntu) с IP ....0.151 мы отправляем на WAN1 в MiltiWAN, поскольку перепрыгивания между WAN оператором телефонии расцениваются как DDOS-атака и нас банили. Аналогично IAX туннель в других офисах настроен на наш WAN1.

Во 2-ом и 3-ем случае мы видим задвоение. В результате IAX туннель висит наглухо и пока не убьёшь одно из соединений - не восстанавливается.

Вот так всё работает стабильно. Ничего ручками не маршрутизируем или перебрасываем.

Такая ситуация тянется не первый год на PfSense. Раньше мы не понимали, почему только в нашем офисе такие затупы канала и грешили на АТС. В результате чего просто перегружали её. После замены АТС, стало понятно, что дело именно в PfSense!

Соответственно вопрос - почему так происходит с пробросом портов? Что-то не так зеркалится? Как можно поправить?

Konstanti

This post is deleted!