» pfSense межсетевой экран

Luckas

Цитата:

КМК, здесь какая-то неувязочка, ведь на 2.1 эти же пакеты работают, при чём весьма не плохо

Взгляни на описание обновлений для 2.2:2.1 - PHP 5.3, FastCGI, FreeBSD 8.3;
2.2 - PHP 5.5, PHP-FPM, FreeBSD 10.1;

Цитата:

Могли бы выкинуть из списка доступных пакетов не рабочие в 2.2

Хорошо написаные пакеты должны быть устойчивы к этим обновлениям, но людям свойственно ошибаться, поэтому далеко не все пакеты хорошо написаны.

Цитата:

Я вообще команду не сильно понимаю: они жутко торопились выпустить релиз в январе любыми средствами.

С другой стороны, пока нет новой версии, то и пакеты почти никто тестировать, а тем более исправлять не будет. Мало кому охота делать двойную работу.

Цитата:

С другой стороны, пока нет новой версии, то и пакеты почти никто тестировать, а тем более исправлять не будет. Мало кому охота делать двойную работу.

Насколько я понимаю, пекеджи можно было начать портировать на 2.2 с первого снапшота с релизной 10-ой фряхой (работа пекеджей на 99% завязана на совместимость с ОС нежели с новым PHP-FPM), т.е. начать в начале ноября, но этого сделано не было .. несмотря на то, что пекеджами занимаются совсем другие люди, но не во всех случаях.

Поэтому не в релизе дело, а в чём-то другом. Могу предположить, что все силы были брошены на релиз 2.2. Плюс ко всему, какой-то неизвестный форк сабжа с новым webgui сильно взволновал местный форумный контингент и команда в срочном порядке изучает возможность смены webgui в 2.3.

Крашится v2.2 при попытке сконфигурировать pppoe сервер на WAN интерфейсе после применения изменений в вебинтерфейсе (жмак на кнопочку apply). Причем крашится знатно, несколько экранов белиберды в консоли и перезагрузка. Больше не поднимается, после прохода fsck в синглюзермоде и подмены config.xml из бекапа в /cf/conf/backup на заведомо рабочий даже вебсервер не взлетает.

5 лет всё жужжало на v.1.2.3.

В багзилле ничего похожего не увидел, Вот это - несколько не то, к поднятию pppoe сервера на WAN интерфейсе отношения не имеет https://redmine.pfsense.org/issues/1696

У кого-нибудь воспроизводится?

nestormahno

Цитата:

Крашится v2.2

2.2 сыровата, ставь v2.15 брать Ссылка.

Цитата:

Плюс ко всему, какой-то неизвестный форк сабжа с новым webgui сильно взволновал местный форумный контингент

плз чуть поподробнее.
ну и ссылку можно, чтоб их форум не перекапывать.

видимо это https://opnsense.org/about/about-opnsense/

Цитата:

видимо это https://opnsense.org/about/about-opnsense/

Абсолютно верно. Это OPNsense.

Они сейчас весьма активно рефакторят код, заодно и рефакторят архитектуру.

Что мне нравится, так это наличие роадмапа. Команда хоть что-то планирует в отличии pfSense.

По моему продукт законченный. Как гайка.

что там можно планировать? сделать семигранную гайку? уже есть микротик


в opnsense сделали уё## ужасную вебморду с расплывающимися буквами. да еще и тормозящую на том же железе, где pfsense работает без нареканий. зачем?

Цитата:

2.2 сыровата, ставь v2.15 брать Ссылка.

Воспроизводится и на 2.15, архитектура I86. Кто-нибудь хочет проверить, "уронить" своего подопытного кролика? Всего-то добавить pppoe сервер на WAN. Надо бы тикет в багтрекере открыть, но ...


Добавлено:
Eternal_Shield

Цитата:

Я на 2.2 с первого снапшота и коммитил багфиксы в master бранч

Просьба в нескольких предложениях отписать процедуру оформления бага в https://redmine.pfsense.org/projects/pfsense/issues?

Что нужно представить туда для.

StanislawK

Цитата:

что там можно планировать?  сделать семигранную гайку? уже есть микротик

У pfsense тонны проблем .. и это мягко выражаясь.

Сколько они делали 2.2? Более 2(!) лет. Причём конкретики от команды слышно не было. А что если проект сдох? Вы что, будете судорожно искать замену, когда таки это станет известно?

Вот чтобы этого не было, нужен роадмап и официальное слово.

Для меня важно: будет ли проект развиваться или нет. Роадмап для меня означает, что БАГИ будут исправляться.

Что касается RouterOS, то она больно деревянная. Да, фич много, аж глаза разбегаются ... а как начнёшь что-то конкретное делать: фиг вам.

Вменяемого DNS сервера нет, openvpn транспорт токмо TCP, гуй на 10 порядков более невменяем pfSense'a, поддержка железа весьма посредственная. Если вас будут бомбить, вы даже не поймёте кто и откуда, а уж breach в жизни не найдёте, ибо информативности у системы НЕТ.

А Snort где? IPS без магии не запустить ...

