Recent posts

#1

Development and Code Review / Re: netflector available as pl...

Last post by UnicronHD - Today at 04:43:03 AM

@RamSense

Next iteration is ready. Binary:
https://drive.google.com/uc?export=download&id=1FPDtVM_e-lk2ygqvrxRcMZ9HWt5kVZ_P

SHA256:
e0b0c32a9f062c36c29ddc7cf193ae984e59fc5215ee05167391f3e14cc2f3b4

I've added support for source_peers and target_peers (will be used for source_if and target_if correspondingly). The idea is not to open a fake socket, but to actually fake multicast over WireGuard by delivering unicast messages to peers. Which means discovery in the other direction should properly work. We'll see how it goes :)

If we assume that your WireGuard interface is target_if, then you need to add target_peers with the IP of your phone (or multiple IPs if you have more than one road warrior). Something like this:

Code Select Expand

log_level = "info"

# Roon for road warriors: the server on the LAN, the phones behind WireGuard.
# wg0 has no broadcast domain, so the server's discovery (multicast and
# broadcast on 9003) goes to each listed peer as a unicast copy instead.
[reflectors.roon-remote]
source_if = "igc0"                # the LAN interface, as ifconfig names it
target_if = "wg0"                 # the WireGuard interface
target_peers = ["10.10.10.2"]     # every road-warrior address that should see the server; add more as needed
udp_ports = [9003]
udp_groups = ["239.255.90.90"]
udp_broadcast = true
bidirectional = true

NOTE: peers should work with almost all protocols, not only UDP relay. The only exception is mDNS. It will not accept source_peers, and no peers at all if bidirectional=true. mDNS via WireGuard is a different topic though. RFC requires multicast responses to multicast queries, which we cannot do. I have some ideas, but this I can try myself, after we figure Roon out.

#2

Hardware and Performance / Re: Mono Gateway (an NXP-based...

Last post by ImposingLlama - Today at 03:43:20 AM

Yes, I have one and it does indeed run OPNsense. Hardware offloading is supported and really sets it apart from anything I've seen before. And yes, it can offload connections which are firewalled by pf. Pretty impressive.

I recommend watching Tomaž's latest video on YouTube.

Cheers
Maurice

Full disclosure: I've been contracted by Mono to maintain their OPNsense update server.

Do you happen to know when the server will be back up?

[isolated network]

#3

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

Last post by lmoore - Today at 03:39:31 AM

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

25.1 and earlier.

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

Yes, this seems to be a standard installation.

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'm still using the Legacy ISC DHCP server on 26.7 and I've not had to make any changes to keep it running after upgrading. I will migrate to Kea down the track.

1. [QUESTION] I've only got a single network, and it's a fairly small one; ...  Would this setup be what you characterized as an "isolated network"??  If there's a simpler/better method, please let me know.

No. You may be able to apply your configuration when installing from media on the Backup machine, which may ease the change. Refer to the OPNsense Importer documentation to import a configuration file at installation time - https://docs.opnsense.org/manual/install.html#opnsense-importer

Here are some suggestions:

Primary machine:

Perform a configuration back-up including RRD data.

Copy the configuration file to the conf directory on a USB stick per the OPNsense Importer instructions.

Backup machine:

Download and prepare installation media for OPNsense 25.1 or earlier.

Consider using ZFS for the file system as using Snapshots is easy.

Disconnect network cables.

Ensure BIOS is configured for UEFI mode.

Installation Choices - YMMV

Boot the installation image and follow the steps;

 1) listed under For new installations or migrations, follow this process: in https://docs.opnsense.org/manual/install.html#opnsense-importer and then log in as installer to commit it to the Hard Drive.

 2) performed using https://opnsenselab.com/posts/opnsense-initial-setup-guide/



Substitute machines and test.

I'll iterate:

• Resolve plugin conflicts using the latest update of the first installed version of OPNsense, e.g. 25.1.12.
• Repeat the configuration back-up prior to each major version upgrade.
• When you get to 26.1.11, make sure you perform the firewall rules migration prior to upgrading to 26.7.
• If you get to version 26.7, ensure you update your Boot Loader - Refer to https://forum.opnsense.org/index.php?msg=271899

HTH - I think you're getting there.

#4

26.7 Series / Re: Crashes, and Kea DHCP Serv...

Last post by computer_freak_8 - Today at 03:34:50 AM

How about a nice smartctl -a /dev/<whatever> output ? :)

