Messages

Hi all,

I've just upgraded to 26.1 and started looking at the new firewall "Rules [new]" interface and the Migration assistant. My setup is a bit on the complex side and I'd like to get the migration right without breaking anything.

Current setup (high level):

Multiple VLANs, grouped into Internal and Restricted interface groups, using groups as policies and interfaces as zones.

Group sequence is used to enforce "global block policies first, more permissive per‑zone rules later" (e.g. blocks for DNS/NTP/SMTP in Internal, allows in Restricted).

Multi‑layer DNS stack: dnscrypt‑proxy on localhost → Unbound as validating resolver → AdGuard Home on a separate VLAN, now with Q‑Feeds domain/IP feeds integrated into Unbound and firewall aliases.

I've read the docs about the Firewall: Rules → Migration assistant and I understand the general flow:

Take ZFS snapshots / use configuration history as backup.

Export legacy rules as CSV via the migration API.

Inspect/adjust in a spreadsheet if needed.

Import into the new Rules UI and, once confirmed, remove legacy rules.

What I'm interested in is best practices and "gotchas" for setups that rely heavily on:

Interface groups + sequence for policy ordering (Internal / Restricted / IoT / Guest, etc.).

Security zones style design (policies via groups, zones via interfaces).

DNS‑centric controls (Unbound blocklists, Q‑Feeds, AdGuard, per‑VLAN policies).

Concretely:

Does the CSV export/import fully preserve group‑based rules and their evaluation order (especially with different group sequence values), or are there manual adjustments you'd recommend doing after import?

Are there specific fields in the CSV that tend to fail validation or translate poorly into the new UI when using lots of aliases / advanced options (schedules, tags, quick, etc.)?

For people already running 26.1 in production with a similar zone/policy approach: did you migrate everything in one go, or did you do it interface‑by‑interface/groups‑by‑groups and test in between?

Any advice on testing strategy after migration (e.g. particular logs/views in the new UI that helped to quickly confirm rule evaluation order and policy behaviour)?

I've seen the notes about snapshots, configuration history and the anti‑lockout rule, but for those of you with more advanced setups I'd really appreciate any lessons learned or checklists before I press "Remove all legacy rules".

Thanks in advance

In my  setup I combining interface groups as security zones (similar Internal/Restricted model) with a multi‑layer DNS stack (dnscrypt‑proxy on localhost, Unbound as validating resolver and AdGuard Home on a separate VLAN), and we've just added Q‑Feeds domain/IP feeds on top.


Being able to control the group rule order via the sequence field is exactly what we need to keep the "global block policies" applied before the more permissive per‑zone rules without exploding the number of interface rules.

Since the sequence field essentially controls policy precedence between interface groups, it might be worth surfacing this more clearly in the UI and docs.
For example, a short note or tooltip like "lower sequence = evaluated earlier (group rules are ordered by 300000 + sequence)" under Firewall → Groups would make it much easier for people using policy‑style groups (Internal/Restricted, IoT/Guest, etc.) to design their rulesets intentionally instead of discovering the behaviour by trial and error.

Hi all,

after upgrading to OPNsense 26.1 my Unbound + dnscrypt-proxy setup stopped working.

Before the upgrade:

Unbound on OPNsense was configured to forward all queries to dnscrypt-proxy on localhost via a forward-zone in a custom file under /usr/local/etc/unbound.opnsense.d/.

dnscrypt-proxy v2 was running on localhost, listening on a custom port, with a list of resolvers configured in dnscrypt-proxy.toml.

Queries sent to Unbound were answered correctly (NOERROR), and dnscrypt-proxy validated DNSSEC as expected.

After upgrading to 26.1:

dnscrypt-proxy no longer starts:

service dnscrypt-proxy status → "not running".
�

Log shows: [FATAL] No servers configured.

In the active dnscrypt-proxy.toml I noticed that the server_names line had been changed to something like:

text
server_names = ['dnscrypt.eu-nl dnscrypt.eu-dk mullvad-doh mullvad-dot quad9-doh-ip4-only']
i.e. multiple resolver names concatenated into a single string, which makes dnscrypt-proxy fail to load any server and emit the "No servers configured" error.

Unbound is running, but returns SERVFAIL for external domains, since it forwards to dnscrypt-proxy on localhost, which is not actually running.

Temporary manual fixes that work only until reboot:

Manually fixing dnscrypt-proxy.toml:

Rewriting server_names as a proper list,

Making sure listen_addresses points to localhost on the chosen port, etc.

After that, dnscrypt-proxy starts and answers queries on its local port.

