Messages

[Backup]

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.

I did seriously consider that - and AFAIK, I've not surrendered any options yet - so I might still...  However, my thinking is currently running in the direction of taking a "bigger step" toward becoming "current". I am hoping that my network is simple enough that I don't take that big step in front of an oncoming bus :)  If you'd care to provide some background on your suggestion, I'd really like to hear that. FWIW, following is how I'm currently thinking on the path forward:

And as I said in my OP, my primary motivation for this effort is a hardware upgrade. I've still not decided what that hardware will be, but the low-end "Deciso" models are high on my list. I still need to evaluate the "throughput" of my current 10 yr-old SuperMicro hardware is... I think I can do this with 'iperf3'. But if that evaluation turns out as I think it will, I'll be "in the market" for at least one new server. And if I decide on a Deciso model, it will come with a current version of OPNsense pre-installed. So if this pans out as I expect, it would seem that an upgrade to the current version of OPNsense is inevitable.

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

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]

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

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

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.

["Backup" fw]

Trying to set up

Set up the back up machine on an isolated network to avoid IP address conflicts with the installation on the back up machine and especially when you've restored the configuration file.

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?

Thanks again,
~S

[isolated network]

Set up the back up machine on an isolated network to avoid IP address conflicts with the installation on the back up machine and especially when you've restored the configuration file.

Thanks for your reply! I have a couple of comments & questions if you don't mind, and I surely appreciate your time.

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? IOW: connect the "Backup" WAN port into a switch used for LAN clients of the "Primary" firewall. And assign the "Backup" fw LAN to be (e.g.) 192.168.1.10/255? IOW the "Backup" firewall will be behind the "Primary" firewall? I could connect a couple of my Raspberry Pis to the "Primary" LAN to complete the "test configuration"...  Would this setup be what you characterized as an "isolated network"??  If there's a simpler/better method, please let me know. 


2. [COMMENT] After posting my question, I found a clear set of installation instructions for OPNsense. I successfully installed ver 26.7 on the "Backup" host machine. I used the shell to install/copy my latest backup config file into the "right place". Afterwards, I powered down the "Primary" firewall, and substituted the "Backup" firewall in its place to have a "look-see" at the GUI. To my surprise, most things worked! What didn't work was DHCP for all of the "dynamic" clients. I learned that ISC DHCP has been abandoned/deprecated by the ISC, and replaced with a new type of DHCP (KEA??). Anyway - I ran the network with the "Backup" firewall for about 20 minutes, and then restored the "Primary" firewall.

3. [QUESTION] Would the installation instructions I used for ver. 26.7 also work with older versions?

4. [QUESTION] Do you know what the last version number was for OPNsense that had the ISC DHCP as the default configuration?

Thanks again!
~S

I installed OPNsense on my server in Jan 2018 - best I can recall. I upgraded fairly regularly until I got to ver 21.7.8. I stopped there because I was concerned about migrating to the "new" version, and because I began traveling extensively. My OPNsense firewall (OPNsense + SuperMicro Intel 4 core 1.8 GHz Atom CPU) has run 24x7 for many years now with virtually no maintenance or administration! The only time I even log into the FW is when I need to check the DHCP logs. My ISP is Google fiber - also very reliable. My family used the Internet continuously while I was on travel, and never had an incident. All this is background to say that I'm very pleased with this setup!

However, after 8+ years I have some concerns re my hardware. Late last year, I attempted installation of a newer version of OPNsense on a slightly newer server that has seen very little use - I planned to use it as a "cold backup" system. Unfortunately, my installation attempt was unsuccessful. 

I am now *seriously* considering the future. I definitely want to stick with OPNsense, but feel that I must upgrade my hardware. 8+ years ago I was "active", and enjoyed tinkering in such projects. Today, I'm looking for a solution that doesn't involve "starting over", and is less challenging for my aging brain  :P  All of that said, I have a few questions:

1. At one time (and perhaps still today) OPNsense allowed one to make a "configuration backup" to an XML file. I still have several of these backup files - several from 2022, the latest from June 2025. Can I apply these "backup configuration" files to a new version of OPNsense?

2. As I said earlier, I am motivated to upgrade my hardware. It's my understanding that if I bought a hardware server, OPNsense would come pre-installed. I wonder if I could send my "backup configuration" files to Decisio (?), and have them "pre-configure" my server?