And maybe run memtest86+ from your favorite Linux Live ISO Boot Image on a USB Stick for at least 24 hours ?

Any tips on how to get smartctl to run? Apparently admins don't have sudo permissions, and running without sudo yields permissions errors. (Smartctl open device: /dev/ada0 failed: Permission denied)
Suppose I can do that from a live USB as well, if needed. Will definitely be a bit since I'll need to build a temporary box to cutover to in the meantime.

[It is true that at least in standard implementations up until now there is no order of precedence at the client side. The resolver library (the piece of software doing the lookups) uses all configured servers in round-robin fashion.]

#5

26.7 Series / Re: Problem where fallback DNS...

Last post by nero355 - Today at 12:37:08 AM

That's also not quite correct. Primary/secondary is an attribute assigned to authoritative DNS servers. The primary for a zone is where the zone is maintained by whatever method. The secondary pulls zone updates from the primary.

That's a whole different story ofcourse :)

My target was this stuff :

It is true that at least in standard implementations up until now there is no order of precedence at the client side. The resolver library (the piece of software doing the lookups) uses all configured servers in round-robin fashion.
That's why you do not necessarily need CARP but you need consistency of all your configured recursive servers.

E.g. 2 Active Directory domain controllers will always return the same data for your internal domain. That's a perfectly fine setup.

But one internal DC and 1.1.1.1 is nonsense because the latter has no knowledge of your internal domain.
And they will both be used.

There is no fallback concept in DNS clients.

And I fully agree with you ;)

#6

26.7 Series / Re: Crashes, and Kea DHCP Serv...

Last post by nero355 - Today at 12:33:40 AM

Not sure what other hardware information is relevant without being able to see/have more detailed logs or something specific to troubleshoot/change.

How about a nice smartctl -a /dev/<whatever> output ? :)

And maybe run memtest86+ from your favorite Linux Live ISO Boot Image on a USB Stick for at least 24 hours ?
If you see errors very shortly after starting it you can stop ofcourse!

#7

26.7 Series / Re: How does new firewall rule...

Last post by nero355 - Today at 12:24:20 AM

The major new feature in version 26.7 is the new firewall rules and I'm still used to the old way how firewall rules were working.

IMHO just the webGUI is different and everything works pretty much the same way, but with added information/clarity compared to the old webGUI :)

Reading the documentation linked in the reply above this one by @passeri should be all you need to know.

#8

26.7 Series / Re: Crashes, and Kea DHCP Serv...

Last post by computer_freak_8 - Today at 12:21:52 AM

perhaps signs of a hardware problem. Perhaps you could tell what hardware is involved.

It's a generic mini-PC; if there's a spot to a hardware report or something that would be useful, I can post that, but I didn't find anything while poking through the webUI menus. It would be great if there were better logs in OPNsense to help troubleshoot the issues.

This machine is not as easy to disassemble and would require significant downtime to do so, hence the lesser detail on hardware specs than the other post. Based on the dashboard, looks like 8GB RAM, 100 GB SSD, load averages 0.60, 0.42, 0.30. Not sure what other hardware information is relevant without being able to see/have more detailed logs or something specific to troubleshoot/change.

#9

26.7 Series / Re: Problem where fallback DNS...

Last post by Patrick M. Hausen - Today at 12:08:11 AM

That's how DNS works for everyone and the whole Primary/Secondary DNS Server thing is basically a big fat lie : DNS does not work that way! ;)

That's also not quite correct. Primary/secondary is an attribute assigned to authoritative DNS servers. The primary for a zone is where the zone is maintained by whatever method. The secondary pulls zone updates from the primary.

It is true that at least in standard implementations up until now there is no order of precedence at the client side. The resolver library (the piece of software doing the lookups) uses all configured servers in round-robin fashion. That's why you do not necessarily need CARP but you need consistency of all your configured recursive servers.

E.g. 2 Active Directory domain controllers will always return the same data for your internal domain. That's a perfectly fine setup.

But one internal DC and 1.1.1.1 is nonsense because the latter has no knowledge of your internal domain. And they will both be used. There is no fallback concept in DNS clients.

#10

26.7 Series / Re: Crashes, and Kea DHCP Serv...

Last post by cookiemonster - September 12, 2026, 11:31:00 PM

perhaps signs of a hardware problem. Perhaps you could tell what hardware is involved. The linked thread has a lot of realtek stuff on it, it might still be the source of problems but is impossible to tell here without basic details provided. It could be almost anything.