Recent posts

#81

25.7, 25.10 Series / Re: New site PPPoE PMTU woes

Last post by ToasterPC - Today at 12:05:01 AM

Hey, thanks for the help!

I would first try if the MTU size is the culprit first (it may also be HTTP/2 over UDP). Use the utility from this post: https://forum.opnsense.org/index.php?topic=45658.0 to find if the 1500 byte MTU is valid from your OpnSenses.

After using the mtu_freebsd.sh script on both sites inside their respective OPNsense VMs, the following results came out:

Known working site:

Code Select Expand

sudo ifconfig
pppoe0: flags=10088d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1492
        description: WAN (wan)
        options=0
        inet REDACTED --> REDACTED netmask 0xffffffff
        inet6 fe80::1%pppoe0 prefixlen 64 scopeid 0x27
        inet6 fc00:1020:25:28e7::1 prefixlen 64 autoconf pltime 604800 vltime 2592000
        nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
sudo ./mtu_freebsd.sh 1.1.1.1
Maximum MTU size: 45580
Current site:

Code Select Expand

sudo ifconfig
pppoe0: flags=10088d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1492
        description: WAN_FTTH (wan)
        options=100000<NETMAP>
        inet REDACTED --> REDACTED netmask 0xffffffff
        inet6 fe80::1%pppoe0 prefixlen 64 scopeid 0x7
        inet6 fc00:1020:27:5359::1 prefixlen 64 autoconf pltime 604800 vltime 2592000
        nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>

sudo ./mtu_freebsd.sh 1.1.1.1
Maximum MTU: 25060
As for the points you mentioned in the article, I believe I might be doing things properly

P.S.: I skip all of the obvious problems, like Realtek adapters, Proxmox underneath with mini jumbo frames, etc. Most of that is covered in the linked article and this one: https://forum.opnsense.org/index.php?topic=44159.0

In the following screenshot, the WAN bridge interfaces for both sites are shown (left is the current one, and right is the currently working example):

And in this one, the LAN bridge interfaces with the same order:

The VLAN tag is being applied at the Proxmox level, and not within OPNsense itself, yet under these conditions only the older site is able to reliably connect to the Internet. The only other thing that comes to mind as a difference is that the older site needs me to reload the WAN interface in order to be able to complete the PPPoE handshake, while the new one will achieve so without manual intervention.

I'm uncertain if that could point to a bigger problem, but aside from that the next steps remain clouded for me.

What else should I keep an eye out for?

#82

25.7, 25.10 Series / Re: clarification of snapshots

Last post by Patrick M. Hausen - Today at 12:04:26 AM

Yes, but Proxmox VM snapshots are not ZFS snapshots. ZFS is not even mandatory for Proxmox.

#83

25.7, 25.10 Series / Re: What is the official migra...

Last post by Patrick M. Hausen - Today at 12:03:50 AM

I think he wants to know what the preferred way is to do that

I guess they want to know if there is any automatic migration.

Answer:

No, there is not. You are supposed to manually move all your settings form ISC to either Kea or DNSmasq. With the exception of static assignments which can me moved in bulk as @meyergru already explained.

The existence of the ISC plugin simply buys you time to postpone that migration for yet another (or two, three ... nobody knows quite yet) release. As far as I know it will be installed automatically on upgrade.

I moved to Kea at home. Wasn't a big deal. Will move all installations at work before April, because that will be when business edition 26.4 hits with most probably the exact same constraints and I want a final stable base for my BE installations. Community editions will have been converted, by February or so.

It's the same with IPsec or OpenVPN. Manual migration it is.

HTH,
Patrick

#84

25.7, 25.10 Series / Re: clarification of snapshots

Last post by nero355 - Today at 12:03:42 AM

Also, PROXMOX e.g linux snapshots and fBSD snapshots are not the same thing. The later is more superior.

As fas as I know OpenZFS has become the default for both Linux and *BSD so there is no longer a difference between the two like there was in the past before the merge ?!

#85

25.7, 25.10 Series / Re: What is the official migra...

Last post by nero355 - January 17, 2026, 11:56:15 PM

On 26.1 in 10 - 15 days... ISC will leave the core opnsense and become a plugin. From there, you can migrate to dnsmasq or Kea

I think he wants to know what the preferred way is to do that :

or is there a planned way from OPNsense for all the existing installations?

Since you can't install the plug-in before updating to the version that has ISC as plug-in install option for the first time :)



Maybe just setup DNSmasqd/KEA before the update first and then update OPNsense I guess ?!

#86

