Зашёл через консоль и сделал ребут системы. Web -интерфейс заработал корректно.

@danilov

1 используйте отдельное правило исходящего NAT для хоста 192.168.40.250 и порта 12426 (оно должно быть выше остальных) -> используйте статический порт (static port)
Для примера ( Вам надо заполнить свои данные ip и порт согласно Ваших хотелок)

da3d284f-a871-4dfb-bbb2-e21f8f392d7b-image.png

2 писал выше уже ( проброс портов)

@Konstanti
Спасибо большое, я прописывал и ранее как вы указали, но нужно было переконектить сетевую карту, и теперь все заработало.

Добрый
@rline
Для zbx на пф есть пакет точно. Как по др системам - хз.

@DIMADUR
Разбиратайтесь снова с микротиком ( настройки , статические маршруты и тд и тп ) пакетов в туннеле от Микротика нет

Добрый
@Mad-Axell
Как указали выше - 2 и 3 правила не нужны.
Loadbalance и так будет отрабатывать в случае падения одного из линков - в настройках LB есть пункт Member down.
Тут работает принцип ИЛИ: или балансировка или failover.
Можете сами проверить это выдергиванием линков по очереди.

@JonathanLee
Read this article. everything is written down there.
https://osbsd.com/vosstanovlenie-sbros-parolya-pfsense.html

@tty1

У меня более 10 pfSense в разных местах работают без этой галки, с подобным поведением первый случай.
Можете объяснить причину такого поведения, опираясь на трафик и детальные логи unbound?

1 Потому что БЕЗ этой галки ваш пф будет пользовать КОРНЕВЫЕ днс, а не те, что вы указали в настройках.

2 НЕ ИСПОЛЬЗОВАТЬ гуглоднс - к ним завтра доступ прикроют и останетесь без инета. Для конторы хватит и я-днс.

@Lares Добрый день! Можно закрывать тему. Я разобрался. У меня на компе какая-то гадость частично блокировала работу COM-порта. С другого компа установка прошла на 5+, всё работает, все счастливы.

@DIMADUR

Здравствуйте
Не совсем понял , зачем в такой схеме проброс портов ?

Насколько я вижу , Вам надо просто правильно настроить статические маршруты ,
1 чтобы 10.x.x.1 знал о том , что сеть 10.168.1.0/24 находится за шлюзом .10.x.x.2
2 чтобы 10.x.x.2 знал о том , что сеть 10.168.45.0/24 находится за шлюзом .10.x.x.1

Добрый.
@danilov
В правилах fw на ВАН создайте правило для нужного IP + галку на Логирование поставьте. И после в Логах смотрите.
Есть еще доп. пакет ntopng https://osbsd.com/ustanavlivaem-ntopng-dlya-monitoring-trafika-v-kompyuternoj-seti-na-pfsense.html

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

@tty1 said in Не работает AirPrint между VLAN (Avahi):

Правда только один из трех почему-то

Всё дело оказалось в домене home.arpa, который по умолчанию pfSense присваивал принтерам через DHCP (а на том принтере, с которого печать работала домен .local был указан вручную).
Решение: в настройках DHCP для VLAN с принтерами указал домен local, все принтеры сразу стали находиться.

@BirBar

а на нем уже добавляются Virtual IPs и к ним отдельные Gateway

возможно , что именно тут и кроется суть проблемы
Надо смотреть , какие конфиги создаются системой в этом случае, и как отрабатывает ПО PF в этом случае
( может быть это ошибка разработчиков именно для Вашего случая, не знаю)

Для анализа , возможно Вам потребуется
1 выгрузить XML файл конфигурации PF
2 посмотреть содержимое файлов папки /tmp/gbe0 (1-2-3__xxxxx
3 и уже смотреть , что делает код PF

возможно , что в Вашем случае нужен другой путь создания необходимой конфигурации ( средствами FreeBsd )
Использовать Netgraph ( встроен в ядро)
На мой взгляд , понадобятся модули
1 ng_ether
2 ng_bridge
3 ng_eiface
Идея состоит в том , чтобы на начальном этапе загрузки PF , выполняется скрипт , который создает несколько виртуальных Ethernet интерфейсов, присваевает им случайные Mac-адреса , и потом присваиваются нужные ip адреса
После загрузки у Вас появляются несколько интерфейсов раздельных с отд ip для каждого , видимых системе , у которого будет свой отдельный gateway
Картинку , как это могло бы выглядеть в теории , скидываю

97e6bb79-642b-4e5b-88f7-54e87ff509c5-image.png

@Tim2000
Откройте тем, кому надо. Не мучайтесь.

Нашел время для решения этой проблемы.
На путь истинный натолкнула ветка англоязычного форума https://forum.netgate.com/topic/183033/static-routes-ignored-in-2-7-0/17

Если коротко, то проблема в автоматических правилах NAT.

По настройкам:

В шлюзах прописываем оба шлюза (в моем примере это 100.0.0.1 и 100.0.0.10 ) В стат маршрутах прописываем статические маршруты (у меня сеть 100.0.1.0/24 доступна через шлюз 10.0.0.10) Шлюз по умолчанию назначаем основной шлюз. (у меня 100.0.0.1) Прописываем правила для LAN интерфейса (в моем примере разрешаю подсети 192.168.0.0/24 ходить через шлюз по умолчанию, а подсети 192.168.1.0/24 задаю выходной шлюз 100.0.0.10) В правилах исходящего NAT переводим из авто или гибрида в ручное. В настройках интерфейса WAN шлюз IPv4 - ничего.

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

PS всем добра!

Всем спасибо - разобрался - некоторые записи Client Identifier были на русском языке)))

