PfSense для средней сети и настройка правил.



  • Добрый день!
    Коллеги, планирую развернуть pfSense для сети ~100 абонентов (на пике 50mbit download). Схема простая - два аплинка, статически смаршрутизированы ip-адреса. До каждого абонента VLAN. На pfSense будет работать DNS Forwarder, 70% абонентов будут отначиваться. У меня возникают два вопроса:

    1. Справится ли с такой нагрузкой pfSense? CPU: Xeon 2.33GHz; Ram 512 mb; NIC bge;

    2. Как красиво создать правила для запрета http, ssh из внутренней сети?
      Дело в том, что действия по созданию и удалению VLAN'ов происходят достаточно часто и использовать Floating Rules, в котором выбирать все интерфейсы, кроме админского и указывать что им запрещено обращаться к http, ssh не очень хороший вариант. Опять же, даже при использовании Floating Rues не ясно как указать запрет доступа ко всем айпи-адресам маршрутизатора не создавая сотню правил (Я имею ввиду то, что создавая VLAN и присваивая ему ип адрес, на нем начинает работать http, ssh, ибо *:80 *:22)

    Пока только такие мысли на счет правил:
    На каждом интерфейсе сделать так:
    (sorry for ipfw syntaxis)

    
    deny ip from $interface_net to me 22,80 in recv $int
    allow udp from $interface_net to me 53 in recv $int
    allow all from any to not me via $int
    
    

    Хотя в идеале надо сделать одно правило такого вида:

    
    deny ip from any to me 22,80
    
    

    и разрешить доступ на эти порты только из админской сети.

    Либо повесить ssh, http на конкретные айпишники из админсокго VLAN'а



  • Добрый день.

    Думаю желательно увеличить память до гигабайта.
    При составлении правил воспользуйтесь возможностями Alias для группировки IP/портов. Это должно обеспечить более простой вид правил и более простое изменение списков IP/портов в группах через добавление/удаление из через алиасы.



  • @Rearden:

    1. Как красиво создать правила для запрета http, ssh из внутренней сети?

    Посмотрите подобное (гтовое) решение обсуждаемое на форуме
    http://www.thin.kiev.ua/router-os/50-pfsense/589-pfsense-20-nat.html

    обсуждение тут
    https://forum.pfsense.org/index.php/topic,47168.0.html

    Возможно найдете рациональное зерно.



  • Господа, спасибо за ответы!

    dr.gopher, на данный момент это не то, что требуется. За ссылки спасибо, это определенно пригодится в дальнейшем.

    Возможно я не совсем корректно выразился на счет блокирования 22,80. Имеется ввиду, что закрыть эти порты чтобы клиенты не имели доступ к портам конфигурирования роутера.

    По умолчанию, при создании VLAN и создании интерфейса, в разделе Firewall/Rules появляется закладка с именем интерфейса, в которой нету правил (запрещено всё). Для того, чтобы работал интернет (НАТ у нас уже настроен) в этом VLAN необходимо прописать правило "Allow on $INTERFACE, source $INTERFACE_NET, dest any, port range other".

    Соответственно появляется доступ к портам, на которых весит ssh, http-конфигуратор pfSense.

    Подскажите пожалуйста, как сделать следующие правила:

    1). "Разрешить доступ на порты 22,80 только на интерфейсе $MANAGEMENT_VLAN и только с $MANAGEMENT_ADDRESS."
    и
    2). "Запретить доступ на $ALL_ROUTER_ADDRESS порты 22,80 на всех VLAN."
    По умолчанию, каждый новый VLAN должен попадать под второе правило.



  • На сколько я помню раньше доступ на 80/22 порты pfSense был разрешен по умолчанию только для интерфейса LAN, на остальных интерфейсах нужно было разрешать явно. Сейчас разве это не так?



  • Верно, по умолчанию запрещено всё. Но как только делаем "правило разрешение интернета" на этом интерфейсе появляется доступ и к портам 22/80.



  • @Rearden:

    Верно, по умолчанию запрещено всё. Но как только делаем "правило разрешение интернета" на этом интерфейсе появляется доступ и к портам 22/80.

    Ну тогда в чем проблема? Вам подсказать как правильно сделать эти правила? Тогда показывайте, что у Вас есть. Скриншот прикрепляем к посту.



  • Подскажите пожалуйста.




  • Для того, чтобы Ваши юзеры не могли попасть на 80/22 порты pfsense в правиле Destination
    должно содержать !адрес_интерфейса(ов)
    Для того, чтобы Вы со своего IP адреса могли иметь доступ к pfSense - на Вашем рабочем интерфейсе (к которому подключен Ваш компьютер) первым правилом добавить правило разрешения
    Source = ваш IP
    Destination = IP адрес интерфейса(ов).



  • Таким образом, если будет сотня VLANов, необходимо на каждом интерфейсе прописать сотню правил, запрещающих доступ на $адрес_интерфейса, 22/80?



  • @Rearden:

    Таким образом, если будет сотня VLANов, необходимо на каждом интерфейсе прописать сотню правил, запрещающих доступ на $адрес_интерфейса, 22/80?

    Вы не так поняли. В своем правиле, которое Вы все равно создаете на каждом из интерфейсов,
    делайте Destination = !адрес_интерфейса
    а не '*'



  • dvserg, я Вас понял.
    Верно, что при указании Destination = !адрес_интерфейса нет возможности коннекта на этот адрес, но сохраняется возможность подключаться к адресам других интерфейсов.



  • @Rearden:

    dvserg, я Вас понял.
    Верно, что при указании Destination = !адрес_интерфейса нет возможности коннекта на этот адрес, но сохраняется возможность подключаться к адресам других интерфейсов.

    Зависит от доступности из одной локальной подсети в другую. Лучше проверить на рабочем сервере.



  • Зависит от доступности из одной локальной подсети в другую

    dvserg, что Вы имеете ввиду?

    Лучше проверить на рабочем сервере.

    Давайте проверим.



  • @Rearden:

    Подскажите пожалуйста.

    @Rearden:

    dvserg, я Вас понял.
    Верно, что при указании Destination = !адрес_интерфейса нет возможности коннекта на этот адрес, но сохраняется возможность подключаться к адресам других интерфейсов.

    В pfSense 2.1.x правило, где явно указан gateway, не пропустит такого подключения, а вот без gateway - пожалуйта. "Weak End System Model" со всеми вытекающими.
    Для сведения, в pfSense есть специальная скрытая таблица (алиас со списком IP/mask) <negate_networks>, где прописаны все сети, подключенные к системе. Если в System: Advanced: Firewall and NAT снят флажок "Disable Negate rules" (по умолчанию снят), то перед каждым правилом, где явно указан gateway (policy based routing - PBR), создается скрытое правило разрешающее доступ в эти сети (<negate_networks>).
    В pfSense 2.1.x в отличие от 2.0.x таблица <negate_networks>не заполняется и, таким образом, эти правила не работают. Доступа в подключенные сети (и на адреса других интерфейсов pfSense) через правило PBR нет. Скорее всего это просто баг, т.к. в современной версии руководства раздел про Negate Rules присутствует (могут и исправить).

    Я лично стараюсь избегать штуковин, которые за сценой что-то делают "для моего же блага". Поэтому флажок System: Advanced: Firewall and NAT -> Disable Negate rules у меня установлен и с правилом подобным вашему я в домике)</negate_networks></negate_networks></negate_networks>



  • @rubic

    Прошу извинить за вопрос не по теме ветки.

    Правильно ли я понимаю, что некорректная обработка  Disable Negate rules в 2.1.х (с задействованным PBR) вынуждает добавлять на LAN разрешающие правила для доступа к сетям, подключеныых через, например, OVPN?



  • @pigbrother:

    @rubic

    Прошу извинить за вопрос не по теме ветки.

    Правильно ли я понимаю, что некорректная обработка  Disable Negate rules в 2.1.х (с задействованным PBR) вынуждает добавлять на LAN разрешающие правила для доступа к сетям, подключеныых через, например, OVPN?

    Ну да, просто ставите это правило выше PBR и все



  • @rubic:

    @pigbrother:

    @rubic

    Прошу извинить за вопрос не по теме ветки.

    Правильно ли я понимаю, что некорректная обработка  Disable Negate rules в 2.1.х (с задействованным PBR) вынуждает добавлять на LAN разрешающие правила для доступа к сетям, подключенных через, например, OVPN?

    Ну да, просто ставите это правило выше PBR и все

    Следует ли создавать аналогичное правило на OVPN-клиенте 2.1.х для доступа в сеть за сервером?
    Клиент без MultiWan\PBR - это пока. Или стоит его добавить заранее - на перспективу?



  • @ pigbrother

    А что мешает проверить ? Дело одной минуты.



  • @werter:

    @ pigbrother

    А что мешает проверить ? Дело одной минуты.

    Клиент и сервер сечас работают в режиме PSK. Я от них далеко, переводить на PKI планирую позже вместе с апгрейдом сервера с 2.0.х  до 2.1.3.
    Не хочется, чтобы сработала поговорка - "удаленная настройка маршрутизатора - к дальней дороге".



  • @ pigbrother

    Используйте тот же teamviewer на любой машине и за сервером и за клиентом. Подключайтесь и работайте.

    Если имеется белая статика\динамика на клиенте и сервере :

    • откройте (временно) в мир веб-интерфейсы на клиенте и сервере (на нестандартных портах + https);
    • настройте (временно) и на клиенте и на сервере тот же PPTP VPN.

    И работайте в свое удовольствие.



  • @pigbrother:

    Клиент и сервер сечас работают в режиме PSK. Я от них далеко, переводить на PKI планирую позже вместе с апгрейдом сервера с 2.0.х  до 2.1.3.

    Разработчики планируют допилить 2.2 в течение месяца-полутора даже ценой фич, которые были в планах. Обещают с этого момента идти в ногу с релизами FreeBSD - 2.2 будет на 10-ке, многопоточный PF и все такое вот.



  • @ rubic

    Да ? Что-то не верится - https://redmine.pfsense.org/versions/10

    Минимум к новому году , а то и в первом квартале 2015.

    P.s. Даже ни одной беты не было, только альфы.



  • @werter:

    @ pigbrother

    Используйте тот же teamviewer на любой машине и за сервером и за клиентом. Подключайтесь и работайте.

    Если имеется белая статика\динамика на клиенте и сервере :

    • откройте (временно) в мир веб-интерфейсы на клиенте и сервере (на нестандартных портах + https);
    • настройте (временно) и на клиенте и на сервере тот же PPTP VPN.

    И работайте в свое удовольствие.

    Имеются и белая статика, и PPTP+RDP доступ к серверам за pfSense. Вы меня уже совсем ниже плинтуса опустить хотите.
    Но рабочим для удаленного коллектива является именно OVPN-канал, даже  короткий простой которого крайне нежелателен.



  • …Вы меня уже совсем ниже плинтуса опустить хотите

    Ни в коем случае  ;) Я про такое даже не думал - просто предложил варианты.



  • @rubic:

    @pigbrother:

    Клиент и сервер сечас работают в режиме PSK. Я от них далеко, переводить на PKI планирую позже вместе с апгрейдом сервера с 2.0.х  до 2.1.3.

    Разработчики планируют допилить 2.2 в течение месяца-полутора даже ценой фич, которые были в планах. Обещают с этого момента идти в ногу с релизами FreeBSD - 2.2 будет на 10-ке, многопоточный PF и все такое вот.

    А не повысятся ли с переходом на 10-ку системные требования pfSense?
    Для самой OC декларируются те же
    486 or better PC, 64 MB or more of RAM, and at least 1.1 GB of hard disk space.

    А в реальности? Да еще если установка будет по умолчанию на ZFS?



  • @werter:

    @ rubic

    Да ? Что-то не верится - https://redmine.pfsense.org/versions/10

    Минимум к новому году , а то и в первом квартале 2015.

    P.s. Даже ни одной беты не было, только альфы.

    Так говорят)

    https://forum.pfsense.org/index.php?topic=73517.msg406539#msg406539
    https://forum.pfsense.org/index.php?topic=73281.msg414107#msg414107
    https://forum.pfsense.org/index.php?topic=76612.msg419935#msg419935



  • @rubic:

    В pfSense 2.1.x в отличие от 2.0.x таблица <negate_networks>не заполняется и, таким образом, эти правила не работают. Доступа в подключенные сети (и на адреса других интерфейсов pfSense) через правило PBR нет. Скорее всего это просто баг, т.к. в современной версии руководства раздел про Negate Rules присутствует (могут и исправить).</negate_networks>

    Похоже все-таки не баг, а фича: https://github.com/pfsense/pfsense/commit/b4227df690fb7a989ead9b3928ebaaaa34b495eb - только сети OpenVPN клиентов попадают в <negate_networks>@pigbrother:

    Правильно ли я понимаю, что некорректная обработка  Disable Negate rules в 2.1.х (с задействованным PBR) вынуждает добавлять на LAN разрешающие правила для доступа к сетям, подключеныых через, например, OVPN?

    Ну, как видим, нет - не нужны такие правила для сетей подключенных через OpenVPN. Нужно только иметь ввиду, что сети OpenVPN клиентов попадают в таблицу <negate_networks>лишь тогда, когда они перечисленны через запятую в поле "Remote networks" OpenVPN сервера, а не заданы директивами "route…" в Advanced configuration.
    https://forum.pfsense.org/index.php?topic=66776.msg377169#msg377169</negate_networks></negate_networks>



  • @rubic

    то сети OpenVPN клиентов попадают в таблицу лишь тогда, когда они перечисленны через >запятую в поле "Remote networks" OpenVPN сервера,
    1.Тогда получается, что использовать многократно рекомендуемый режим сервера Remote Access не выйдет - в его настройках нет поля Remote networks, а использовать Peer tо Peer SSL/TLS?
    2. Как быть с <negate_networks>на клиентах, получающих, например, push "route…." из Client Specific Override сервера? Заполнять IPv4 Remote Network/s на клиенте?</negate_networks>



  • @pigbrother:

    1.Тогда получается, что использовать многократно рекомендуемый режим сервера Remote Access не выйдет - в его настройках нет поля Remote networks, а использовать Peer tо Peer SSL/TLS?

    Да. Ведь Remote Access - это по определению для одиночных клиентов, за которыми нет сетей. Можно конечно добиться, чтобы и с сетями работало, но если клиент позволяет подключиться в режиме Peer tо Peer SSL/TLS, то зачем?

    2. Как быть с <negate_networks>на клиентах, получающих, например, push "route…." из Client Specific Override сервера? Заполнять IPv4 Remote Network/s на клиенте?</negate_networks>

    Не знаю, нужно пробовать. По мне так проще руками сделать аналог negate rule чем надеяться на этот скрытый механизм, который еще и меняется в самый неудобный момент.



  • По мне так проще руками сделать аналог negate rule чем надеяться на этот скрытый механизм, который еще и меняется в самый неудобный момент.

    Да, изменения произошли внезапно, но хуже, что при обновлении настройки  не переносятся из  Advanced configuration в Remote networks.

    Прочитал  :) комментарии к настройке поля Remote networks. Они честно отличаются:

    Для 2.0.х

    This is a network that will be routed through the tunnel, so that a site-to-site VPN can be established without manually changing the routing tables. Expressed as a CIDR range. If this is a site-to-site VPN, enter here the remote LAN here…

    Для 2.1.2:
    These are the IPv4 networkS that will be routed through the tunnel, so that a site-to-site VPN can be established without manually changing the routing tables. Expressed as a comma-separated list of one or more CIDR ranges. If this is a site-to-site VPN, enter the remote LAN/s here….

    Если можно - подробнее про самостоятельное создание аналога negate rule.

    По поводу negate_networks> на клиентах. Проверил на  2.1.2
    В tmp/rules.debug
    table <vpn_networks>и table <negate_networks>Создаются\заполняются только при создании сервера, но не клиента OVPN.</negate_networks></vpn_networks>



  • @pigbrother:

    Прочитал  :) комментарии к настройке поля Remote networks. Они честно отличаются:

    Для 2.0.х

    This is a network that will be routed through the tunnel, so that a site-to-site VPN can be established without manually changing the routing tables. Expressed as a CIDR range. If this is a site-to-site VPN, enter here the remote LAN here…

    Для 2.1.2:
    These are the IPv4 networkS that will be routed through the tunnel, so that a site-to-site VPN can be established without manually changing the routing tables. Expressed as a comma-separated list of one or more CIDR ranges. If this is a site-to-site VPN, enter the remote LAN/s here….

    Таким образом, теперь нет необходимости прописывать "route…" в Advanced configuration, все сети можно прописать в IPv4 Remote Network/s. То же самое с "push route" - все локальные для сервера сети можно прописать в IPv4 Local Network/s.

    Если можно - подробнее про самостоятельное создание аналога negate rule.

    Обратите внимание на следующее: любое policy based routing (PBR) правило направляет трафик в обход системной таблицы маршрутизации, т.е. на этот трафик системные маршруты не действуют, даже если они есть (pf routing: https://forum.pfsense.org/index.php?topic=73670.0). Поэтому, чтобы трафик между сетями подчинялся системным маршрутам, необходимо перед PBR правилом поставить другое - из нужной сети в нужную сеть с gateway = default. Это именно то, что и делают скрытые negate rules - перед каждым PBR правилом разрешают трафик из всех подключенных сетей во все подключенные сети. Очевидно, разработчики пришли к выводу, что это медвежья услуга - лучше, чтобы оператор сам контролировал кого куда пускать.

    По поводу negate_networks> на клиентах. Проверил на  2.1.2
    В tmp/rules.debug
    table <vpn_networks>и table <negate_networks>Создаются\заполняются только при создании сервера, но не клиента OVPN.</negate_networks></vpn_networks>

    А если на клиенте в IPv4 Remote Network/s прописать что-нибудь?



  • я бы посоветовал переназначить порт управления роутером и выключить автоматический редирект в админку. искать специально будут долго.

    а так же как уже выше описали при использовании атрибута Gateway в правиле сети можно исключить попадание клиента в любую сеть кроме внешней.

    так же можно заготовить правило для копирования и просто переносить копию на вновь появившийся интерфейс. для запрета доступа к локальному интерфейсу шлюза.
    допустим прописать его таким образом
    reject
    интерфейс клиента
    протокол any
    сурс эни
    дест интерфейс_адресс

    а в портах прописать алиас портов которые хочется прикрыть 22 80 443 и тд
    днс в таком случае будет ходить



  • Поэтому, чтобы трафик между сетями подчинялся системным маршрутам, необходимо перед PBR правилом поставить другое - из нужной сети в нужную сеть с gateway = default

    То есть то самое правило вида:
    IPv4 * LAN net * remote_network/24 * * none
    Так?

    А если на клиенте в IPv4 Remote Network/s прописать что-нибудь?

    Создал fake-клиента с такими настройками:

    dev ovpnc1
    dev-type tun
    tun-ipv6
    dev-node /dev/tun1
    writepid /var/run/openvpn_client1.pid
    #user nobody
    #group nobody
    script-security 3
    daemon
    keepalive 10 60
    ping-timer-rem
    persist-tun
    persist-key
    proto udp
    cipher AES-128-CBC
    up /usr/local/sbin/ovpn-linkup
    down /usr/local/sbin/ovpn-linkdown
    local 192.168.126.128
    tls-client
    client
    lport 0
    management /var/etc/openvpn/client1.sock unix
    remote 1.2.3.4 1194
    ifconfig 10.0.22.2 10.0.22.1
    route 10.0.0.10 255.255.255.0
    ca /var/etc/openvpn/client1.ca 
    cert /var/etc/openvpn/client1.cert 
    key /var/etc/openvpn/client1.key 
    tls-auth /var/etc/openvpn/client1.tls-auth 1
    

    и в  tmp/rules.debug

    записи появились:

    table <vpn_networks>{ 10.0.0.10/24 10.0.22.0/24 }
    table <negate_networks>{ 10.0.0.10/24 10.0.22.0/24 }

    Какой правильный вывод из этого следут сделать? Обязательно заполнять Remote Network/s и на клиенте?</negate_networks></vpn_networks>



  • Какой правильный вывод из этого следут сделать? Обязательно заполнять Remote Network/s и на клиенте?

    В чем проблема проверить?
    Варианты :

    1. Не указывать. В настройках сервера прописать директиву push "route x.x.x.x y.y.y.y vpn_gateway"; и route … .На клиенте же можно добавить директиву pull (а можно и не добавлять)
    2. В настройках сервера не указывать директиву push …, только route. В настройках клиента прописать директиву route x.x.x.x y.y.y.y vpn_gateway;
    3. Заполнить поле  Remote Network/s на клиенте и route ... на сервере.

    Это основные вар-ты. Существуют еще и подверсии этих же.

    P.s. @ pigbrother

    Какой-то Вы нерешительный, что ли. С одним несчастным ОпенВПН-ом разбираетесь хз сколько времени. Уже давно бы все попробовали и выяснили что для вас подходит\работает.
    Так нет, устроили тут "Твиттер" честное слово : "Прописал строку, удалил строку" и т.д. и т.п.



  • @pigbrother:

    Какой правильный вывод из этого следут сделать? Обязательно заполнять Remote Network/s и на клиенте?

    Не и на клиенте, а только на клиенте, если negate_networks вам так дороги)



  • @werter
    Так нет, устроили тут "Твиттер" честное слово : "Прописал строку, удалил строку" и т.д. и т.п.

    Показалось, что тема negate в деталях интересна не только мне. Если этим отвлек\напряг вас - не обессудьте, старею, наверное.



  • @ pigbrother

    Пардоньте и вы меня, но вот сложилось такое впечатление.
    P.s. "Не ошибается тот , кто ничего не делает"(с)



  • Коллеги, приветствую!
    Ограничил доступ к ssh,http как показано на скриншоте. На самом деле всё просто - первым правилом разрешается пинговать шлюз, следующим правилом разрешается доступ к локальным ресурсам (на тестовом роутере сделано from $net to $servers any, в идеале надо сделать доступ только к определенным портам, Например from $net to $server 80,25 etc.). Третьим правилом разрешается "выход в интернет" но кроме $local_networks в чей диаппазон и входит адрес конкретного маршрутизатора.

    На данный момент полет нормальный. 18 VLAN'ов. States в среднем 10k (в данный момент 7% (6461/98000)).
    За 37 дней аптайма был следующий глюк - сервер перестал пускать на вэб-интрефейс. Проблема решилась удалением php-sockets из /tmp и рестартом webconfigurator.

    Далее есть непонятка с NetFlow. Сейчас работает softflowd. На самом деле не понятно как работает, ибо в том VLANe на который он натравлен крайне мало netflow трафика (несколько пакетов в 5 минут), соответственно в биллинге не обновляется информация о трафике. Пробовал pfflowd, он генерит больше трафика, но постоянно падает. Так что вопрос о netflow остается открытым. На продакшене сейчас работает через ngctl и правило ipfw add ngtee 5 ip from any to any in.




  • https://forum.pfsense.org/index.php?topic=78224.30

    И да, по первому правилу (сверху вниз) - fw разрешает\запрещает трафик только ко внешним сетям. У вас же правило, к-ое пытается обработать трафик в одной с pfsense сети.
    Толку от него - нуль.

    Поправьте (или проверьте) , если я не прав.


Log in to reply