3. As I read the specifications, it seems the DEC677 would meet my needs. My Google Fiber service is rated at 2 Gbps, and there are 3-4 fairly active users. We have a "streaming service" for movies, a "cellular extender box" and several (too many) computers laying about. Could someone "take a stab" at confirming the DEC677 would be sufficient?

That's all I can think of at present. Thanks in advance for your help!

Best Rgds,
~S

I'm sorry, but I am not clear on the point of your post. It seems to be out of context; perhaps you posted in the wrong place?

I am trying to troubleshoot a problem. I have several hosts on my network that use `dhcpcd` (DHCP Client Daemon). I've used `dhcpcd` for years, and it seems to work quite well, but I am having an issue with a couple of hosts recently that are configured with the `inform` option. All that means is that the hosts send a DHCPINFORM message, and receive a DHCPACK as shown in the log messages below.


2022-05-17T16:40:52   dhcpd[42083]   DHCPACK to 192.168.1.57 (b8:27:eb:3a:b9:78) via em1   
2022-05-17T16:40:52   dhcpd[42083]   DHCPINFORM from 192.168.1.57 via em1


`dhcpcd` seems to be happy with this result; its log shows the following:


May 17 22:40:26 raspberrypi1bp dhcpcd[265]: dev: loaded udev
May 17 22:40:29 raspberrypi1bp dhcpcd[265]: eth0: waiting for carrier
May 17 22:40:31 raspberrypi1bp dhcpcd[265]: eth0: carrier acquired
May 17 22:40:32 raspberrypi1bp dhcpcd[265]: eth0: probing address 192.168.1.57/24
May 17 22:40:36 raspberrypi1bp dhcpcd[265]: eth0: received approval for 192.168.1.57
May 17 22:40:36 raspberrypi1bp dhcpcd[265]: eth0: adding route to 192.168.1.0/24
May 17 22:40:36 raspberrypi1bp dhcpcd[265]: eth0: adding default route via 192.168.1.1
May 17 22:40:37 raspberrypi1bp dhcpcd[265]: forked to background, child pid 371


The host seems to operate correctly, `ip addr` & `ip route` give expected results, the host can reach other hosts on the LAN, and on the Internet, and the host can be found by other hosts on the LAN.

The only odd thing is that this host is never listed in the lease table when the inform option is used. I have another host that is configured identically, and it does show up in the lease table as follows:


I/f      IP addr      MAC addr           Hostname      Description               Lease type
LANem1 192.168.1.51  b8:27:eb:a7:8c:00  raspberrypi0w  RPi Zero W - WiFi client  static


I suspect that one of these two clients is failing to send something that's needed for the log entry, but I have no idea what that "something" is. Beyond the DHCPINFORM, and the DHCPACK, what is needed by the OPNsense DHCP server to make an entry in the lease table?

[A log of my investigation into "Fix the DNS" follows:]

A log of my investigation into "Fix the DNS" follows:

There is definitely something amiss with DNS. Using the diagnostics in OPNsense, I can't ping pkg.opnsense.org - or anything else for that matter. The output is:

Code Select Expand

# /sbin/ping -c '3' 'pkg.opnsense.org'
ping: cannot resolve pkg.opnsense.org: Host name lookup failure

Oddly, I get intermittently successful (but rather slow) DNS lookups (see attachment); sometimes I get a result - sometimes I don't!

I didn't (knowingly) change anything during my string of updates yesterday - except to disable the plugin for Dynamic DNS. This system has been running for years; I started with a much older version, and have updated it repeatedly without incident. My configuration tends to remain very stable. Here's how my DNS is set up currently:

Dnsmasq is enabled on both (LAN & WAN) interfaces, Port 53

MDNS Repeater is also enabled - on the LAN only; this is contrary to the "Help recommendation": "At least two interfaces must be selected."  I didn't change this during my machinations yesterday - at least not intentionally. No other DNS services are enabled; only Dnsmasq & MDNS Repeater. I do not recall why MDNS repeater is installed!! I have intermittently run a VPN on OPNsense - perhaps it was added to support that?

This may be relevant: Viewing my Firmware plugins, I see this:

Code Select Expand

os-dyndns (orphaned) 1.24_2 169KiB OPNsense Dynamic DNS Support
os-mdns-repeater (orphaned) 1.0_1 14.7KiB OPNsense Proxy multicast DNS between networks

Perhaps this is a result of the failure to resolve pkg.opnsense.org ?

On the LAN hosts I checked, DNS seems to work perfectly & prompt responses are received:

Code Select Expand

