Проброс портов, не хочет работать
-
Здравствуйте
(сложно что-либо говорить , не видя настроек и схемы сети)
не совсем понял , зачем Вам исходящий NAT на Lan 4 интерфейсе с подменой адреса источника - возможно , что именно тут ошибка (отключите)
Те, по-моему ,
1 должен быть настроен проброс портов с WAN интерфейса провайдера Б к серверам сети 172.16.0.0/24 без изменения адреса источника , меняется только адрес получателя и возможно порт (судя по всему - сделано )
2 должен быть настроен Nat Outbound на интерфейсе WAN Провайдера Б для сети 172.16.0.0/24ответ из сети 172.16.0.0/24 на пакет , пришедший на интерфейс WAN пр Б , по таблице состояний должен уходить через WAN пр Б
3 шлюзом по умолчанию тогда можно оставить шлюз провайдера А
4 правило "Pass IPv4 TCP/UDP source=172.16.0.0/24 destination=any Gateway="шлюз провайдер Б" работает только для исходящего графика , инициируемого серверами сети 176XXXX ( если у Вас соединение было создано извне , то это правило уже не работает , так такое соединение уже внесено в таблицу состояний и его не надо снова проверять правилами файрвола)
-
Провайдер А и провайдер Б на одном интерфейсе сидят? оба на WAN?
Понял так что оба на WAN.
Проверьте исходящий NAT, выставьте режим ручной, авто правила можете оставить. В настройках интерфейса WAN уберите шлюз. Далее работайте правилами фаервола.
Не до конца понятно что у вас с пробросом порта. Сделайте скрины с настройками если позволяет полика безопасности. Или сделайте схему того что вам нужно реализовать. -
@stiff
Два провайдера, WAN интерфейса тоже два, на одном из WAN (несколько белых IP от 1 провайдера) на другом камеры
PfSens ставится на место микротика
Добились получения интернета через локалку, решили попробовать переключить камеры, выяснили что проброс не работает
Если ставить Dafault Gateway например WAN1 (где несколько белых IP) то у камер начинается временами packet loss и судя по диагностики часть трафика уходит на интерфейс WAN1, хотя камеры это WAN2, так же работает со статическим маршрутом, так что пытаемся сделать все без них и dafult gateway -> None
States
LAN_TEST tcp 9x.xx.xxx.xx:XXXX -> 192.168.xx.xxx:XXXXX SYN_SENT:CLOSED 4 / 0 208 B / 0 B
WAN_TEST tcp 9x.xx.xxx.xx:XXXX -> 192.168.xx.xxx:XXXXX (2xx.xxx.xxx.xxx:XXXX) CLOSED:SYN_SENT 4 / 0 208 B / 0 BПостараюсь сделать скрины с настройками что могу
-
@BirBar
Судя по Вашим словам , проброс-то , как раз , работает , не работает ответный трафик от камер
Возможно , что у Вас
часть камер имеет шлюзом по умолчанию шлюз отличный от LAN4 ( таким образом , появляется асимметричная маршрутизация , которая и приводит к таким результатам )Попробуйте сделать так , ради интереса ,
немного поменять вот это правило NATа
В настройках NAT (Firewall-NAT-Outbound) создано правило "Int=LAN 4 source=172.16.0.0/24 destination=any NAT address=адрес интерфейса Провайдер Б"на
Int=LAN 4 source=ANY destination=172.16.0.0/24 NAT address= interface addressтогда камера на любой запрос извне будет отвечать на адрес интерфейса Lan4, а дальше уже PF сам отправит пакет через WAN Б
те , схема должна быть такой
Внешний ip -> WAN Б -> проброс -> NAT (замена адреса источника на ip lAN4) -> камера
и обратно
камера -> Lan 4 ip ( замена адреса назначения) -> WAN Б -> Внешний IPP.S. Вспомнил , у PF была "поломана" функция "reply-to" в похожих с Вашим случаями ( но это не работало на виртуальных интерфейсах)
Если хотите , напишите мне в личку , мне от Вас нужен будет файл на посмотреть / tmp/rules.debug
или выложите его содержимое здесь , удалив конфиденциальную информацию -
@Konstanti said in Проброс портов, не хочет работать:
mp
В общем переустановили PfSense уже начали с нуля и на тестовых интерфейсах, результат тот же
-
@BirBar
Я верно понимаю , что у Вас на интерфейсе bge3 2 ip адреса ххх1 и xxx2?И сейчас указан только 1
Смотрите , в чем странность
Это мое домашнее правило проброса портовpass in quick on $WAN reply-to ( igb0 79.x.x.1 ) inet proto tcp from any to 192.168.1.80 port 80
А у Вас система по какой-то причине создала правило
pass in quick on $WAN_TEST inet proto tcp from any to 192.168.5.14 port 8xxx
Видите разницу ? В моем случае четко указано , куда возвращать пакет , в случае проброса порта , а в Вашем этого не происходит
Возможно , что в этом и кроется проблема
Можно , ради эксперимента, попробовать «ручками» добавить отсутствующий текст в файл /tmp/rules.debug , сохранить его , из консоли перезапустить pf, используя pfctl и конфиг из / tmp и посмотреть , что будет ( заработает или нет ) .pfctl -f /tmp.rules.debug
Но это все до первой перезагрузки
проверьте в настройках , не активирована ли опция Disable reply-to ?
есть ли у Вас шлюз по умолчанию для wan интерфейса ?
у всех внешних ip один шлюз ?
Версия pf какая ? -
@BirBar said in Проброс портов, не хочет работать:
В общем переустановили PfSense уже начали с нуля и на тестовых интерфейсах, результат тот же
debug.txt
Поискал у себя debug.txt.
Нашел только /cf/conf/rules.debug.old
Не там искал? -
@Konstanti
Видимо этот косяк во время первоначальной настройки появился, так как переустанавливали попробовали версию 2.6
На данный момент оставили только 1WAN_test для настройки, задача всё та же осталась
pass in quick on $WAN_TEST reply-to (bge0 xxx.xxx.xxx.xx2 ) inet proto tcp from any to 192.168.5.14 port 8xxx
прописал пытался использовать pfctl -f /tmp.rules.debug, но вылезла системная ошибка ему не понравился синтаксис
в итоге сегодня опять ставим с нуля 2.7.1 попробуем без ошибок всё поднять посмотреть что будет@pigbrother
debug.txt уже я сам создал этот файлик для отправки сюда, копипастой с pfsense
с файла rules.debug -
@BirBar
а как Вы добавляете второй ip ? как алиас ?проверьте в настройках PF, не активирована ли опция Disable Reply-to
-
@Konstanti said in Проброс портов, не хочет работать:
@BirBar
а как Вы добавляете второй ip ? как алиас ?проверьте в настройках PF, не активирована ли опция Disable Reply-to
2ой WAN идет уже как 2ой интерфейс, а на нем уже добавляются Virtual IPs и к ним отдельные Gateway
проверьте в настройках PF, не активирована ли опция Disable Reply-to
настройках галочка не стоит, сложилось впечатление будто опция эта работает, так?
-
@BirBar
Не совсем так
при формировании правила проверяются несколько условий системой ( добавлять эту опцию или нет )судя по всему , при Ваших настройках , какое из правил проверки не выполняется
я вчера специально на тестовую ам добавил ip алиас и создал правила проброса , все сформировалось нормально
нет ничего хуже , чем разбираться в чужом кодеif ($rule['gateway'] == "" && $aline['direction'] <> "" && (interface_has_gateway($rule['interface']) || interface_has_gatewayv6($rule['interface'])) && !config_path_enabled('system','disablereplyto') && !isset($rule['disablereplyto']) && $type != "match") { if ($rule['ipprotocol'] == "inet6") { $rg = get_interface_gateway_v6($rule['interface']); if (is_ipaddrv6($rg)) { $aline['reply'] = "reply-to ( {$ifcfg['ifv6']} {$rg} ) "; } } else { $rg = get_interface_gateway($rule['interface']); if (is_ipaddrv4($rg)) { $aline['reply'] = "reply-to ( {$ifcfg['if']} {$rg} ) "; } } } -
а на нем уже добавляются Virtual IPs и к ним отдельные Gateway
возможно , что именно тут и кроется суть проблемы
Надо смотреть , какие конфиги создаются системой в этом случае, и как отрабатывает ПО PF в этом случае
( может быть это ошибка разработчиков именно для Вашего случая, не знаю)Для анализа , возможно Вам потребуется
1 выгрузить XML файл конфигурации PF
2 посмотреть содержимое файлов папки /tmp/gbe0 (1-2-3__xxxxx
3 и уже смотреть , что делает код PFвозможно , что в Вашем случае нужен другой путь создания необходимой конфигурации ( средствами FreeBsd )
Использовать Netgraph ( встроен в ядро)
На мой взгляд , понадобятся модули
1 ng_ether
2 ng_bridge
3 ng_eiface
Идея состоит в том , чтобы на начальном этапе загрузки PF , выполняется скрипт , который создает несколько виртуальных Ethernet интерфейсов, присваевает им случайные Mac-адреса , и потом присваиваются нужные ip адреса
После загрузки у Вас появляются несколько интерфейсов раздельных с отд ip для каждого , видимых системе , у которого будет свой отдельный gateway
Картинку , как это могло бы выглядеть в теории , скидываю