"Recent posts
#1
25.7, 25.10 Series / Re: BUSINESS V25.10.1_2 to Ver...
Last post by DEC740airp414user - Today at 12:12:52 PMhad someone previously been changing snapshot settings?
being honest i did something similar, it ended up being i did not understand how snapshots worked. and i rebooted to a previous snapshot without current settings
being honest i did something similar, it ended up being i did not understand how snapshots worked. and i rebooted to a previous snapshot without current settings
#2
German - Deutsch / Re: WireGuard keine Auflösung ...
Last post by diabolo511 - Today at 11:53:51 AMdie Absicht ist es und war es, das meine Firewall den DNS macht.
Laut dem Live Log komm ich auch rein, nur dahinter passiert halt nichts mehr.
Ich bin aktuell noch auf der Arbeit, ich stelle die Bilder später mal rein.
Laut dem Live Log komm ich auch rein, nur dahinter passiert halt nichts mehr.
Ich bin aktuell noch auf der Arbeit, ich stelle die Bilder später mal rein.
#3
General Discussion / Re: Support AmneziaWG
Last post by Patrick M. Hausen - Today at 11:39:26 AMYes, but in which scenario would you legitimately need to punch holes through a firewall that not also asks for anonymity?
#4
25.7, 25.10 Series / Re: BUSINESS V25.10.1_2 to Ver...
Last post by Wuensch-AG-Adm - Today at 11:22:38 AMQuote from: Patrick M. Hausen on February 20, 2026, 08:55:06 AMIf you have evidence that an update really caused the loss of firewall rules, you can still open an issue on Github to reach the developers. My main point is that this is the community forum and although I run a handful of systems with the business edition I do not have the expertise to help you. Also I never experienced anything like that myself.
Side note - why do you need a maintenance window to run an audit?
That's the only time I can devote to it. I take care of many other networks and application infrastructures, and since the problem didn't block the system's communication (I've simply re-create the 4/5 missing rules), I'll take care of it next time.
It's not about the OPNSense-Firewalls, It's about the workflow in the company.
Cheers,
Joel.
#5
General Discussion / Re: Support AmneziaWG
Last post by OPNenthu - Today at 11:20:00 AMMaybe I misinterpreted the link in the OP?
The things it discusses seem to have more to do with punching through for access purposes (avoiding VPN blocks) rather than anonymity. Tor is solving a different problem, no?
The things it discusses seem to have more to do with punching through for access purposes (avoiding VPN blocks) rather than anonymity. Tor is solving a different problem, no?
#6
General Discussion / Re: sophos utm9 migration to O...
Last post by Monviech (Cedrik) - Today at 10:52:13 AMDoesn't matter that much. You can use NAT and just bind to random ports no other service uses.
That way you let PF decide which interface can forward traffic to the webserver.
It's always better to bind to the ANY interface since the service will always reliably start.
That way you let PF decide which interface can forward traffic to the webserver.
It's always better to bind to the ANY interface since the service will always reliably start.
#7
General Discussion / Re: Support AmneziaWG
Last post by bimbar - Today at 10:47:33 AMI also don't see the point. If you need obfuscated internet access for legitimate reasons, you'd better use TOR.
#8
General Discussion / Re: sophos utm9 migration to O...
Last post by bimbar - Today at 10:44:18 AMQuote from: Monviech (Cedrik) on February 21, 2026, 10:34:52 PMJust fyi:
https://docs.opnsense.org/vendor/deciso/opnwaf.html
It's almost the same apache configuration and web application features as in UTM, and we support it fully in business support (if you ever need it).
If you want to stay mostly in community scope HA proxy is also fine.
For that to be useful, it would need to be capable of binding to a specific IP:port of the device, not only a port on all IPs.
#9
Russian - Русский / Проброс сети WireGuard
Last post by Al-x - Today at 10:31:29 AMДобрый день!
Прошу помощи, в вопросе. Уровень знаний ближе к начальному, но и не первый день разбираюсь с вопросом.
Есть роутер Keenetic с белым IP, установлен, условно, сервер Wireguard. К нему удалённо подключается WireGuard на OPNsense. Версия OPNsense - 26.1.2_5, последняя.
Настройки WG OPN: Allowed IP: 0.0.0.0/0, Disable routes = вкл, Gateway=172.16.6.1.
В настройках создан интерфейс WG (всё по умолчанию), Dynamic gateway policy откл.
В настройках шлюзов так же создан шлюз WG_GW c IP 172.16.6.1 с автоматической проверкой доступности шлюза.
В статических маршрутах есть такой маршрут: сеть 192.168.0.0 шлюз WG_GW (172.16.6.1).
Конфигурация сети: локальная сеть Keenetic (192.168.0.0), локальная сеть OPNsense (192.168.10.0), сеть WG (172.16.6.0).
Теперь по проблеме.
Если клиент из сети Keenetic, допустим, 192.168.0.100 обращается по адресу 192.168.10.100, то всё нормально, он получает ответ.
А вот если клиент из сети Keenetic заходит в эту сеть из вне через переадресацию портов, например: 123.456.789.10:80 (Keenetic NAT 192.168.10.100:80), то на стороне OPNsense пакет доходит до 192.168.10.100:80, формируется ответ и уходит в интерфейс WAN вместо WG.
Если бы адреса выхода были фиксированы и я мог бы создать статический маршрут, то проблемы бы не было, но это невозможно по следующим причинам. 1. соврешенно не хочется, чтобы выход в интернет был через WG. 2. Если я сделаю статический маршрут 0.0.0.0/0 - шлюз WG_GW (172.16.6.1), то поначалу всё работает (даже если смириться с неудобством пункта 1), но после отвала связи - WG не может переподключиться, потому что он ищет соединение в отвалившемся шлюзе.
Для эксперимента, но это не цель, создано правило IN - LAN - Src: Lan Net, Dest: !LAN net - GW - WG_GW. (я опущу тот нюанс, что создана группа шлюзов с контролем отвала, сейчас это не имеет значения.) И даже тут всё работает - клиенты полностью уходят в WG. Но вот как перенаправить туда ответный пакет - я хоть убей не пойму. Какие правила только не создавал, включал/отключал SNAT по сетям - не помогает: интерфейс WG не подменяет адрес источника. Адрес источника всегда тот, что был у клиента. Понимаю, что у идеале SNAT должен был бы делать Keenetic, но тоже глухо - пакет отправляется в тунель с адресом источника точки выхода клиента.
С настройками Disable routes = вкл, Gateway=172.16.6.1 я тоже игрался, не помогло. Я предполагал, что Disable routes = вкл может отменять некоторые действия правил, но в итоге никакой разницы не увидел применительно к пути возврата пакета. Если мне память не изменяет, то при отключенной опции маршрут 0.0.0.0/0 - шлюз WG_GW создаётся автоматически.
Относительно того, что я пробовал - признаюсь - немного плаваю в вопросе, но я пробовал делать как вхлодящие, так и исходящие правила в LAN, чтобы все пакеты от нужного клиента шли в шлюз WG, но ещё раз повторюсь - это срабатывало только на запросах, которые формирует сам клиент. А вот его ответы всегда идут в WAN.
Прошу помощи, в вопросе. Уровень знаний ближе к начальному, но и не первый день разбираюсь с вопросом.
Есть роутер Keenetic с белым IP, установлен, условно, сервер Wireguard. К нему удалённо подключается WireGuard на OPNsense. Версия OPNsense - 26.1.2_5, последняя.
Настройки WG OPN: Allowed IP: 0.0.0.0/0, Disable routes = вкл, Gateway=172.16.6.1.
В настройках создан интерфейс WG (всё по умолчанию), Dynamic gateway policy откл.
В настройках шлюзов так же создан шлюз WG_GW c IP 172.16.6.1 с автоматической проверкой доступности шлюза.
В статических маршрутах есть такой маршрут: сеть 192.168.0.0 шлюз WG_GW (172.16.6.1).
Конфигурация сети: локальная сеть Keenetic (192.168.0.0), локальная сеть OPNsense (192.168.10.0), сеть WG (172.16.6.0).
Теперь по проблеме.
Если клиент из сети Keenetic, допустим, 192.168.0.100 обращается по адресу 192.168.10.100, то всё нормально, он получает ответ.
А вот если клиент из сети Keenetic заходит в эту сеть из вне через переадресацию портов, например: 123.456.789.10:80 (Keenetic NAT 192.168.10.100:80), то на стороне OPNsense пакет доходит до 192.168.10.100:80, формируется ответ и уходит в интерфейс WAN вместо WG.
Если бы адреса выхода были фиксированы и я мог бы создать статический маршрут, то проблемы бы не было, но это невозможно по следующим причинам. 1. соврешенно не хочется, чтобы выход в интернет был через WG. 2. Если я сделаю статический маршрут 0.0.0.0/0 - шлюз WG_GW (172.16.6.1), то поначалу всё работает (даже если смириться с неудобством пункта 1), но после отвала связи - WG не может переподключиться, потому что он ищет соединение в отвалившемся шлюзе.
Для эксперимента, но это не цель, создано правило IN - LAN - Src: Lan Net, Dest: !LAN net - GW - WG_GW. (я опущу тот нюанс, что создана группа шлюзов с контролем отвала, сейчас это не имеет значения.) И даже тут всё работает - клиенты полностью уходят в WG. Но вот как перенаправить туда ответный пакет - я хоть убей не пойму. Какие правила только не создавал, включал/отключал SNAT по сетям - не помогает: интерфейс WG не подменяет адрес источника. Адрес источника всегда тот, что был у клиента. Понимаю, что у идеале SNAT должен был бы делать Keenetic, но тоже глухо - пакет отправляется в тунель с адресом источника точки выхода клиента.
С настройками Disable routes = вкл, Gateway=172.16.6.1 я тоже игрался, не помогло. Я предполагал, что Disable routes = вкл может отменять некоторые действия правил, но в итоге никакой разницы не увидел применительно к пути возврата пакета. Если мне память не изменяет, то при отключенной опции маршрут 0.0.0.0/0 - шлюз WG_GW создаётся автоматически.
Относительно того, что я пробовал - признаюсь - немного плаваю в вопросе, но я пробовал делать как вхлодящие, так и исходящие правила в LAN, чтобы все пакеты от нужного клиента шли в шлюз WG, но ещё раз повторюсь - это срабатывало только на запросах, которые формирует сам клиент. А вот его ответы всегда идут в WAN.
#10
26.1 Series / firewall needs reboot to handl...
Last post by bongo - Today at 06:33:14 AMthis is an issue, i identified for the 1st time a few months ago on 25.7.xx, but it did not solve with 26.1.
i use ISC DHCPv4 to provide IP addresses to devices in my local networks.
once a device has attached for the 1st time, it gets an IP from the pool. as pool IPs are configured in my setup for minimum rights, this is only temporary then.
as soon as i see the MAC of the new device in OPNsense, i configure it to a static IP, to add it to the appropriate group, to define its access rights to internet and other local networks, handled by OPNsense. this also allows me to access the device (expecially for IoT stuff) by IP.
all i need to do to get things working is disconnect/reconnect the device, so that it gets its configured IP address.
this has worked fine like this for years now.
for a few months now, i recognized that, when i detach/attach a device to get it working, it gets the new IP as expected, but it is shown as inactive in the leases.
and although the firewall is configured for this IP, i get no data through.
whatever i try, it still shows as inactive.
i'm not 100% sure, but it looks like for some reason, the device is not added to the arp list.
the only solution i found so far (after a few hours of analyzing the problem) is to reboot opnsense. after a reboot, it all works fine.
it looks to me like this issue has started with one of the updates for 25.7.
i actually use OPNsense 26.1.2-amd64 which still shows this issue.
any idea what's going wrong?
regards
bongo
i use ISC DHCPv4 to provide IP addresses to devices in my local networks.
once a device has attached for the 1st time, it gets an IP from the pool. as pool IPs are configured in my setup for minimum rights, this is only temporary then.
as soon as i see the MAC of the new device in OPNsense, i configure it to a static IP, to add it to the appropriate group, to define its access rights to internet and other local networks, handled by OPNsense. this also allows me to access the device (expecially for IoT stuff) by IP.
all i need to do to get things working is disconnect/reconnect the device, so that it gets its configured IP address.
this has worked fine like this for years now.
for a few months now, i recognized that, when i detach/attach a device to get it working, it gets the new IP as expected, but it is shown as inactive in the leases.
and although the firewall is configured for this IP, i get no data through.
whatever i try, it still shows as inactive.
i'm not 100% sure, but it looks like for some reason, the device is not added to the arp list.
the only solution i found so far (after a few hours of analyzing the problem) is to reboot opnsense. after a reboot, it all works fine.
it looks to me like this issue has started with one of the updates for 25.7.
i actually use OPNsense 26.1.2-amd64 which still shows this issue.
any idea what's going wrong?
regards
bongo