$ host pkg.opnsense.org
pkg.opnsense.org has address 89.149.211.205
pkg.opnsense.org has IPv6 address 2001:1af8:4f00:a005:5:: 

I have just now disabled MDNS Repeater (no reboot), and it seems to have no effect: pings are 100% failures, DNS lookups remain intermittent, updates remain "constipated".

I re-booted several times yesterday trying to clear the update failure with no effect, but I decided to try a reboot again today...   Voilà !!!
Updates are responsive again, all pings work, and DNS lookup is more responsive.

I am whole again, but please allow me to continue - I still have questions:

1. The only change I made was to disable MDNS Repeater. I expected OPNsense to prompt if a reboot were required, but got none. I'm left wondering exactly what the "fix" was???

2. Is an enable/disable of MDNS Repeater expected to throw a reboot prompt in the web gui?

3. In an effort to find an answer (by replicating the issue), I re-enable MDNS Repeater and Dynamic DNS under all options used previously, and test before and after a series of reboots:
   a. before reboot: ping works 100%, DNS Lookup seems more reliable, but failed to yield a result for 1 of 3 tests
   b. after reboot: ping works 100%, DNS Lookup worked 100%
   c. I find this result confusing as it implies that nothing I did made any difference at all. Any comments???

4. I have read the documentation for Dnsmasq. My 'take-away' from this is that OPNsense team recommends use of the Unbound DNS - is that a correct interpretation?

Looking forward to any and all replies & thank you for your help.

~ S

[I did see that a couple of plugins were 'orphaned':]

I have gotten behind in my updates, and so today was a 'catch-up' day.

Things have gone x-well until just now; I first encountered a series of messages re missing packages during the OPNsense 21.1.9_1-amd64 update. And now, when I am attempting to update to 21.7 (my final destination for the time being), this message displayed for a very long time:

***GOT REQUEST TO CHECK FOR UPDATES***
Fetching changelog information, please wait... fetch: transfer timed out
Updating OPNsense repository catalogue...

Eventually, it seems to have worked through the process, and the complete message appeared:

***GOT REQUEST TO CHECK FOR UPDATES***
Fetching changelog information, please wait... fetch: transfer timed out
Updating OPNsense repository catalogue...
pkg: https://pkg.opnsense.org/FreeBSD:12:amd64/21.1/latest/meta.txz: No address record
repository OPNsense has no meta file, using default settings
pkg: https://pkg.opnsense.org/FreeBSD:12:amd64/21.1/latest/packagesite.txz: No address record
Unable to update repository OPNsense
Error updating repositories!
pkg: Repository OPNsense cannot be opened. 'pkg update' required
Checking integrity... done (0 conflicting)
Your packages are up to date.
***DONE***

I've not skipped any steps (e.g. when the pkg mgr required an update).

I did see that a couple of plugins were 'orphaned':

os-dyndns (orphaned)   1.24_2   169KiB   OPNsense   Dynamic DNS Support   
os-mdns-repeater (orphaned)   1.0_1   14.7KiB   OPNsense   Proxy multicast DNS between networks

I have the option to delete either or both of these two plugins... Should I ???

I've tried "Check for Updates" again, but it's headed for the same dead-end as above.

I've run an "Audit" on "Health"; it seems all "core package consistency" checks FAILED with the message: 'no upstream equivalent' as follows:

***GOT REQUEST TO AUDIT HEALTH***
Currently running OPNsense 21.1.9_1 (amd64/OpenSSL) at Mon Mar 28 17:02:10 CDT 2022
>>> Check installed kernel version
Version 21.1.8 is correct.
>>> Check for missing or altered kernel files
No problems detected.
>>> Check installed base version
Version 21.1.8 is correct.
>>> Check for missing or altered base files
No problems detected.
>>> Check for missing package dependencies
Checking all packages: .......... done
>>> Check for missing or altered package files
Checking all packages: .......... done
>>> Check for core packages consistency
Core package "opnsense" has 66 dependencies to check.
Checking packages: .
beep-1.0_1 has no upstream equivalent
Checking packages: .
ca_root_nss-3.68 has no upstream equivalent
Checking packages: .
choparp-20150613 has no upstream equivalent

...

Checking packages: .
wpa_supplicant-2.9_11 has no upstream equivalent
Checking packages: .
zip-3.0_1 has no upstream equivalent
***DONE***

What should I do? I don't seem to be able to get my next upgrade!

[1.]

Here's one way to make this work:

