Recent posts

#1
General Discussion / Re: Device Monitor - a tool fo...
Last post by hacesoft - Today at 10:13:28 AM
Quote from: mooh on April 21, 2026, 10:01:40 PM
Quote from: hacesoft on April 21, 2026, 06:51:56 PMNot every plugin is for everyone — install what fits your needs. 🙂
I didn't mean to belittle your effort. In fact, I appreciate every effort to improve OPNsense.

I just not sure what the size of the target audience for all this host discovery stuff is, yours and the new component of OPNsense. If I want to know what's going on on my network, I ask it directly via SNMP or an all-in-one solution like Unifi or Omada. Only small, unmanaged networks don't already provide that functionality. How many are there using OPNsense?

Hello, I recently switched from pfSense to OpnSense and this option was standard in the system and I use it to check if an uninvited guest is connecting. Or when I connect a device, I find out its IP address. I don't have unifi, or rather I only use AP AC RL and I have a classic L2, L3 switch. So OpnSense will provide me with the necessary information :). I originally wrote the plugin just for myself, but I decided to share it with others... I would like the plugin to be offered as a standard package, but that's too much for me for now :).
#2
General Discussion / Re: Device Monitor - a tool fo...
Last post by hacesoft - Today at 10:07:17 AM
Quote from: SteffenDE on April 23, 2026, 07:49:14 AM
Quote from: hacesoft on April 21, 2026, 06:38:33 PMHi Steffen,
The hostname field works as follows: the plugin pulls the hostname from Services → ISC DHCPv4 / DHCPv6 → DHCP Static Mappings — specifically the Hostname field for each entry. If a device doesn't have a static mapping with a hostname defined there, the field will simply remain empty, as the plugin has no other automatic source for this information.
You can also fill in the hostname manually directly in the plugin, but note that this is stored only in the plugin's own database — it does not propagate back to OPNsense DHCP or any other system.
So the short answer: populate the Hostname field in your DHCP static mappings and it will appear automatically.

I have hostnames defined at Dnsmasq because I think ISC is deprecated. So it would be nice to support Dnsmasq too.
Good day, I just converted my home network from ISC to DNSmasq and it will take a while before I get to it and modify the plugin. but don't worry, it will happen :).
#3
General Discussion / Re: Device Monitor - a tool fo...
Last post by hacesoft - Today at 10:04:40 AM
Quote from: pc44 on April 23, 2026, 09:42:44 PM
Quote from: pc44 on April 23, 2026, 04:26:58 AMI have an older version of Device Monitor installed and working.  It is great !!!

I am happy with it, but is there a way to update to this new version, or do I need to fully uninstall/reinstall?

Thank you.

Figured it out.  Deleted the existing /tmp/opnsense-devicemonitor folder.  Then downloaded, unzipped, and copied over the new files.  Then just re-ran sh install.sh.

Now up-to-date. ☑️
Good day, exactly as you asked. If you use sh install.sh, everything except the database will be deleted before installation. After installation, the plugin will be started again. If you use sh uninstall.sh, everything will be removed.
#4
26.1, 26,4 Series / dpd_action = start
Last post by humnab - Today at 07:57:39 AM
Hello,

in the OPNsense GUI we have:

Start, Clear, Trap for DPD Action, Start sets:

/usr/local/etc/swanctl/swanctl.conf

dpd_action = start

But this is not a valid option for dpd_action, it the documentation ist correct:

https://docs.strongswan.org/docs/latest/swanctl/swanctlConf.html

