Quote from: nero355 on September 13, 2026, 10:11:24 PMQuote from: turipriv on September 13, 2026, 11:15:04 AM- Uninstalled os-cpu-microcode-intel plugin:)
- Upgraded from 26.1.11_10 to 26.7
- Automatic reboot
- I would have upgraded my FreeBSD Bootloader at this point to avoid any issues in the future !!
- Upgraded from 26.7 to 26.7.3_11
- Automatic reboot
- Reinstalled os-cpu-microcode-intel plugin
- Manual reboot
Quote from: ubu on September 12, 2026, 11:41:48 AM"you have not reset it properly in the settings", I did exactly what you had informed me to do. Is there a way to improperly do what you instructed? I did exactly this, "System: Configuration: Defaults: Components: select "NetFlow configuration" -> Reset."Quote from: franco on September 11, 2026, 05:45:03 PMA stuck template perhaps, but clearing the settings would disable it in that case. There's no reason it wouldn't. The stack trace at hand is also unknown, which could confirm the issue or point elsewhere.
What's in /etc/rc.conf.d/netflow ? Removing the file would also cause it not to start although in practice the reboot rebuilds the file so whatever the config mandates is going to steer the YES/No decision.
Cheers,
Francoroot@OPNsense:~ # cat /etc/rc.conf.d/netflow
#
# Automatic generated configuration for netflow.
# Do not edit this file manually.
#
netflow_enable="YES
+--------------+ +----------------+ +--------------+ +---------------+
WAN | "Primary fw" | LAN | E'net switch 1 | WAN | "Backup fw" | LAN | E'net switch 2|
----->| ver 21.7.8 |<-------------->| |<------>| ver 26.7 |<--------------->| |
DHCP | | 192.168.1.0/24 +----------------+ DHCP | | 192.168.10.0/24 +---------------+
+--------------+ | +--------------+ |
| |
| |
+------------------+ +-----------------+
| LAN hosts | | LAN hosts |
| 192.168.1.0/24 | | 192.168.10.0/24 |
+------------------+ +-----------------+
Quote from: nero355 on Today at 12:31:26 AMJust make sure the LAN IP Range on both Routers is different like I told you earlier ;)
And you can do those changes via the webGUI but make sure that at that time the Routers are not connected to each other !!
Quote from: seamus on September 13, 2026, 10:47:54 AMI've hit a snag in setting up the "isolated network":
- The WAN on the "Backup" fw seems to be fine. It was set up for DHCP, and when I plug it into the "Primary" fw (switch connected to LAN port), it takes an IP address of 192.168.1.139... that seems OK
- The LAN is not cooperating! The config.xml file I restored to the "Backup" fw has the LAN setup as 192.168.1.1/24. To fix this, I'm using Option 2 in the CLI/console setup menu. During the Option 2 dialog, I changed the LAN IP to 192.168.10.1/24. Unfortunately this change DOES NOT TAKE! Each time I finish with Option 2, the system reports the LAN address as 192.168.1.1/24!!
What am I doing wrong? Do I have to edit the XML file to make this change to the LAN address range? Why doesn't Option 2 allow me to make this change?
OPNSENSE OS-DDCLIENT + DNS MADE EASY (DIGICERT) - FINDINGS & CONFIGURATION GUIDE
================================================================================
SUMMARY
-------
DNS Made Easy (DME) support in os-ddclient is not missing or abandoned - it is
hidden behind a backend setting people might not know exists. Switching
Backend to "ddclient" in General Settings makes it reappear in the account
dropdown. If the legacy backend does not work cleanly, DME can also be
configured on the newer "native" backend using its generic custom-URL escape
hatch, with the DME API URL hand-built in the Server field. This second
method (embedded URI) is the one confirmed working.
BACKGROUND: THREE CONFUSINGLY SIMILAR NAMES
--------------------------------------------
- os-dyndns : the original, now fully removed OPNsense plugin. Predates
ddclient entirely; had its own separate implementation.
- ddclient : the upstream Perl dynamic-DNS utility (FreeBSD package
ddclient-devel). As of ~2023, upstream ddclient is
unmaintained/archived (see ddclient/ddclient issue #528 on
GitHub).
- os-ddclient : the current OPNsense plugin (GUI + service). Despite the
name, it ships TWO independent backends under one plugin:
the legacy Perl ddclient binary, and a from-scratch Python
reimplementation labeled "native" in the GUI.
ROOT CAUSE OF "DNS MADE EASY ISN'T IN THE LIST"
------------------------------------------------
- DME was added to os-ddclient back in Feb 2022 (commit 6a6882e0) and is
still fully present today in the plugin's protocol dropdown definition -
confirmed directly against current master source.
- In Jan 2023 (commit ef91a6b4), the plugin gained a second, from-scratch
Python backend ("native"), intended to eventually replace the unmaintained
Perl ddclient.
- The Python backend only reimplements a small subset of providers:
allinkl, aws, azure, cloudflare, digitalocean, dnspod_cn, domeneshop,
duckdns, dyndns2, gandi, hetzner, hostinger, netcup, powerdns.
DNS Made Easy was never ported to it.
- The GUI filters the protocol dropdown based on which backend is selected.
If Backend = opnsense (native), the dropdown shows ONLY that ~14-provider
list, completely hiding DME (and every other legacy-only provider). The
default backend in current master is now "opnsense" - so a fresh install
hides DME by default.
- FIX: General Settings -> Backend -> "ddclient". This restores the full
legacy protocol list, including DME.
KNOWN ISSUE ON THE LEGACY BACKEND
-----------------------------------
GitHub opnsense/plugins issue #3494: a user configured DME correctly per
DME's own docs (Service = DNS Made Easy (digicert), resourceID = numeric
Dynamic DNS ID, Password = per-record Dynamic DNS Password, Hostname(s) =
real hostname) and still got this log entry:
FAILED: Updating HOSTNAME: Server said: '0':
This was never confirmed resolved for DME specifically in that thread. Test
carefully and check the ddclient log after saving. If you hit this same
failure, it is a known unresolved bug in an unmaintained dependency, not a
configuration mistake.
ALTERNATIVE: STAY ON THE NATIVE/PYTHON BACKEND (CONFIRMED WORKING)
---------------------------------------------------------------------
The native backend has a generic escape hatch for providers it does not
implement natively. The dyndns2.py handler supports:
Service = Custom
Protocol = Custom GET / Custom POST / Custom PUT
...which lets you supply a fully custom URL. Simplified source:
if protocol in ['get', 'post', 'put']:
url = self.settings.get('server')
url = url.replace('__MYIP__', self.current_address)
url = url.replace('__HOSTNAME__', self.settings.get('hostnames'))
req = requests.request(method=protocol, url=url, ...,
auth=HTTPBasicAuth(self.settings.get('username'),
self.settings.get('password')))
Important limitations of this mechanism:
1. Service and Protocol are two separate dropdowns. "Custom GET/POST/PUT" in
the Protocol list is the same generic handler just picking an HTTP verb;
you still need Service = Custom for the account to route to this handler
at all.
2. The code only substitutes __MYIP__ and __HOSTNAME__ inside the Server
string. There is NO __USERNAME__ or __PASSWORD__ placeholder. The
Username/Password form fields are ONLY ever used to build an HTTP Basic
Auth header - they are never merged into the URL.
3. DME's real API (per ddclient's own upstream Perl source) expects
username= and password= as literal query-string parameters, not Basic
Auth. Since there is no way to inject the form fields into the URL, the
real credentials must be hardcoded directly into the Server string, and
Username/Password left blank (harmless - they just produce an unused,
ignored Basic Auth header).
4. Consequence: the DDNS password ends up stored in plaintext in config.xml
as part of the Server field (a plain text field, not masked like the
dedicated Password field). Low risk for a DME-record-specific DDNS
password, but worth knowing.
DME'S REAL API SHAPE (FROM DDCLIENT'S OWN PROTOCOL DEFINITION)
------------------------------------------------------------------
server = cp.dnsmadeeasy.com
script = /servlet/updateip
Full request:
https://cp.dnsmadeeasy.com/servlet/updateip?username=...&password=...&ip=...&id=...
- id= is a NUMERIC Dynamic DNS Record ID, generated per-record in the DME
control panel - NOT a hostname. This is the single biggest DME-specific
gotcha: every other provider in this plugin expects a real hostname in the
Hostnames field; DME expects that field to hold the numeric record ID
instead (comma-separated if updating more than one record).
- password= is the record's Dynamic DNS Password, a separate value DME
generates per record - NOT the main DME account login password.
CONFIGURATION - NATIVE BACKEND, CUSTOM ESCAPE HATCH (CONFIRMED WORKING)
---------------------------------------------------------------------------
Service : Custom
Protocol : Custom GET
Server : https://cp.dnsmadeeasy.com/servlet/updateip?username=DME_USERNAME&password=YOUR_DDNS_PASSWORD&ip=__MYIP__&id=__HOSTNAME__
Username / Password : leave blank (unused for this provider)
Hostname(s) : your numeric DME Dynamic DNS Record ID(s),
e.g. 1007 or 1007,1008
Remember to URL-encode special characters in the embedded username/password if needed
(e.g. "@" becomes "%40").
CONFIGURATION - LEGACY DDCLIENT BACKEND, NATIVE DME SUPPORT (UNTESTED / KNOWN BUG RISK)
-------------------------------------------------------------------------------------------
Backend (General Settings) : ddclient
Service : DNS Made Easy (digicert)
resourceID : your numeric DME Dynamic DNS Record ID
Username : your DME account login email
Password : the record's Dynamic DNS Password
(not your account password)
Hostname(s) : your real hostname
FALLBACK
--------
If neither plugin approach works, DME's own KB shell-script-on-cron approach
is a fine, simple, proven fallback:
https://support.dnsmadeeasy.com/hc/en-us/articles/34327247093531-The-DDNS-Shell-Script
It is functionally identical to the "native backend custom GET" approach
above, just running outside OPNsense's plugin framework via cron instead.
You lose the GUI status/last-updated indicator and automatic re-trigger on
WAN IP change, but gain independence from either of os-ddclient's two
backends and their respective rough edges.
OUTCOME
-------
The embedded-URI method (native backend, Service = Custom, Protocol =
Custom GET, credentials and record ID baked into the Server field) has been
tested and confirmed working.