After asking a couple of related/similar questions here, I managed to get the final puzzle piece I needed on reddit (the OPNsense sub-reddit). I thought I'd share the answer here. Please note: I don't claim this is the best/optimal answer - I claim only that this does work for my particular situation. Perhaps the OPNsense experts here can identify improvements; perhaps even add something to the documentation?

1. Ref the attachment here below for a crude schematic of my network. The Firewall/LAN gateway at 192.168.1.1 is OPNsense running on an appliance with two (2) Ethernet ports. The OPNsense configuration was mostly the default configuration generated during initial installation some time ago. Recently, I added a small embedded device to the network - the "pocketbeagle" device connected to a laptop running Ubuntu 20.04.

2. The objectives are as follows:

• Internet access for the pocketbeagle device
• SSH access to the pocketbeagle device from hosts on the 192.168.1.0/24 subnet

3. After plugging in the pocketbeagle device, I made an SSH connection from the Ubuntu laptop. I found it was necessary to add a default gateway to the pocketbeagle device:

    $ sudo route add -net 0.0.0.0 gw 192.168.6.1

4. On the Ubuntu laptop, I verified that forwarding was enabled, and that the firewall (ufw) was disabled:


    $ cat /proc/sys/net/ipv4/ip_forward
    1
    # "1" means ip_forward is enabled
   
    $ sudo ufw status
    Status: inactive
    # "inactive" means that no rules are altering traffic patterns on the Ubuntu laptop


5. A return route from the firewall is needed to route packets back to the pocketbeagle device. I did this by creating a static route. Use the GUI from here, be sure to Save, Apply, etc as you complete each step:

• System->Gateways->Single, Add a gateway for the IP on the Ubuntu laptop (192.168.1.104 in this case
• System->Routes->Configuration, Add a route to 192.168.6.0/24 using the gateway defined in the previous step

6. The final step to gain Internet access for the pocketbeagle device is to set up NAT for packets from the 192.168.6.0/24 subnet. Using the OPNsense GUI again:

• Firewall->NAT->Outbound; Change mode to "Hybrid outbound NAT rule generation"
• Add a NAT Rule for the WAN interface for Source Address 192.168.6.0/24

That should do it. My pocketbeagle device can now connect to the Internet, and I can update/upgrade its Debian OS. As far as connecting to the pocketbeagle device from other hosts on the network, I elected not to use OPNsense for this - I simply created a static route on each host that needed access. For example, on my Macbook, this took care of it:

    % sudo route -n add 192.168.6.0/24 192.168.1.104

[were]

Sorry but I can't tell you positive things when you do that wrong.
Just trying to help you. And if you don't want that help and already know how to set it up there shouldn't be a problem in your system.
Here are just people who try to help.

And I think it's not okay if someone is trying to find the bugs in your network, tell you the bugs and you say that these people just spreading negativity.

I appreciate help... really I do. But you weren't helpful. When someone says, "That will not work" a few times, but they are making guesses, I call that negativity. And you were making guesses. How do I know that? Because it does now work - just as I've shown it in the diagram, and configured as I described. Is there more than one way to do it? I'd say that's very likely, but this does work. How? I'll leave that for you to research. 

[am]

On your "Painting" i see that you dont have the 6.0 Network on the OPNsense conencted. That will not work.

So Ping from every device in the 1.0 Network is working. But not from 6.0 to Internet. That is because every Packet from the 6.0 Network is going to your Pocketbeagle, but thats it.

No...  I added the network diagram hoping it would clarify things, but it may be confusing them. It does show a WiFi connection from the Ubuntu Linux host to the gateway at 192.168.1.1. As I explained in my original post, I am routing packets from 192.168.6.0 to 192.168.1.1 with the connections as shown in the diagram.

You can't set your gateway to an address which is not in the Subnet of the device itself. That will not work

I'm ending this thread... your negativity wins - congratulations! You apparently believe I am making this up. FYI, I have better things to do than create imaginary networks, and report results that I didn't actually see.

Simple, they cannot see each other. the x.x..6.0 range will not talk to the *.*.1.0 range without either a gateway or a mask of 255.255.0.0. What make/model is the USB dongle, sounds like it's running in gateway mode rather than access point mode.

I have a gateway - the WiFi interface in the Ubuntu host (see attachment, please). I've created a static route in OPNsense using this gateway. I can ping the OPNsense host at 192.168.1.1 from 192.168.6.2.

The "dongle" is a "pocketbeagle" running Debian: https://beagleboard.org/pocket. It runs its own DHCP server, and is configured to create its own network.