Добавлено:
nestormahno
1. Чётко сформулировать проблему в сабже. Например: PPPoE Server on PPPoE WAN interface hangups the box;
2. В описании надо указать конфигурацию коробки со всей необходимой информацией (если требуют шаги воспроизведения) и шагами для воспроизведения бага. Например:
Цитата:

Setup:
1. pfSense 2.2 x86.
2. WAN interface (PPPoE).

Steps to reproduce:
1. Turn on a PPPoE server on WAN interface.

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

2. В категории указать область бага. В вашем случае: PPPoE Server;
3. В affected version указать версию сабжа с багом. В вашем случае, скорее всего, будет All;
4. Прочие поля не трогать;
5. Если есть логи, то добавить их в Files. Это будет большим плюсом;

Eternal_Shield

Цитата:

Сколько они делали 2.2? Более 2(!) лет. Причём конкретики от команды слышно не было. А что если проект сдох? Вы что, будете судорожно искать замену, когда таки это станет известно?

Если проект сдохнет, уже установленные системы внезапно сломаются, или будут работать как прежде?

Могли и не делать 2.2. Меня 2.0 полностью устраивал, и 1.2.3 тоже устраивал (и до сих пор трудится в дальнем офисе).

из дальнейшего развития, если и хочется, то поддержки нового железа. а новое железо появляется крайне редко.


Цитата:

Что касается RouterOS, то она больно деревянная.

я и говорю - семигранная гайка с левой резьбой.

Цитата:

Если проект сдохнет, уже установленные системы внезапно сломаются, или будут работать как прежде?

Перечислять критичные уязвимости, о которых стало известно за последние пару лет не хочется, вы о них и сами, наверняка, знаете. На циску и джуниперы с хуайвеями (прости,
Господи) во всяких ГУП и ФГБУЗ денег нет и не будет, продолжим сидеть на самосборе из омна и палок.

Eternal_Shield

спасибо за толчок в нужном направлении. Постараюсь найти время, точнее локализовать проблему. Как выясняется, она зависит от "фазы луны", т.е. последовательности настройки конфигурации pfsense. Если первым после назначения интерфейсов настроить pppoe сервер на WAN, то дальше уже ничего не валится. Чудны дела твои...

Возникла необходимость поднять bind.
Поставил то что предлагали.
Наткнулся на , даже не знаю что это, грабли или косяк какой.
Пишу руками конфиги - работает, но недостаток что слетают при старт стоп.
Причем заметил в таком только виде
pfsense IN A ....... (точки нет после pfsense)
Если она есть - не работает.
Пишу средствами вэб морды - все тоже самое - не работают. Причем точка (pfsense. IN A ...) там есть, убираю ее руками - не помогает, все равно ни dig ни host и т.д. не показывают ничего.
И в том и в другом случае, не работают записи зон ....in-addr-arpa для всех кроме 127й. Естественно собственный DNS Resolver - отключен при этом.
Кому-то удалось настроить?

Цитата:

даже не знаю что это, грабли или косяк какой

ставил однажды в качестве познавания.
снес прямо сразу после установки.
причины сноса даже не отложились в голове.
по всей видимости это какое-то взрывоопасное гуано, которое не настраивается и не управляется..
..ну не зря же я его снес.

Добавлено:
а нет! в теме про программные маршрутизаторы я писал другое.
думаю, что администрирование dns построено не лучше, чем администрирование dhcp

sky418
В чём конкретно проблема то? Я так и не понял.

У меня BIND уже более года крутится и всё отлично работает.

MAGNet

Цитата:

по всей видимости это какое-то взрывоопасное гуано, которое не настраивается и не управляется..
..ну не зря же я его снес.

Вы просто не смогли правильно приготовить сабж. На самом деле, всё легко настраивается. Причём настраивается как душе угодно.

Цитата:

У меня BIND уже более года крутится и всё отлично работает.

А вот теперь мне не понятно, что у вас работает.
Если разговор о доступе в интернет - то здесь да, все работает, но это не все функции, которыми и ради которых я поднимаю bind. Собственно для этого его и поднимать особо не надо.
Ни одна доменная запись зоны, кроме localhost, вообще не воспринимается.
К примеру (все не расписываю, кратко)

@ IN NS TRATA.TA
@ IN A 10.10.10.10
MX ..........
##### in-addr-arpa ####
IN NS TRATA.TA
1 IN PRT gw.
Ну и Т.Д
Так вот:
Если из внутренней сети, или даже с самого pfsense пробуешь любую команду по проверки зон, то они отрабатывают с нулевым результатом.
При ответе от bind(a) все А записи пусты, а уж об обратной и речи не идет. Единственный запрос правильно отрабатываемый, это запрос к зоне localhost но запрос к его ....addr-arpa не отрабатывает .
Естественно никакого обратного общения с DHCP не идет тоже.
А все запросы на интернет ресурсы отрабатывают без проблем, но это с таким же успехом работает и без bind.
Надеюсь не сумбурно объясняю.

sky418

Цитата:

А вот теперь мне не понятно, что у вас работает.