25.7, 25.10 Series / Cant Access Web Gui

Last post by colin299 - January 17, 2026, 11:48:07 PM

I have just freshly installed Opnsense on a ProtectLi vault. I have gone through and assigned the correct interfaces in the opnsense software. Both my computer I am trying to access the GUI from and the software are set on 192.168.40.x IPs with the same subnet. When I enter the shell on opnsense to ping my PC it says that the host is down. And when I try to ping the GUI from my PC I get nothing. I dont know if this is a firewall issue or not. If it is, I have no idea how to fix it. I am at a loss and would appreciate any help.

#87

25.7, 25.10 Series / automatic neighbor discovery i...

Last post by heitkergm - January 17, 2026, 11:37:39 PM

I was unpleasantly surprised that the 25.7.11_1 update caused my router to crash reliably after about 5 minutes after each reboot.

Running 25.7.10_x, the router was rock-solid and never crashed, running for many days at a time.

I disabled the Interface->Neighbors->Automatic-Discovery option, and the router has returned to stability.

Should a NEW feature be automatically enabled?  After this,  I would say NO!

#88

General Discussion / Re: Development / Community / ...

Last post by passeri - January 17, 2026, 11:26:28 PM

Given the base is working software, not a development from scratch, I can understand that the release pattern does not follow a conventional cycle such as one might read in Wikipedia. I interpret development as a form of beta which is yet changing for reasons other than bugs. Community I accept as an advanced stable release which may yet have bugs which are fixed under _NN releases. Business is a supported stable release which might be called long term except that its term is not long.

Opnsense is not the only operation to follow a pattern like this, nor the only forum in which it is argued. I think that the conventional namings from alpha through gold, including the word beta, confuse the issue by their prior connotations.

We have a stable base product. On that there is a development offshoot. When that is feature-complete (for this phase) and stable it becomes Community, field testing more advanced features ahead of the low-risk business edition.

The clear implication is that there are three levels of risk for the consumers who must themselves share the risk management as discussed, firstly by selecting in which level they will join and secondly by their own testing and timing of upgrades on one or more of their own systems. Personally I use select Community then upgrade (always with snapshots) through "Does it work for a few hours?" on a reserve box to "Does it work for a few days?" on an internal production box to "Here we go" on the edge router.

#89

25.7, 25.10 Series / Re: Dnsmasq stops occasionaly

Last post by ligand - January 17, 2026, 11:21:57 PM

addn-hosts=/var/etc/dnsmasq-hosts
addn-hosts=/var/etc/dnsmasq-leases
#conf-dir=/usr/local/etc/dnsmasq.conf.d,*.conf
  PID   RSS COMMAND
51305 14916 /usr/local/sbin/dnsmasq -x /var/run/dnsmasq.pid -C /usr/local/etc/dnsmasq.conf
Sat Jan 17 09:03:01 EST 2026
  PID   RSS COMMAND
51305 31912 /usr/local/sbin/dnsmasq -x /var/run/dnsmasq.pid -C /usr/local/etc/dnsmasq.conf
Sat Jan 17 10:03:01 EST 2026
  PID   RSS COMMAND
51305 50476 /usr/local/sbin/dnsmasq -x /var/run/dnsmasq.pid -C /usr/local/etc/dnsmasq.conf
Sat Jan 17 11:03:01 EST 2026
  PID   RSS COMMAND
51305 66684 /usr/local/sbin/dnsmasq -x /var/run/dnsmasq.pid -C /usr/local/etc/dnsmasq.conf
Sat Jan 17 12:03:01 EST 2026
  PID   RSS COMMAND
51305 80724 /usr/local/sbin/dnsmasq -x /var/run/dnsmasq.pid -C /usr/local/etc/dnsmasq.conf
Sat Jan 17 13:03:01 EST 2026
  PID   RSS COMMAND
51305 99828 /usr/local/sbin/dnsmasq -x /var/run/dnsmasq.pid -C /usr/local/etc/dnsmasq.conf
Sat Jan 17 14:03:01 EST 2026
  PID    RSS COMMAND
51305 118236 /usr/local/sbin/dnsmasq -x /var/run/dnsmasq.pid -C /usr/local/etc/dnsmasq.conf
Sat Jan 17 15:03:01 EST 2026

#90

25.7, 25.10 Series / Unbound + dnscrypt-proxy broke...

Last post by opnessense - January 17, 2026, 10:59:24 PM

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:5353

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@5353
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@5353):

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

drill @127.0.0.1 -p 5353 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:5353)" 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@5353

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