Recent posts

["Backup" fw]

#1

26.7 Series / Re: Can settings from ver OPNs...

Last post by seamus - Today at 02:58:36 AM

Just 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 !!

Yes - WRT making the "LAN IP Range on both Routers is different", please refer to my earlier post - repeated below:

I'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?

Another question is access to the "OPNsense Configuration WebGUI". Can I access the WebGUI from the WAN port? If so, HOW?  I tried this last night, but it DID NOT WORK. I thought that perhaps a Rule or Setting might need to be changed, but that seems to be a "Catch 22" - i.e. need WebGUI to change those Rules/Settings.

Thanks again for your time and patience,
~S

#2

26.7 Series / NAT Port Forwarding rules for ...

Last post by omar.chancusig - Today at 02:35:35 AM

Hi everyone,I'm facing a persistent issue with Destination NAT (Port Forward) after updating to OPNsense 26.7.
The Problem:
Every time the firewall reboots, almost all of my port forwarding rules that point to internal IP addresses and internal ports stop working. External traffic cannot reach the internal hosts.Strangely, the only rule that does work perfectly after every reboot is the one that redirects access to OPNsense itself (using This Firewall as the target).

Current Workaround:
To fix it, I have to manually go to Firewall ➔ NAT ➔ Port Forward and simply click "Apply". As soon as I force the reload, all internal redirections start working instantly until the next reboot.

Environment & Context:
OS Version: OPNsense 26.7
Symptoms: It behaves like a race condition during the boot sequence, where the pf rules are being evaluated/loaded before the local interfaces or internal IP bindings are fully up and ready.
Tunables: I checked my System Tunables, and they are completely stock (no experimental network delays or routing overrides active).Has anyone else experienced this specific synchronization issue in 26.7? Is there a known fix or a recommended tunable/boot hook to delay the initial pf load until internal interfaces are fully operational?Thanks in advance for your help!

#3

26.7 Series / Re: os-ddclient and DNSMadeEas...

Last post by MattSF23 - Today at 02:28:23 AM

wow, what a rabbit hole that was 😛

I asked my close, personal friend Claude to investigate and here's some info below. The TL;DR on this is: you can use the older ddclient backend or use 'native' for the built-in Python-based dynamic DNS support in OPNSense. Select whichever under Services: Dynamic DNS: Settings: General Settings. If you're going with the native version, there is some funky formatting you'll need to do for 'Server'
In which case you'll have to ... READ 😁

Code Select Expand

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.



#4

26.7 Series / Re: Boot stuck for 1-2 min aft...

Last post by Gilgamesh - Today at 01:22:04 AM

No, I haven't found any solutions yet and at the moment I'm not actively seeking such as not urgent for my situation. My S2S tunnel initiates properly without my interaction, so the only impact for me currently is the boot time.

#5

26.7 Series / Re: os-ddclient and DNSMadeEas...

Last post by MattSF23 - Today at 12:35:56 AM

Oh I should have said: I'm using Firmware version 26.7.3_11 and os-ddclient version 1.31_1

#6

26.7 Series / SOLVED: os-ddclient and DNSMad...

Last post by MattSF23 - Today at 12:33:53 AM

Hi folks, just moved from pfsense to OPNsense and it was a bit bumpy but now things are working pretty well. One thing I forgot to check was what dynamic DNS services are supported by the os-ddclient plugin. I see 'DNS Made Easy (digicert) in the source code for os-ddclient:
https://github.com/opnsense/plugins/blob/acb1d44b1109617e70b505b8800753266f5a2099/dns/ddclient/src/opnsense/mvc/app/models/OPNsense/DynDNS/DynDNS.xml#L51
But then it looks like it was (partially?) removed (no longer in ddclient.conf in master/main)

It doesn't appear to be an active choice in the GUI console under Service in the plugin settings. I'm guessing the code didn't work or there wasn't much demand to maintain it?

Does anyone know if the functionality is duplicated in another service name, or should I look for a new DNS provider? 😔 Thanks!

#7

26.7 Series / Re: Can settings from ver OPNs...

Last post by nero355 - Today at 12:31:26 AM

However, the only logical conclusion I can come to based on the conflicting advice is that there may be more than one way to do this!

Not really...

Just 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 !!

[L]

#8

Hardware and Performance / Re: Power loss recovery on Pro...

Last post by nero355 - Today at 12:27:12 AM

A (convenient, supported) bigger battery option would be nice, too (e.g. 2 AA).

Rechargeable AA batteries can be Low Self Discharge models for many years now : Why aren't these things too ?! :(

System ON = Charge the battery to 100% and cut off when full.
System OFF = Use the battery for the CMOS Clock until next boot.

Maybe it will be that simple one day... Who knows...

Oh, context: I like to use systems for 10+ years these days. Advances in computer hardware just aren't as exciting as they were 25+ years ago.

+1 here :)

[Let me try to explain how this idea of an isolated network entered the conversation:]

#9

26.7 Series / Re: Can settings from ver OPNs...

Last post by seamus - Today at 12:19:25 AM

Let me try to explain how this idea of an isolated network entered the conversation:


A. Unless I've missed something, you first introduced the "isolated network" here:

Set up the back up machine on an isolated network ...

B. Subsequently, I asked a question to clarify what you meant by "isolated network":

Re setting up on an "isolated network": To avoid confusion, let's agree to call my current, existing OPNsense ver 21.7.8 firewall as the "Primary" firewall, and a 2nd machine with the more current version of OPNsense we'll call the "Backup" firewall.

1. [QUESTION] I've only got a single network, and it's a fairly small one; my LAN is 192.168.1.0/255. I have about 20-30 hosts, and reserved approx 50 addresses for use as fixed IPs (using about 6 of those). My question is regarding the "isolated network". Could I simply connect the WAN for the "Backup" firewall to the LAN of the "Primary" firewall?

C. After that post, this one was made - which seemed to answer my question re "isolated network":

My question is regarding the "isolated network".
Could I simply connect the WAN for the "Backup" firewall to the LAN of the "Primary" firewall?

Correct!

That's how I play with other Routers behind my own Router all the time :)

D. And now we arrive at your most recent post:

I don't understand why you plugged the WAN port in to your functioning LAN - it wasn't going to work. That's why I advised disconnecting network cables.

I hope you now understand why I "plugged the WAN port in to your functioning LAN"

So, I will try again using your advice. However, the only logical conclusion I can come to based on the conflicting advice is that there may be more than one way to do this!

And please forgive my sloppy ignorance - I am trying.

#10

General Discussion / Re: Block Local Network Connec...

Last post by nero355 - Today at 12:15:43 AM

I maintain a dumb TV with AppleTV in front like connervt, and imprison an NVR as described in the previous paragraph. Having to VPN in to check what the cameras are seeing is the trade-off when I am out of the house.

This =>

My best you can do solution here at home is to never connect the "Smart" TV itself to my network.  Instead, I have an AppleTV4K and a Chromecast connected to my big family TV.  The AppleTV4K does everything (and more) better than the TV's native apps.  The Chromecast allows for the simple streaming from one device to another.

I have zero trust in any of the smart TV's native operating systems nor the apps that run on them.

?!?!

That's like chosing between two devils that also happen to be twin brothers! LOL! :P


If you really want to get away from it all you need to be a lot more radical and go for something like https://plasma-bigscreen.org/ for example :)