BUG! bogon vs. filter.inc (RFC6598)



  • 2.2-RELEASE (i386) и ранее: есть серьезная ошибка в файле /etc/inc/filter.inc, не позволяющая клиентам из сети вашего же провайдера подключаться к вашим серверами за pfSense даже при снятом флажке Interfaces - WAN/DMZ - Block bogon networks!

    Ситуация возникает, если ваш провайдер (как Ростелеком, например) использует сеть:

    100.64.0.0/10    100.64.0.0–100.127.255.255  Used for communications between a Service Provider and its subscribers when using a Carrier-grade NAT, as specified by RFC 6598. (из https://forum.pfsense.org/index.php?topic=67194.0)

    Проверка на наличие бага через ssh shell:  pfctl -s rules | grep "100.64" выдает что-то типа

    block drop in log quick on rl0 inet from 100.64.0.0/10 to any label "Block private networks from WAN block 100.64/10"

    Ключевое слово здесь "private" - но данная сеть не относится к приватным по RFC 1918! Это "серая" сеть для ISP по RFC 6598, и пакет из этой сети может придти к вам на WAN интерфейс из сети провайдера и причем он будет абсолютно легальным смаршрутизированным без выхода в Интернет пакетом от клиента (DSL пользователь, например, в случае Ростелекома). Адрес этой сети заботливо придет к вам от files.pfsense.org в таблицу "bogons" (Diagnostics - Tables). Причем обновление таблицы "bogons" отключить из web-интерфейса pfSense нельзя. Для разрешения пакетов в Interfaces cнимаем флажок "Block bogon networks", делаем перезагрузку pf фильтра Status - Filter Reload, проверяем снова в ssh  shell: pfctl -s rules | grep "100.64" - правило блокировки никуда не делось! Через pfctl удалять правило из текущего состояния смысла никакого нет, после перезагрузки оно появится снова. Смотрим cat /etc/inc/filter.inc | grep "100.64" и видим такую строчку:

    block in $privnetlog quick on ${$oc['descr']} from 100.64.0.0/10 to any tracker {$increment_tracker($tracker)} label "{$fix_rule_label("Block private networks from {$oc['descr']} block 100.64/10")}"

    • вот этой строчки здесь вообще не должно быть, без нее включение/выключение блокировки "Block bogon networks" из web-интерфейса будет работать как положено по смыслу.

    Временное решение - сделать резервную копию (cp filter.inc filter.0.inc), закомментировать в ssh shell с помощью vi эту строчку в filter.inc

    vi filter.inc
    / 100.64
    i

    <escape>:wq

    и сделать перезагрузку pf фильтра. После перезагрузки шлюза pfSense это исправление должно остаться (до обновления firmware по-крайней мере).

    P.S.: Честно говоря, это конкретная подстава со стороны разработчиков.
    P.P.S.: Чтоб не извращаться с vi, кто-нибудь знает как поставить mc в pfSense 2.2? (в 2.1 известно, загрузкой с инета)</escape>



  • P.P.S.: Чтоб не извращаться с vi, кто-нибудь знает как поставить mc в pfSense 2.2? (в 2.1 известно, загрузкой с инета)

    А чем плох встроенный редактор:

    Diagnostics: Edit file



  • Diagnostics: Edit file

    Круто! :) Не знал… Спасибо!



  • total commander + sftp plugin



  • @derwin:

    total commander + sftp plugin

    до кучи
    http://winscp.net/eng/docs/lang:ru



  • странно, в свежем FAR в бывшем ftp плагине (теперь NetBox называется) есть поддержка SCP, но не смог он подключиться к pfSense 2.2…



  • @paulroot:

    странно, в свежем FAR в бывшем ftp плагине (теперь NetBox называется) есть поддержка SCP, но не смог он подключиться к pfSense 2.2…

    SSH в pfSense включен?



  • @pigbrother:

    SSH в pfSense включен?

    Да, конечно. Захожу по ssh иногда. По SFTP из FAR NetBox тоже вылетает (говорит что-то про большой объем данных, идущих от  pfSense).



  • Промежуточный результат обсуждения с разработчиками (ветка https://forum.pfsense.org/index.php?topic=88215.0):
    сказали, что сеть 100.64.0.0/10 будет исключена из автоматически обновляемого файла /etc/bogons (Should be removed from there - https://redmine.pfsense.org/issues/4379)


Log in to reply