Restoring the Unbound → dnscrypt forward:

Keeping a forward-zone pointing to dnscrypt-proxy in a custom file under /usr/local/etc/unbound.opnsense.d/,

Restarting Unbound so that queries go through dnscrypt-proxy again.

This works until the next reboot. After reboot:

dnscrypt-proxy is again "not running",

Unbound still forwards to it, so external queries result in SERVFAIL.

Questions

Is it expected that upgrading to OPNsense 26.1 modifies or resets dnscrypt-proxy.toml in a way that breaks server_names and causes [FATAL] No servers configured?

What is the recommended / supported way in 26.1 to:

keep a local dnscrypt-proxy v2 instance on OPNsense,

have Unbound forward all queries to it via forward-zone,

and ensure that:

dnscrypt-proxy.toml is not overwritten or broken on upgrades,

custom Unbound configuration under /usr/local/etc/unbound.opnsense.d/ is reliably loaded on boot and not ignored after upgrades?

If there is an updated best-practice example (or official doc) for a persistent Unbound + dnscrypt-proxy setup on 26.1, I'd really appreciate a pointer.

Thanks!

I prefer this setup because.Adguard do the filtering for all my vlans for spam and other malware with low cpu usage.

If the rpi breaks, like its happened to me before, I  still have my dns working on all my home net,i just bypass the filtering.

(This is an extra layer because on the top i have Zenarmour running)

Than i manage unbound and dnscrypt with a proper firewall.The flow is perfect, plus my firewall is a bit more powerfull than a rpi.

The RPI is not reliable to run all the vlans DNS, but for the filtering is ok.

This is my thought ,but yes you could do that.

After applying the hotfix 25.7.11_2 my Unbound + dnscrypt-proxy setup is now stable again.
For reference, this is what I did and what is currently working:

Backed up /usr/local/etc/dnscrypt-proxy/dnscrypt-proxy.toml before upgrading, since the plugin/GUI may touch it during upgrades.

Upgraded to 25.7.11_2 from the GUI and rebooted.

Verified that dnscrypt-proxy is running and listening on 127.0.0.1:xxxx:


From a LAN client I ran a DNS leak test (dnsleaktest.com) and only saw the encrypted resolvers configured in dnscrypt-proxy, no ISP DNS leaked.


The important points that made it stable for me:

Keep dnscrypt-proxy.toml under /usr/local/etc/dnscrypt-proxy/ clean and backed up, and avoid unnecessary changes from the GUI plugin if you manage it from the shell.



So far, after the upgrade to 25.7.11_2 and a couple of reboots, Unbound + dnscrypt-proxy continue to work reliably with this setup.



*************************************THANKS OPNSENSE TEAM*************************************************************

Hi all,
after a recent OPNsense upgrade my DNS stack with Unbound and dnscrypt-proxy broke, and I would like to understand what is the correct way to run this combination on current releases.

Setup (before it broke)

OPNsense as main router/firewall

Unbound listening on LAN/VLANs on port 53

dnscrypt-proxy (plugin) listening on 127.0.0.1:xxxx

Unbound forwarding to dnscrypt via custom file:
/var/unbound/etc/dnscrypt.conf:

text
server:
  do-not-query-localhost: no

forward-zone:
  name: "."
  forward-addr: 127.0.0.1@xxxx
AdGuard running on a Raspberry Pi in LAN (some VLANs used it directly, others only via Unbound)

Clients only use the firewall (Unbound) as DNS; dnscrypt and AdGuard are "behind" Unbound, so client-side configuration never changes.


What happened after upgrade

After an OPNsense/Plugin upgrade from 25.7.10 to  25.7.11_1, dnscrypt-proxy plugin installed), the following started to happen:


dnscrypt-proxy often fails to start or exits with:

"No servers configured" or issues with server_names in dnscrypt-proxy.toml

The TOML file appears to be regenerated/modified by the plugin/GUI after upgrades or reboots, even if I only manage it from the shell.

Unbound either:

Does not start, or

Starts but all queries return SERVFAIL for any domain, even though direct tests to public resolvers (1.1.1.1 / 9.9.9.9) work fine from the firewall.

unbound-checkconf /var/unbound/unbound.conf previously reported errors related to Python module / DNSBL and custom fragments, but now the config has been cleaned up and Unbound passes the check. Still, when chained to dnscrypt, resolution randomly breaks.


As a temporary workaround, I had to:

Disable dnscrypt in the chain.

Configure Unbound to forward directly to 1.1.1.1 and 9.9.9.9 (or use "System Nameservers"), so clients could resolve again.


