Проброс порта в другой PFsens



  • Добрый день.
    Есть сеть из трех шлюзов на пфсенс. настроен ospf. схема включения треугольник.

    Задача. с белого IP шлюза А настроить NAT для экченджа на 443 порт. Который находится за шлюзом С. трафик может идти внутри как А<->С так и А<->В<->С.

    Сломал мозг как это правильно настроить. 0_1551285606311_2019-02-27_19-39-10.jpg



  • @tararashka
    Добрый вечер
    А в чем суть проблемы ?
    Пробрасывается порт , а потом уже маршрутизаторы на основе OSPF сами решат, каким маршрутом пойдет пакет
    По таблице состояний обратно пакет пойдет тем же маршрутом , что и пришел .
    Или я чего-то недопонял ? Речь идет о каком НАТе ? Исходящем или .... ?



  • @konstanti
    нужно чтоб телефоны из интернета по активсинку получали почту.
    в нат правиле дестанейшен указан адрес и порт сервера за пфсенсом С. создается автоматическое правило в фаерволе для входящего трафика. если посмотреть что по этому правилу пролетает в логе то увидим попытки подключений со статусом
    CLOSED:SYN_SENT
    Фаервол между шлюзам сейчас разрешает все. Из лан сетей всех шлюзов можно достучатся до сервера.
    Если делать проверку порта 44 на шлюзе А и WAN интерфейса до локального адреса сервера, то получаем его недоступность. Если это же делать с лан или тунельных интерфейсов то проверка проходит успешно.



  • @tararashka
    Мой Вам совет ,
    начните с packet capture
    Т е начинаем с lan интерфейса маршрутизатора А - ушел пакет или нет , если ушел , то в каком виде , возможно неверно настроен проброс порта, и пакет уходит не на тот порт сервера , который нужен
    и так по всей цепочке A->C в первую очередь ( потому что пакет все-таки пойдет по этому маршруту с высокой степенью вероятности )
    Дальше интерфейс WAN С - смотрим есть/нет прием/ответ на пакет .
    Lan C есть ли ответ на пакет
    Ищем то место , где пакеты теряются
    А вот потом уже , можно будет понимать , что и как



  • @tararashka
    Или , как вариант , сделайте правило Nat outbound для 44 порта на интерфейсах Lan гейтвея A - тогда по сети к серверу будут бегать только пакеты с адресом источника из внутренней сети . И проверьте , будет этот вариант работать или нет



  • @Konstanti
    пакет из интернета через WAN шлюза А долетает успешно натируемый (почтовик получает пакет с интернет адресом телефона) до сервера и тот его выпуливает видимо по дефолтгетевую на тот самый интернет адрес телефона.
    Потому что на шлюзе А есть только входящие пакеты от телефона.

    Как объяснить серверу что его нужно пульнуть обратно на шлюз А? я так понял что Nat outbound только для подсетей. а стандартный Nat Port Forward с лан интрефеса и адреса сервера на адрес шлюза А результата не дает



  • @tararashka
    Те Вы тактично умолчали , что есть еще один шлюз ????? Используйте NAT Outbound на гейтвее А для порта 44 ( интерфейсы Lan ) и будет Вам счастье . Тогда почтовик будет пулять пакеты обратно в ту сеть , откуда они пришли.

    те схема будет такой ( лень писать пришлю скрин со своих настроек IPtables , тут все так же )
    0_1551291186023_1649275c-1672-4a08-946b-bcf18cc4e521-image.png

    Первая строка - проброс
    Вторая - исходящий нат на внутреннем интерфейсе



  • @konstanti said in Проброс порта в другой PFsens:

    лю скрин со своих настроек IPtables , тут все так же )

    я вроде даже картинку приложил. там все шлюзы через которые может пойти трафик от белого адреса до почтового сервера. Если не затруднит ткните носом в мануал по исходящему нату. я рыл в эту сторону, но или уже совсем дурак или что то от усталости со мной происходит.
    верно ли я понимаю что мне нужно указать в исходящем нате в Source адрес сервреа/32 (адресом сервера)? и в Destination локальный адрез шлюза А/32



  • @tararashka
    и тот его выпуливает видимо по дефолтгетевую на тот самый интернет адрес телефона. - по-другому я бы такой текст не смог бы понять , кроме как что есть еще один гейтвей у почтовика , куда он и выпуливает пакеты для внешних сетей .
    По таблицам состояний этот пакет должен вернуться к А без проблем. Если только у С нет второго выхода в интернет и связки С-А и B-C - не виртуальные каналы

    0_1551292605210_d40d3539-7312-4839-9cd1-cd1462ff1fb0-image.png



  • @konstanti said in Проброс порта в другой PFsens:

    и тот его выпуливает видимо по дефолтгетевую на тот самый интернет адрес телефона

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

    что то магия не происходит. Огромно спасибо. Что то в голове стало укладываться. завтра продолжу



  • @tararashka
    А канал c-a и с-b виртуальный ?????????

    По таблицам состояний этот пакет должен вернуться к А без проблем. Если только у С нет второго выхода в интернет и связки С-А и B-C - не виртуальные каналы - такая схема без исходящего нат и не будет работать .

    Все надо мониторить tcpdump-ом



  • @konstanti
    С-А С-В А-В это Овпн тунели пир ту пир. которые объявлены в OSPF. с локальных интервейсов все маршруты работают. У всех шлюзов есть свой выход в интернет.
    WAN A-C- (Почтовый сервер) пакет пролетает судя по Packet Capture и почтовик его отдает на адрес телефона. 0_1551295127595_30cfce58-4a1a-44b3-a769-e2b2340e4688-image.png



  • @tararashka
    Итак , могу диагноз поставить
    при такой конфигурации маршрутA->C->Сервер->C->A при внешнем адресе работать не БУДЕТ
    Тоже самое со схемой через B
    Варианты решения
    1 если почтовику не важен внешний IP - то NAT OUTBOUND на А ( на обоих OPENVPN интерфейсах)

    2 DDNS на роутере С ( если важно знать внешний IP) и доступ через C напрямую

    Если что-то не так , используйте Packet Capture
    На выходе с А ( интерф Openvpn) Вы должны увидеть
    IP openvpn интерф ( src) -> ip почтовика (dst)



  • @konstanti
    я наверное задам глупый вопрос.
    почему NAT OUTBOUND делать роутере на А? задача именно в том чтоб почтовик выходил через адрес роутера А.
    связка почтовик <> роутер С имеет склонность к миграции. и нужен механизм чтоб не зависимо от место положения почта продолжала работать через ip роутера А

    собественно к глупому вопросу. мне NAT OUTBOUND нужно делать разве не на роутере С? где красные стрелки? ведь именно там пакет улетает не ту сторону.

    0_1551337225393_65da5b78-1fd4-4204-8b45-605e56c93999-image.png

    Сейчас пакет летит так. Причем входящий пакет видно и на ovpn A-C со стороны рутера С и на порту WAN C в Packet Capture
    0_1551337335576_9d42b2cb-8bbb-435c-8409-f4622ce44179-image.png

    в конкретно данном случае от WAN C я мог бы отказаться, но у меня нет уверенности что через пол года в нем не появится необходимость. Хотелось бы собрать уже готовую рабочую среду.

    на самом деле схема включения мне кажется достаточно стантдартная для средних компаний, а решений и мануалов я как то я не нашел на эту тему..



  • @tararashka
    Про вариант С ничего сказать не могу , не проверял . Схема с вариантом А рабочая (NAT OUTBOUND для OpenVPN интерфейсов A). Как ее организовать присылал картинку , только вместо Lan указываете нужный интерфейс Openvpn ( делается это в раздел Manual outbound NAT - тут создается это правило .)
    И все будет работать -мой почтовик именно так и работает
    Посмотрите настройки IPTables
    (DNAT - проброс, SNAT - NAT OUTBOUND)
    внешн клиент ->wan (проброс к 1.230)->nat outbound 10.10.100.2->почтовик
    обратно
    почтовик->10.10.100.2->wan->внешн клиент

    Пример получения письма (если смотреть Ваш вариант - роутер А WAN интерфейс)
    17.58.63.184.43701 > 37.153.XXX.XXX.smtp: Flags [S],
    37.153.XXX.XXX.smtp > 17.58.63.184.43701: Flags [S.],

    Роутер А (Openvpn интерфейс)

    10.10.100.2.43701 > 192.168.1.230.25: Flags [S],
    192.168.1.230.25 > 10.10.100.2.43701: Flags [S.],

    Роутер С (lan интерфейс)

    10.10.100.2.43701 > 192.168.1.230.25: Flags [S],
    192.168.1.230.25 > 10.10.100.2.43701: Flags [S.],



  • @tararashka а интересный, чёрт возьми, "крокодил" получается...
    А вот если пакеты ещё и через B перекидывать надо? WAN, я так понимаю там есть, что мешает резерв сделать?

    @tararashka said in Проброс порта в другой PFsens:

    на самом деле схема включения мне кажется достаточно стантдартная для средних компаний, а решений и мануалов я как то я не нашел на эту тему..

    Вот и я про то же, вроде кругом типовые задачи, а как копнешь - так и тупик. Насколько раздули тему, когда надо было офисы связать через OpenVPN. А ложка-то оказалось, что надо всего-лишь OpenVPN самому себе обратку дать.


Log in to reply