Проблема с пинг на Inet



  • 1-й раз столкнулся с данной проблемой.

    Есть два провайдера.
    Есть на каждом интерфейсе (для каждого провайдера) правила разрешающие ПИНГ из инета.
    На одном все отвечает, на другом нет
    TCPDUMP дает идентичные картинки
    1)
    [0.0.0-RELEASE][root@pf.garant.khv]/root(5): tcpdump -ni re1_vlan6 host n.n.n and icmp
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on re1_vlan6, link-type EN10MB (Ethernet), capture size 96 bytes
    19:30:58.509679 IP 97.125.117.211 > 146.152.18.206: ICMP echo request, id 1, seq 91, length 40
    19:30:58.509696 IP 146.152.18.206 > 97.125.117.211: ICMP echo reply, id 1, seq 91, length 40
    19:30:59.501207 IP 97.125.117.211 > 146.152.18.206: ICMP echo request, id 1, seq 92, length 40
    19:30:59.501212 IP 146.152.18.206 > 97.125.117.211: ICMP echo reply, id 1, seq 92, length 40
    2)
    [0.0.0-RELEASE][root@pf.garant.khv]/root(6): tcpdump -ni pptp0 host n.n.n and icmp
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on pptp0, link-type NULL (BSD loopback), capture size 96 bytes
    19:38:31.012951 IP 97.125.117.211 > 231.31.91.132: ICMP echo request, id 1, seq 137, length 40
    19:38:31.012967 IP 231.31.91.132 > 97.125.117.211: ICMP echo reply, id 1, seq 137, length 40
    19:38:35.789605 IP 97.125.117.211 > 231.31.91.132: ICMP echo request, id 1, seq 138, length 40
    19:38:35.789621 IP 231.31.91.132 > 97.125.117.211: ICMP echo reply, id 1, seq 138, length 40

    В случае 1) все отвечает
    В случае 1) НЕ отвечает

    В других местах все работает и с тремя провайдерами.
    Может кто-то сталкивался? Или это у провайдера 2) что-то не в порядке



  • Добрый.
    Скрины правил fw на ВАН.
    Возможно, что ваш 2-ой провайдер блокирует icmp.



  • скриншоты лень

    pass  in  quick  on $PPTP_DALTEK inet proto icmp  from any to any keep state

    И еще это все работало в течении лет 5-ти, а тут с неделю ОПА



  • и по скриншотам tcdump
    провайдер никак не блокирует ICMP



  • @vvalexeev:

    скриншоты лень

    Удачи.

    P.s. Совсем офонарели. Помочь пытаешься, а ему лень  >:(



  • Зачем скриншот, если в 4-м посте было написано правило, которое стоит самым первым в списке правил на этом интерфейсе?
    tcpdump в 1-м посте показывает что пакеты приходят и уходят на обоих интерфейсах.
    Или без красивой картинки читать не дано?
    Кстати при подключении вместо pfsense windows пинг работает
    Думается, что это связано с версией pfSense, потому как случилось все это после обновления на др.версию. Просто новый человек решил оказывается обновить.

    Можно еще найти странности в поведении pfsense. Это не хула, а просто констатация факта



  • @vvalexeev:

    Зачем скриншот, если в 4-м посте было написано правило, которое стоит самым первым в списке правил на этом интерфейсе?
    tcpdump в 1-м посте показывает что пакеты приходят и уходят на обоих интерфейсах.
    Или без красивой картинки читать не дано?
    Кстати при подключении вместо pfsense windows пинг работает
    Думается, что это связано с версией pfSense, потому как случилось все это после обновления на др.версию. Просто новый человек решил оказывается обновить.

    Можно еще найти странности в поведении pfsense. Это не хула, а просто констатация факта

    В Windows сетевая подсистема по умолчанию всегда старается отвечать с того интерфейса с которого пришел запрос.
    В pfSense без привязки ответ пойдет по таблице маршрутизации



  • pf всегда отвечает с того же интерфейса на который пришел запрос ( не имеется ввиду NAT)
    Пробросы портов (с 2-мя и более провайдерами), тоже не требуют доп.манипуляций. С какого провайдера придет, через того и уйдет не смотря на табл.маршрутизации. В отличии от iptable, где нужны доп.действия
    Windows всегда отвечает со шлюза по-умолчанию (табл. маршрутизации) по опыту, но попытка использования в качестве маршрутизатора была лет двадцать назад. Не прижилось как раз из-за наличия 3-х провайдеров и путаницы в ответах.



  • В отличии от iptable, где нужны доп.действия

    Аналогично\поэтому в Микротик, например, ответить с интерфейса, на который пришел запрос - относительно нетривиальная задача, хотя iptables там напрямую недоступны.

    Тогда как для pfSense
    Пробросы портов (с 2-мя и более провайдерами), … не требуют доп.манипуляций.
    что очень удобно.



  • Уходим от темы.
    Никто не сталкивался с поведением pfsense, описанным в 1-м и 4-м посте?



  • @vvalexeev:

    Уходим от темы.
    Никто не сталкивался с поведением pfsense, описанным в 1-м и 4-м посте?

    А нечего тут смотреть, у тебя пакет уходит с интерфейса! Следующий рубеж - железяка провайдера. Незнаю, посмотрите логи шлюзов нет ли каких сбоев. пинг в любую сторону не работает? с самого пфсенса и этого интерфейса пинговать пытались?



  • Про провайдера подумал. Убрал pf поставил Windows, все пингуется
    Короче завязываем с темой. Поставил pfSense другой версии, все стало нормально.


Log in to reply