PfSense для средней сети и настройка правил.
-
На сколько я помню раньше доступ на 80/22 порты pfSense был разрешен по умолчанию только для интерфейса LAN, на остальных интерфейсах нужно было разрешать явно. Сейчас разве это не так?
-
Верно, по умолчанию запрещено всё. Но как только делаем "правило разрешение интернета" на этом интерфейсе появляется доступ и к портам 22/80.
-
Верно, по умолчанию запрещено всё. Но как только делаем "правило разрешение интернета" на этом интерфейсе появляется доступ и к портам 22/80.
Ну тогда в чем проблема? Вам подсказать как правильно сделать эти правила? Тогда показывайте, что у Вас есть. Скриншот прикрепляем к посту.
-
Подскажите пожалуйста.
-
Для того, чтобы Ваши юзеры не могли попасть на 80/22 порты pfsense в правиле Destination
должно содержать !адрес_интерфейса(ов)
Для того, чтобы Вы со своего IP адреса могли иметь доступ к pfSense - на Вашем рабочем интерфейсе (к которому подключен Ваш компьютер) первым правилом добавить правило разрешения
Source = ваш IP
Destination = IP адрес интерфейса(ов). -
Таким образом, если будет сотня VLANов, необходимо на каждом интерфейсе прописать сотню правил, запрещающих доступ на $адрес_интерфейса, 22/80?
-
Таким образом, если будет сотня VLANов, необходимо на каждом интерфейсе прописать сотню правил, запрещающих доступ на $адрес_интерфейса, 22/80?
Вы не так поняли. В своем правиле, которое Вы все равно создаете на каждом из интерфейсов,
делайте Destination = !адрес_интерфейса
а не '*' -
dvserg, я Вас понял.
Верно, что при указании Destination = !адрес_интерфейса нет возможности коннекта на этот адрес, но сохраняется возможность подключаться к адресам других интерфейсов. -
dvserg, я Вас понял.
Верно, что при указании Destination = !адрес_интерфейса нет возможности коннекта на этот адрес, но сохраняется возможность подключаться к адресам других интерфейсов.Зависит от доступности из одной локальной подсети в другую. Лучше проверить на рабочем сервере.
-
Зависит от доступности из одной локальной подсети в другую
dvserg, что Вы имеете ввиду?
Лучше проверить на рабочем сервере.
Давайте проверим.
-
Подскажите пожалуйста.
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>
-
Прошу извинить за вопрос не по теме ветки.
Правильно ли я понимаю, что некорректная обработка Disable Negate rules в 2.1.х (с задействованным PBR) вынуждает добавлять на LAN разрешающие правила для доступа к сетям, подключеныых через, например, OVPN?
-
Прошу извинить за вопрос не по теме ветки.
Правильно ли я понимаю, что некорректная обработка Disable Negate rules в 2.1.х (с задействованным PBR) вынуждает добавлять на LAN разрешающие правила для доступа к сетям, подключеныых через, например, OVPN?
Ну да, просто ставите это правило выше PBR и все
-
Прошу извинить за вопрос не по теме ветки.
Правильно ли я понимаю, что некорректная обработка Disable Negate rules в 2.1.х (с задействованным PBR) вынуждает добавлять на LAN разрешающие правила для доступа к сетям, подключенных через, например, OVPN?
Ну да, просто ставите это правило выше PBR и все
Следует ли создавать аналогичное правило на OVPN-клиенте 2.1.х для доступа в сеть за сервером?
Клиент без MultiWan\PBR - это пока. Или стоит его добавить заранее - на перспективу? -
@ pigbrother
А что мешает проверить ? Дело одной минуты.
-
@ pigbrother
А что мешает проверить ? Дело одной минуты.
Клиент и сервер сечас работают в режиме PSK. Я от них далеко, переводить на PKI планирую позже вместе с апгрейдом сервера с 2.0.х до 2.1.3.
Не хочется, чтобы сработала поговорка - "удаленная настройка маршрутизатора - к дальней дороге". -
@ pigbrother
Используйте тот же teamviewer на любой машине и за сервером и за клиентом. Подключайтесь и работайте.
Если имеется белая статика\динамика на клиенте и сервере :
- откройте (временно) в мир веб-интерфейсы на клиенте и сервере (на нестандартных портах + https);
- настройте (временно) и на клиенте и на сервере тот же PPTP VPN.
И работайте в свое удовольствие.
-
Клиент и сервер сечас работают в режиме PSK. Я от них далеко, переводить на PKI планирую позже вместе с апгрейдом сервера с 2.0.х до 2.1.3.
Разработчики планируют допилить 2.2 в течение месяца-полутора даже ценой фич, которые были в планах. Обещают с этого момента идти в ногу с релизами FreeBSD - 2.2 будет на 10-ке, многопоточный PF и все такое вот.
-
@ rubic
Да ? Что-то не верится - https://redmine.pfsense.org/versions/10
Минимум к новому году , а то и в первом квартале 2015.
P.s. Даже ни одной беты не было, только альфы.
-
@ pigbrother
Используйте тот же teamviewer на любой машине и за сервером и за клиентом. Подключайтесь и работайте.
Если имеется белая статика\динамика на клиенте и сервере :
- откройте (временно) в мир веб-интерфейсы на клиенте и сервере (на нестандартных портах + https);
- настройте (временно) и на клиенте и на сервере тот же PPTP VPN.
И работайте в свое удовольствие.
Имеются и белая статика, и PPTP+RDP доступ к серверам за pfSense. Вы меня уже совсем ниже плинтуса опустить хотите.
Но рабочим для удаленного коллектива является именно OVPN-канал, даже короткий простой которого крайне нежелателен.
