Failover и Port forward есть несколько вопросов.



  • Уважаемые, подскажите кто сталкивался. Есть пограничный pfsense в качесве шлюза с двумя wan от разных провайдеров. Для каждого из них настроен port forward на одну машину внутри сети, порты пробрасываются все 1-65535. Настроен failover и при падении основного канала исходящий траффик уходит по резервному.
    Вопрос в том, как сделать так, чтобы пока не поднялся резервный канал, проброс портов с него на внутреннию машину не работал? Это нужно сделать для того, чтобы траффик приходящий с нескольких машин в инете, которые определяют доступен или нет сервис на 1 или 2 wan-е  корректно проходил. Сейчас можно посылать пакеты на 1 и 2 ван и с обоих он будет успешно форвардится на внутреннюю машину. Может это и не страшно? пусть все время форвардится? Просто я думаю что могут возникнуть различные проблемы, например если пинговать 2 ван то ответ я получаю с 1 ..что не есть правильно..



  • @chillivilli:

    если пинговать 2 ван то ответ я получаю с 1 ..что не есть правильно..

    Это странно, второй ван и должен отвечать.



  • Точно должен отвечать со второго? если да буду копать правила. Просто может быть думал по поводу icmp такая ситуация,  а аказалось что нет, и по http запросам отвечает с первого wan..у кого есть настроенный failover вариант с двумя wan, можете рассказать что у вас в NAT прописано?



  • @chillivilli:

    Точно должен отвечать со второго? если да буду копать правила. Просто может быть думал по поводу icmp такая ситуация,  а аказалось что нет, и по http запросам отвечает с первого wan..у кого есть настроенный failover вариант с двумя wan, можете рассказать что у вас в NAT прописано?

    Здесь, ни правила, ни нат не играют никакой роли. На обоих WAN-интерфейсах есть Default Gateway?



  • Да, у каждого вана свой Дефаулт Гейтвей



  • Можно tcpdump с обоих интерфейсов для пинга на OPT интерфейс? Хочу посмотреть, как приходит по одному, уходит по другому.



  • Может из-за этого?


    Outbound traffic to the Internet

    All services running locally on pfSense will strictly obey the system's routing table. This means they go out the primary WAN unless you have static routes defined that match the traffic. This only applies to services which initiate connections to the Internet, such as the DNS forwarder, and several packages such as squid.

    По крайней мере у меня тоже так. Есть хост в DMZ-LAN с белым IP выданным провайдером подключенным к OPT-WAN. Соответственно, и ходят снаружи на этот хост все через OPT. Но! Если я извне сделаю до него traceroute, то он покажет, что маршрут прошел через WAN т.к. на предпоследнем хопе pfsense генерит ответ destination unreachable от себя, и идет этот ответ через WAN. С провайдером выясняли в свое время почему все так ходит.



  • прошу прощения. но я ошибся.. прсото в тспдампе и на одном и на другом инт-йсе вместо соответсвующего ип адреса всегда писалось имя хоста самого пфсенса, что меня запутало при беглом анализе. При более внимательном изучении выяснилось, что на какой ип пришел пакет icmp запроса, с такого интерфейса и ипа уходит ответ.  Это верно как для самого пфсенса так и для портов прокинутых на внутренние машины. В том числе когда с двух внешних ип адресов прокидывается один и тот же порт на одну внутреннюю машину.



  • @chillivilli:

    При более внимательном изучении выяснилось, что на какой ип пришел пакет icmp запроса, с такого интерфейса и ипа уходит ответ.

    Понятно, значит для пинга заводится state. А с traceroute все сложнее, там же просто UDP пакет прилетает на порт > 30000. Вот и пойми что кто-то маршрут трассирует… Еще раз сейчас проверил, все так как я писал. Так что имейте ввиду.



  • @rubic:

    @chillivilli:

    При более внимательном изучении выяснилось, что на какой ип пришел пакет icmp запроса, с такого интерфейса и ипа уходит ответ.

    Понятно, значит для пинга заводится state. А с traceroute все сложнее, там же просто UDP пакет прилетает на порт > 30000. Вот и пойми что кто-то маршрут трассирует… Еще раз сейчас проверил, все так как я писал. Так что имейте ввиду.

    Вообще говоря, pfSense'у должно быть фиолетово (до некоторой степени) - хоть UDP, хоть ICMP.



  • @Evgeny:

    Вообще говоря, pfSense'у должно быть фиолетово (до некоторой степени) - хоть UDP, хоть ICMP.

    Думаю, не в моем случае. Единственное объяснение, которое я вижу, заключается в том, что:
    на OPT-WAN с удаленного хоста от traceroute приходит UDP пакет с TTL=1 и назначением = хост в DMZ, (пусть заводится state: udp remote host:port -> DMZ host:port), но TTL обнуляется и пакет отбрасывается, после чего pfsense отправляет ICMP type=3 удаленному хосту.
    Так вот, по какой-то причине (может потому, что state убивается вместе с пакетом, или потому, что pfsense игнорирует этот state, считая, что он описывает общение удаленного хоста с хостом в DMZ и к самому pfsense не относится) этот ICMP улетает не с OPT-WAN, а по дефолтному маршруту, т.е. с WAN. И в выводе traceroute мы видим WAN, хотя не видим провайдерского шлюза WAN (напротив видим шлюз OPT-WAN).
    Вот парень мучался пару лет назад: http://forum.pfsense.org/index.php/topic,9171.0.html
    в точности мой сетап, все так и осталось загадкой…



  • @rubic:

    @Evgeny:

    Вообще говоря, pfSense'у должно быть фиолетово (до некоторой степени) - хоть UDP, хоть ICMP.

    Думаю, не в моем случае. Единственное объяснение, которое я вижу, заключается в том, что:
    на OPT-WAN с удаленного хоста от traceroute приходит UDP пакет с TTL=1 и назначением = хост в DMZ, (пусть заводится state: udp remote host:port -> DMZ host:port), но TTL обнуляется и пакет отбрасывается, после чего pfsense отправляет ICMP type=3 удаленному хосту.
    Так вот, по какой-то причине (может потому, что state убивается вместе с пакетом, или потому, что pfsense игнорирует этот state, считая, что он описывает общение удаленного хоста с хостом в DMZ и к самому pfsense не относится) этот ICMP улетает не с OPT-WAN, а по дефолтному маршруту, т.е. с WAN. И в выводе traceroute мы видим WAN, хотя не видим провайдерского шлюза WAN (напротив видим шлюз OPT-WAN).
    Вот парень мучался пару лет назад: http://forum.pfsense.org/index.php/topic,9171.0.html
    в точности мой сетап, все так и осталось загадкой…

    Да, похоже на правду. Суть похоже в том, что ICMP-reply, который отсылается никаким образом не связан с

    пусть заводится state: udp remote host:port -> DMZ host:port

    и посему шлётся согласно таблицы маршрутов. Попробуй на pfSense создай static route на твой удалённый хост через OPT-WAN, должно правильно показать маршрут.



  • Да, конечно, с маршрутом все показывает правильно. Как ты понимаешь, это не выход из положения. Просто будем иметь ввиду, что есть у pfsense такая фича))



  • @rubic:

    Да, конечно, с маршрутом все показывает правильно. Как ты понимаешь, это не выход из положения. Просто будем иметь ввиду, что есть у pfsense такая фича))

    Согласен, но по крайней мере - есть логичное объяснение -)))


Log in to reply