Recent posts

[- I would have upgraded my FreeBSD Bootloader at this point to avoid any issues in the future !!]

#1

26.7 Series / Re: Firmware upgrade from 26.1...

Last post by turipriv - Today at 11:12:29 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

:)

Good point, but as I said, I am late-loading the microcode.

Also, I had enough emotions for a Sunday already without upgrading the bootloader... ;P

Jokes aside, upgrading the bootloader is the next planned step, but I'm a couch potato and didn't want to remove my FW from the rack in case anything went wrong.

[Backup]

#2

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

Last post by lmoore - Today at 11:00:00 AM

Good to hear you're making progress.

FWIW, I would have installed 25.1 on the Backup firewall and using the Web GUI on Backup firewall, restored the configuration file created on the Primary, also using the Web GUI.

If the restored configurations put the system in a functional state, one would be well on their way to having a firewall to drop in as a replacement.

However, with the path you are on I would suggest getting DHCP working on the Backup firewall using the OPNsense documentation before tackling the reservations you have.

OPNsense documentation:

- https://docs.opnsense.org/manual/dnsmasq.html

Here is a list (not exhaustive) of articles after searching migrating from ISC DHCP to Dnsmasq on OPNSense.

- https://www.bigiron.cc/guides/opnsense-dhcp-migration-isc-to-kea-or-dnsmasq
- https://learntohomelab.com/docs/HomeLab-Series/EP41_OPNsense%20ISC%20DHCP%20Migration%20to%20Dndsmasq%20DHCP/
- https://homenetworkguy.com/how-to/migrate-from-isc-dhcp-to-dnsmasq-or-kea-dhcp-in-opnsense/
- https://blog.hyperboly.net/posts/guides/isc-to-dnsmasq-opnsense/
- https://www.youtube.com/watch?v=AzJB6Mx3CnQ
- https://github.com/meyergru/iscdhcp_to_dnsmasq
- https://forum.opnsense.org/index.php?topic=51785.0
- https://forum.opnsense.org/index.php?topic=47371.0

#3

French - Français / Documentation des règles firew...

Last post by Linkas - Today at 10:59:34 AM

Salut à tous,

Je remonte un peu ce que j'ai vécu il y a trois semaines suite à une migration de version sur le firewall de la PME industrielle où je bosse, ça peut servir à d'autres. Apres la mise à jour majeure d'OPNsense, il fallait reprendre toute la doc des règles NAT et ACL, une trentaine de règles au total. Franchement au début je me suis dit que j'allais tout retaper à la main comme d'habitude, sauf que j'ai exporté les configs en xml et je me suis retrouvé avec des blocs illisibles pour quelqu'un qui n'a pas le nez dedans (mon collègue en l'occurrence, qui doit pouvoir s'y retrouver si je suis absent). Du coup j'ai testé une alternative gratuite à ChatGPT, en français, sans inscription, pour reformuler mes exports de config en fiches lisibles. J'ai collé des morceaux de règles et demandé un résumé en français avec le contexte (source, destination, action), et ça m'a sorti des fiches que j'ai pu relire et corriger ensuite... Ça m'a évité de tout rédiger de zéro, surtout sur les règles répétitives genre les ACL par VLAN. Après je vérifie quand même chaque fiche avant de la valider, on ne sait jamais. Bref, ça m'a fait gagner pas mal de temps sur la partie rédaction, le reste (vérif des états firewall, tests des règles) je l'ai fait à la main comme d'hab. Quelqu'un d'autre a des méthodes pour ce genre de doc post-migration?

Merci d'avance,

#4

26.1, 26,4 Series / Re: samplicate pegging cpu

Last post by franco - Today at 09:46:19 AM

> I did exactly what you had informed me to do.

Why are we losing focus again?

Just run the command first:

# pluginctl -g OPNsense.Netflow


Cheers,
Franco

#5

26.1, 26,4 Series / Re: samplicate pegging cpu

Last post by ubu - Today at 09:28:03 AM

A 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,
Franco

Code Select Expand

root@OPNsense:~ # cat /etc/rc.conf.d/netflow
#
# Automatic generated configuration for netflow.
# Do not edit this file manually.
#
netflow_enable="YES

"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."

Should I this time perform the above set of instructions and also edit that file and change it to "No"?

#6

German - Deutsch / Re: OPNsense 26.7.3_11 unter P...

Last post by sternchen45 - Today at 09:11:01 AM

ZFS in einer VM, am besten noch auf einem ZFS-Pool, ist keine gute Idee, Stichwort Write Amplification.

Besser, UFS zu nutzen. Snapshots lassen sich immer noch VM-seitig über die in PVE enthaltenen Tools erstellen.

Insgesamt bin ich erstaunt, dass Du die doch reichliche und klare Doku zu Opnsense in virtualisiert nicht berücksichtigst.

[Following up with perhaps some "good news" after my previous post:]

#7

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

Last post by seamus - Today at 08:37:07 AM

Following up with perhaps some "good news" after my previous post: 

I've managed to place the "Backup" firewall in a functional "isolated network":

Code Select Expand


      +--------------+                +----------------+        +--------------+                 +---------------+
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 |
                                      +------------------+                                     +-----------------+
                                         

I have no idea what caused this, but after a couple of reboots this evening I tried 'Option 2' (Set Interface IP address) in the console again. This time, there was no "preset" for 192.168.1.1/24; this time the console config, 'Option 2' took the new address (192.168.10.1/24) when entered, and applied it to the LAN interface!! :) 

I wish I knew why this happened... I'm glad things have inched forward, but that's tempered by the uncertainty of WHY??
I wonder if it could have something to do with the "Primary fw" backup config... I "manually" restored this backup to the "Backup fw" in '/conf/config.xml' using the shell???

Now comes the "real fun" in translating my settings from "Primary" 21.7.8 to "Backup" 26.7. As it turns out, I was using part of dnsmasq - 'Dnsmasq DNS' in ver 21.7.8. Any clues re how to configure Dnsmasq with DHCP and Unbound would be appreciated!

Thanks again,
~S

["Backup" fw]

#8

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

#9

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!

#10

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.