[more]
вы пошутили - мы тоде посмеялись.

[/more]

Значит так. Едем по пунктам:
1. Надо создать ACL для целевой подсети. В нашем пример пусть будет имя vlan1 и подсеть 10.10.10/24;
2. Теперь создаём view для acl vlan1. recursion yes. match-clients vlan1. allow-recursion vlan1;
3. Создаём зону:
Zone name: tratata.ta
view: vlan1
name server: ns.tratata.ta
base domain ip: 10.10.10.10
mail admin zone: mega.uber.admin
allow query: vlan1
ns in a 10.10.10.10

всё работает. поздравляю.

с реверсом тоже всё ппц как просто.

Спасибо, попробую. Сейчас нет возможности.
По моему у меня все так же, только кажется я не обратил внимание на разницу имен с ACL

sky418

Цитата:

По моему у меня все так же, только кажется я не обратил внимание на разницу имен с ACL

Имена могут быть какие угодно. Это неважно. Важно чтобы всё остальное правильно настроено было.

Eternal_Shield
Спасибо, сменил any на конкретный ACL и прямые зоны заработали с реверсом пока грабли, буду перепроверять.
PS
Все разобрался, Огромное спасибо.

Кто-нибудь может поделиться "производительностью" данного решения?
Меня пока просто интересует нагрузка l2tp (или pptp) на процессор. Желательно, конечно, с тарифом 100мбит или больше

m0nty2k5
Без использования AES-NI/QuickAssist на проце Intel Atom C2758:


Тут нет l2tp, но думаю цифр выше хватит, чтобы примерно оценить производительность именно pfSense 2.2.

Отправил в баг-трекер описание проблемы, изложенное на прошлой странице.
https://redmine.pfsense.org/issues/4510

подтвердили проблему, воркараунда не предлагают. Указывают что на интерфейсе, который выходит в интернеты по PPPoE не надобно поднимать еще такой-же сервер. Однако...
Я пять лет этим пользовался, считал что у pfsense это вполне штатная фича.
Тогда же я договорился с техподдержкой провайдера, что они не будут возражать против поднятия пппое сервера с конкретным name в их сети для доступа в локалку больнички из территориально разнесенных кабинетов. И как теперь выкручиваться - поднимать pppoe на каком-то из OPT интерфейсов и физически подключать его (параллелить) к WAN?
Сетевик из меня нулевой...

Добавлено:
вопрос - чем и как парсится XML-ный конфиг файл для создания конфигурационных файлов демонов на этапе загрузки pfsense и на стадиях настройки в ГУЕ? Это описано где-нибудь в документации, на сабжевом форуме? К несчастью во фре я совсем нулёвый, хочется хоть как-то подступиться к локализации проблемы.

nestormahno
Это часто встречающаяся проблема с PPPoE.
Самое лучшее - использовать OpenVPN.

StanislawK

А чем IPSec плох? У меня он работает уже несколько лет и исправно.
OpenVPN нет ни в цисках, ни в зюкселях с длинками, ни в большинстве других железок. При возникновении необходимости подружить pfsense по vpn site-to-site с ними возникает нюанс...

При чем тут IPSec? вопрос был про PPPoE, который используется обычно для удаленных мобильных клиентов. Сейчас OpenVPN есть для всех таких платформ.

vpn site-to-site работает хорошо. без нюансов и неожиданностей.

Аргумент про железки - вообще не понятен.

Во первых я не запрещаю использовать IPSec, а только рекомендую OpenVPN как наиболее распространенный и легко администрируемый централизованно.

Во вторых, несколько не правильно доказывать неправильность метода, аргументируя отсутствием его поддержки например в принтере или хабе.

[more] StanislawK
Из моей практики, обычно для удаленных мобильных клиентов использовались pptp/l2tp(с или без ipsec), поддержка которых присутствует в 99% ОСей "из коробки" (десктоп/мобайл) Т.е. никакого софта дополнительно устанавливать не нужно. Да и с провайдерами ни о чем договариваться не нужно.

Аргумент про железки был именно на тему vpn site-to-site, и выбор пал на IPsec, как на наиболее распространенное решение, в т.ч. и в аппаратных шлюзах. Ведь никогда не известно, когда начальство поставит задачу связать сеть с таким-то филиалом, в котором используется что-нибудь железное и брендовое. Далеко не факт, что в нем найдется модуль openVPN.


Цитата:

Самое лучшее - использовать OpenVPN.

Очень любопытно, а чем оно "самое" то? Факты?


Цитата:

рекомендую OpenVPN как наиболее распространенный и легко администрируемый централизованно

Опять же, факты?

Не подумайте, что я пытаюсь тут всем "продать" IPSec. Просто очень любопытно, чем же OpenVPN лучше всех??? [/more]

StanislawK

Цитата:

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

PPPoE работает на канальном уровне в широковещательном ETHERNET-сегменте, с удаленными мобильными клиентами это вы погорячились!

Кто-нибудь пробовал настраивать обмен настройками?

Angel_19
Нет. А что это и для чего оно нужно?