Action to perform for this CHILD_SA on DPD timeout. The default clear closes the CHILD_SA and does not take further action. trap installs a trap policy, which will catch matching traffic and tries to re-negotiate the tunnel on-demand (note that this is redundant if start_action includes trap. restart immediately tries to re-negotiate the CHILD_SA under a fresh IKE_SA.


So it should be changed to restart?
#5
26.1, 26,4 Series / OpenVPN - Via UDP no routing
Last post by PotatoCarl - Today at 07:56:15 AM
Hi

I have since some time a problem with OpenVPN:
I have setup 4 legacy servers on two outside WAN lines.
- WAN is coming in via fixed IPs on FritzBoxes -> Forward Host (OpnSense).
- Two OpenVPN Servers (legacy), one UDP 1194, the other 1195, each bound to a different WAN
- Two OpenVPN Servers (legacy), Port 443 TCP, one to each WAN line

When I connect via UDP I get a connection. That means IMHO that the OpenVPN is setup correctly so far.
However, I cannot do any name resolution (time out), ping to any computer in the connected network etc.
Basically I get "VPN connected" and get "offline".

When I connect to the Port 443 VPN it works almost fine (see below), i.e. on any Linux PC everything works perfectly as expected. On Android, too.

I tried various firewall rules (I don't think I changed anything to stop working, as I use the VPN daily I should have noticed instantly) either using the OpenVPN nets directly, an Alias with all combined, or the OpenVPN_Network presetting. Nothing changes anything, on the UDP line it does not seem to get routed.

All OpenVPNs have set the DNS to the real IP of the OpenSENSE (which runs unbound), not any guessed IP from the OpenVPN network.

As I have the update to the new network ahead of me, I'd prefer to get the UDP running to translate "port by port" to the configuration and switch off "seamless" the system instead cutting off all remote VPN users all at once.

Any ideas, any one? Am I missing a "new" firewall rule that is mandatory here and might have been introduced even a couple of major versions ago that stopped working suddenly?

Firewall live view BTW does not show anything blocked, making it more confusing, unbound does not show a connection attempt.

Thanks for any ideas where to look.
#6
I see, either way makes sense. It seems like I could implant the CPU type in the PLUGIN_VARIANT variable by deducing it from dmesg output, but that would probably be brittle, even if it can run early enough.
#7
Quote from: pfry on April 07, 2026, 05:03:58 PMTaxes = vaporized (yet somehow still alive and aware), but hey, those are inevitable.
That's because you are paying the taxes that the likes of Musk, Zuckerberg and Trump do not pay.
#8
After looking at some packet dumps it seems like there are at least two methods of sending the boot file name. Obviously, KEA and udhcpd use different ones, apart from ordering packet options differently.
KEA sends: ... 43 0b 2f 70 78 65 6c 69 6e 75 78 2e 30 ff 63 ...
which translates to "/pxelinux.0" but as you can see, there is an "ff" at the end. This is not a null-terminated string, instead the string length is prefixed, "0b" (decimal 11) in this case.
The decoded packet reads:
e.e.e.e.67 > 255.255.255.255.68:  xid:<censored> flags:0x8000 Y:c.c.c.c S:b.b.b.b ether <censored> vend-rfc1048
DHCP:OFFER SM:255.240.0.0 DG:g.g.g.g NS:e.e.e.e DN:"local" LT:3116 SID:e.e.e.e BF:"/pxelinux.0" (DF) [tos 0x10]
udhcpd sends: ... 00 00 2f 70 78 65 6c 69 6e 75 78 2e 30 00 00 ...
which, again, translates to "/pxelinux.0" but is surrounded by all zeros so it is, intentionally or not, a null-terminated string.
The decoded packet reads:
e.e.e.e.67 > 255.255.255.255.68:  xid:<censored> flags:0x8000 Y:c.c.c.c S:b.b.b.b ether <censored> sname "<censored>" file "/pxelinux.0" vend-rfc1048
DHCP:OFFER SID:e.e.e.e LT:864000 SM:255.240.0.0 DG:g.g.g.g NS:e.e.e.e DN:"local"

So while KEA passes the filename in a "BF" parameter, udhcpd supplies it in a "file" parameter.

So, given the correct string length passed by KEA it seems like the bug is in the nVidia boot agent, which, of course, is the worst possible outcome because that means that these will never work with KEA.
I might find a way to make KEA send a "file" parameter instead of the "BF", hoping that it will also surround it by zeros or that it will just be implemented properly. More likely I'll ditch KEA for Dnsmasq because naturally I want a solution that works in all cases. The only upside of this is that now I know it.
Quote from: nero355 on April 24, 2026, 03:39:20 PMWould it be an option to have a dedicated PXE Boot VLAN on your network ?

In the past I have worked for a company that had this and the software doing the PXE Boot stuff was some kind of dedicated Linux distro at the time.
So in this case OPNsense would be just the Router providing internet access for all those NetBoot images :)
That would be an excellent option for actual thin clients, as this kind of boot is quite insecure and should ideally be confined even on the LAN.
However, I use PXE for all sorts of things except thin clients. :) (my infrastructure is not robust enough; to depend on it, I'd need HA first) Like initial / post-modification memtest86+ tests and serving the OS installers (debian netinstall), and that can potentially be every machine (except the TFTP server itself, of course). That way, I don't have to fiddle with USB sticks and can apply the same procedure to other peoples machines if need be. :) That's why I need it to "always work", as the type of client is not forseeable. One thing I still need to figure out is how to chainload the BSD bootloader from pxelinux (which provides the menu). Is there some sort of "GRUB" for PXE?
#9
General Discussion / Re: How do IPv6 Router Adverti...
Last post by barney - Today at 01:45:38 AM
Quote from: mooh on April 23, 2026, 01:41:32 PMThis is where I don't understand what you're looking for.
I'm not looking for anything any more - my stuff is all working. I'm continuing the discussion trying to answer questions and maybe explain my setup in case it helps anyone else in the future, and happy to keep doing that if it is useful.