@tty1

1 ничего советовать тут не могу , и так и этак пробовал , отличий особых не нашел , как создавались дубли фазы-2 , так и создаются ( пришлось своим путем идти неформальным) . тут дело не в инициаторе соединения , а кто инициирует обновление ключей .

2 тоже не вижу проблем в том , кто первый пакет отправит (см настройки фазы-1 (responder only)

Responder Only Enable this option to never initiate this connection from this side, only respond to incoming requests.

3 Поставьте уровень логгирования Silent и будет заказчику счастье

@pigbrother на версии PF 2.7.0 - не помогло.

@Hitch
Здравствуйте

Как я уже писал ранее , проблема в том , что PF работает чуть выше уровнем , чем Вам надо (см статью в этой ветке порядок прохождения пакетов )
Если все-таки надо фильтровать на уровне канальном с анализом Ethernet заголовка и именно на PF , то я бы решал эту проблему через Netgraph ( но в лоб ее не решить , нужно приложить некие усилия )
Суть в том , что эта подсистема позволяет перехватывать и анализировать трафик именно в том момент , когда он передается от драйвера адаптера к ядру системы и наоборот
Таким образом , можно отсеивать пакеты с неразрешенными Mac- адресами и пропускать валидные пакеты
Тут есть 2 пути
1 использовать комбинацию модулей ng_ether +ng_bpf
(они уже встроены в ядро PF , и тут надо только написать грамотный скрипт и составить bpf- программу , используя tcpdump)
пример такой программы

printf "Configuring ${INTERFACE}_bpf..." ngctl msg ${INTERFACE}_bpf: setprogram { thisHook=\"${INTERFACE}_to_bpf_from_tee\" \ ifMatch=\"${INTERFACE}_from_bpf_to_one2many\" ifNotMatch=\"drop\" \ bpf_prog_len=19 bpf_prog=[ { code=40 jt=0 jf=0 k=12 } { code=21 jt=16 jf=0 k=34525 } \ { code=21 jt=0 jf=15 k=2048 } { code=48 jt=0 jf=0 k=23 } { code=21 jt=0 jf=13 k=17 } \ { code=40 jt=0 jf=0 k=20 } { code=69 jt=11 jf=0 k=8191 } { code=177 jt=0 jf=0 k=14 } \ { code=72 jt=0 jf=0 k=14 } { code=21 jt=0 jf=8 k=53 } { code=80 jt=0 jf=0 k=24 } \ { code=84 jt=0 jf=0 k=128 } { code=21 jt=0 jf=5 k=128 } { code=32 jt=0 jf=0 k=30 } \ { code=21 jt=2 jf=0 k=3232236006 } { code=84 jt=0 jf=0 k=4294967264 } \ { code=21 jt=0 jf=1 k=3232235808 } { code=6 jt=0 jf=0 k=65535 } { code=6 jt=0 jf=0 k=0 } ] } printf "OK! \n"

2 использовать комбинацию модулей ng_ether + ng_macfilter
тут все несколько отличается от пути 1 и конфигурируется тоже легче , НО тк модуль ng_macfilter не интегрирован в ядро PF , то
его придется отдельно собирать под конкретную версию Freebsd
https://www.gsp.com/cgi-bin/man.cgi?section=4&topic=NG_MACFILTER

https://github.com/freebsd/freebsd-src/blob/main/sys/netgraph/ng_macfilter.c

посмотреть , с какими модулями собрано ядро можно командой
kldstat -v | grep ng_

Добрый
@GOOFY
ПРОКИДЫВАТЬ сетевую в ВМ НЕ НАДО.
Надо создать на ней БРИДЖ в гипере и после ОТДАТЬ этот бридж в ВМ.