Current behaviour / tests

From OPNsense shell:

service unbound status → service running (when not chained to dnscrypt).

drill @1.1.1.1 google.com and drill @9.9.9.9 google.com → NOERROR with valid IPs.

With Unbound directly forwarding to those public DNS, drill @127.0.0.1 google.com and drill @<LAN_GW_IP> google.com return valid answers.


When I reintroduce the forwarding to dnscrypt via /var/unbound/etc/dnscrypt.conf (127.0.0.1@xxxx):

If dnscrypt-proxy is running and the TOML is clean, the chain works again:

drill @127.0.0.1 -p xxxx google.com → NOERROR

drill @<LAN_GW_IP> google.com → NOERROR (clients → Unbound → dnscrypt → upstream)


But after some upgrades or reboots, dnscrypt-proxy's config is changed/regenerated and Unbound starts failing again (SERVFAIL), unless I manually fix the TOML and/or custom Unbound fragments. This behaviour seems similar to what is described here: "Unbound + Dnscrypt-proxy issue after upgrade to 25.7.11_1".


What I am looking for

Supported way to chain Unbound + dnscrypt-proxy on current OPNsense versions

Is the approach "clients → Unbound (53) → dnscrypt-proxy (127.0.0.1:xxxx)" via custom file in /var/unbound/etc/ still considered valid, or is there now a recommended alternative?


How to prevent plugin/GUI from regenerating dnscrypt-proxy.toml

If I want to manage dnscrypt-proxy only from the console (no GUI), what is the correct way to:

Disable automatic regeneration of dnscrypt-proxy.toml on upgrades/reboots?

Keep my own TOML persistent across firmware/plugin updates?


Best practice for Unbound custom fragments with dnscrypt

Given the changes in ACL handling and the known bug reported for 25.7.11 (duplicate server: clause etc.), what is currently the cleanest way to:

Add the forward-zone to 127.0.0.1@xxxx

Avoid clashes with Unbound's generated config and ACL changes in newer releases?


Logging / diagnostics

Is there a recommended way to make configctl unbound check errors show up clearly in the regular logs (e.g. /var/log/resolver.log), as suggested in the 25.7.11 thread, to make debugging these situations easier?


If needed, I can provide:

Current /usr/local/etc/dnscrypt-proxy/dnscrypt-proxy.toml

unbound-checkconf /var/unbound/unbound.conf output

tail -n 50 /var/log/resolver.log and /var/log/dnscrypt-proxy/dnscrypt-proxy.log

Thanks in advance for any hints or examples of a stable Unbound + dnscrypt-proxy setup on the latest OPNsense versions.

Regards

thats make sense Patrick.

thank you for your explanation,you have solve my problem.

i want to connect from the wireguard instead of the vlan  client to have an extra layer of security.

ok i see, maybe my falt

i need to create an alias for the  client defined in the wireguard vpn peers (ip) instead of the vlan client linux_pc

then i create a rule for wireguard  that allow from source wireguard peer(linux_pc1) destination this firewall

is that will work

i place that rule on vlan network, but on the wireguard rule i need to include also??

if i dont while im connect from the linux_pc vlan with wireguard client i loose connection

or better what rule should i put on wireguard to allow access from linux_pc that use a wireguard client

vlan linux---->linux_pc------->wireguard client linux pc

the linux_pc is the ip address of a machine inside a vlan that connect to the wireguard client

it only work if i set the wireguard firewall rule as

source wireguard net and destination this firewall

which mean the all wireguard vpn have access

when i change the firewall wireguard rule to
source linux_pc and destination this firewall i loose connection with the web gui.

hello Patrick
i have a similar issue with restricting the Gui web access only to a specific client of wireguard
i have create an alias for the machine with a specific ip address
i set listen interface to all

from wireguard theclient allowed ip is  0.0.0.0/0,::/0

from firewall rule i set a rule with allow the source  wireguard net to destination This firewall.


now if i want to limit the access to the firewall to a specific wireguard client i create a nat port forward rule as you suggested.

Firewall: NAT: Port Forward


Interface   Proto         Address                 Ports           Address           Ports                IP                Ports

wireguard   TCP/UDP    Linux_PC       443 (HTTPS)   This Firewall   443(HTTPS)      127.0.0.1         443 (HTTPS)   

is that will work?

thanks i found it.
i found a strange rule set to the floating rule allow anything from anywhere.
i delete this rule now my vlan are isolated.

Thanks for the support Guys

hi viragomann

how i  flush the states in opnsense