As I understand the situation I have 3 separate networks involved:

  • VLAN 20 - fdb4:66c9:5838:20::/64 - containing the OpenHab server.
  • VLAN 40 - fdb4:66c9:5838:40::/64 - containing the Dirigera TBR and other direct ethernet / WiFi IoT Devices.
  • Thread - fd2c:d79a:65f9:1::/64 - Thread Mesh-Local network containing the Matter devices.
 
These are all separate networks and require L3 routing for traffic to move between them.

The communications I need to happen are:

  • Discovery (3 -> 1): devices on the Thread network need to be discoverable from the OpenHab server.
  • Control (1 -> 3): The OpenHab server needs to send messages to the devices on the Thread network.

For the Discovery stage:

  • The Thread device registers itself with the Dirigera TBR.
  • The Dirigera broadcasts an mDNS message, which includes the Mesh-Local IPv6 address of the device.
  • The mdns-bridge running on OPNsense reflects that message from VLAN 40 to VLAN 20.
  • The OpenHab server gets the mDNS message and registers a device with its Mesh-Local IPv6 address.

For the Control stage:

  • The OpenHab server sends a message to the device's Mesh-Local IPv6 address.
  • The OPNsense gateway / static route sends this to the Dirigera TBR.
  • The Dirigera TBR routes this to the end device.

So the two highlighted steps (Discovery 3, Control 2) are the ones I needed to add.

If my OpenHab server itself was in VLAN 40 then I would not need anything extra - the Router Advertisement the Dirigera publishes would suffice (Note: this is an assumption - I've not tried putting OpenHab on the IoT VLAN so don't know for sure).

When I initially asked this question my thinking was that I needed to get the RA published on VLAN 40 across to VLAN 20 somehow and that would complete the route for the control messages. However, creating the gateway / static route was the actual solution, and it is all working exactly how I want it now.

Final note is that the IKEA Dirigera operates both as a Matter Bridge and as a Thread Border Router. I am only using it as a TBR. If you are using it as a Matter Bridge then the OpenHab server only ever needs to talk to the Dirigera - never directly to the devices on the Thread network.

#10
Quote from: pavlon1988 on February 27, 2026, 08:07:45 AMа чем они ещё вкрячиваются ?))
например, использую штатные средства опнсенсе а не прямое редактирование конфига?