Messages

Thanks, @meyergru and @Monviech (Cedrik). The issues have been resolved with v0.4.5 of the OPNsense integration "hass-opnsense".

Yes, see: https://forum.opnsense.org/index.php?topic=48092

Oh, thanks for pointing me to this post!

If I understand it correctly, adjustments would be needed on the side of the Home Assistant integration and plugin. Correct?

Have there been any changes introduced with v25.7 concerning API permissions?

I run the OPNsense integration "hass-opnsense" with Home Assistant that connects to OPNsense via API. Additionally, I have installed the respective OPNsense plugin "os-homeassistant-maxit".

Until the update to v25.7 the integration via API went flawlessly. But now several entities don't get updated anymore. The OPNsense "Backend" log is full of API errors:

Code Select Expand

2025-07-26T12:27:30Errorapiuri /api/diagnostics/system/systemInformation not accessible for user hass using api key xxxyyyyzzz
2025-07-26T09:34:42Errorapiuri /api/diagnostics/system/systemTemperature not accessible for user hass using api key xxxyyyyzzz
2025-07-26T09:34:42Errorapiuri /api/diagnostics/system/systemDisk not accessible for user hass using api key xxxyyyyzzz
2025-07-26T09:34:40Errorapiuri /api/diagnostics/system/systemTime not accessible for user hass using api key xxxyyyyzzz
2025-07-26T09:34:39Errorapiuri /api/diagnostics/system/systemResources not accessible for user hass using api key xxxyyyyzzz
2025-07-26T09:34:37Errorapiuri /api/diagnostics/system/systemInformation not accessible for user hass using api key xxxyyyyzzz
2025-07-26T09:34:01Errorapiuri /api/diagnostics/system/systemTemperature not accessible for user hass using api key xxxyyyyzzz
2025-07-26T09:34:01Errorapiuri /api/diagnostics/system/systemDisk not accessible for user hass using api key xxxyyyyzzz
2025-07-26T09:33:58Errorapiuri /api/diagnostics/system/systemTime not accessible for user hass using api key xxxyyyyzzz
2025-07-26T09:33:57Errorapiuri /api/diagnostics/system/systemResources not accessible for user hass using api key xxxyyyyzzz
2025-07-26T09:33:55Errorapiuri /api/diagnostics/system/systemInformation not accessible for user hass using api key xxxyyyyzzz
2025-07-26T09:33:19Errorapiuri /api/diagnostics/system/systemTemperature not accessible for user hass using api key xxxyyyyzzz
2025-07-26T09:33:19Errorapiuri /api/diagnostics/system/systemDisk not accessible for user hass using api key xxxyyyyzzz
2025-07-26T09:33:17Errorapiuri /api/diagnostics/system/systemTime not accessible for user hass using api key xxxyyyyzzz
2025-07-26T09:33:16Errorapiuri /api/diagnostics/system/systemResources not accessible for user hass using api key xxxyyyyzzz
2025-07-26T09:33:14Errorapiuri /api/diagnostics/system/systemInformation not accessible for user hass using api key xxxyyyyzzz
2025-07-26T09:32:38Errorapiuri /api/diagnostics/system/systemTemperature not accessible for user hass using api key xxxyyyyzzz
2025-07-26T09:32:38Errorapiuri /api/diagnostics/system/systemDisk not accessible for user hass using api key xxxyyyyzzz
2025-07-26T09:32:36Errorapiuri /api/diagnostics/system/systemTime not accessible for user hass using api key xxxyyyyzzz
2025-07-26T09:32:35Errorapiuri /api/diagnostics/system/systemResources not accessible for user hass using api key xxxyyyyzzz
2025-07-26T09:32:33Errorapiuri /api/diagnostics/system/systemInformation not accessible for user hass using api key xxxyyyyzzz
2025-07-26T09:31:57Errorapiuri /api/diagnostics/system/systemTemperature not accessible for user hass using api key xxxyyyyzzz
2025-07-26T09:31:57Errorapiuri /api/diagnostics/system/systemDisk not accessible for user hass using api key xxxyyyyzzz
2025-07-26T09:31:55Errorapiuri /api/diagnostics/system/systemTime not accessible for user hass using api key xxxyyyyzzz
2025-07-26T09:31:54Errorapiuri /api/diagnostics/system/systemResources not accessible for user hass using api key xxxyyyyzzz
2025-07-26T09:31:52Errorapiuri /api/diagnostics/system/systemInformation not accessible for user hass using api key xxxyyyyzzz
2025-07-26T09:31:17Errorapiuri /api/diagnostics/system/systemTemperature not accessible for user hass using api key xxxyyyyzzz
2025-07-26T09:31:16Errorapiuri /api/diagnostics/system/systemDisk not accessible for user hass using api key xxxyyyyzzz
2025-07-26T09:31:14Errorapiuri /api/diagnostics/system/systemTime not accessible for user hass using api key xxxyyyyzzz
2025-07-26T09:31:13Errorapiuri /api/diagnostics/system/systemResources not accessible for user hass using api key xxxyyyyzzz
2025-07-26T09:31:11Errorapiuri /api/diagnostics/system/systemInformation not accessible for user hass using api key xxxyyyyzzz


I just opened a new issue in GitHub:

https://github.com/opnsense/core/issues/8954

You are absolutely right - still I believe you are missing my point here:

I just checked again. If I remove all selections in the ,,Interface" drop-down field, it jumps back to the standard text/label displaying ,,All". And this is definitely wrong, because then no interface is selected to be active - and no firewall rules will be added - even if the setting  ,,DHCP register firewall rules" is checked. This is even more confusing.

Instead the standard text/label of the ,,Interface" drop-down field should display ,,None". Then it is absolutely clear, that currently no interface is selected to be active.

This would be an easy fix.

Interface

Interface IPs used to responding to queries from clients. If an interface has both IPv4 and IPv6 IPs, both are used. Queries to other interface IPs not selected below are discarded. The default behavior is to respond to queries on every available IPv4 and IPv6 address.

Looking at the OPNsense documentation Dnsmasq DNS & DHCP this is imho not entirely clear. Maybe it should be added, that the relevant interfaces must be explicitly selected and the selection must not be "All".  This information would have helped me a lot. What do you think?

I cannot see a line like this

interface=vlan0.1,vlan0.2

Can you check "Services: Dnsmasq DNS & DHCP: General: Default: Interface" and choose the interfaces there that DHCP should work on?

In your case igb1. That also generates the DHCP firewall rules.

You are my hero! Choosing "LAN" as interface did the trick. But why doesn't it work if it is set to "All"? Is this intentional?

Here it is - my little nightmare.

Code Select Expand

# DO NOT EDIT THIS FILE -- OPNsense auto-generated file
#

rebind-localhost-ok
stop-dns-rebind

# This tells dnsmasq that a domain is local and it may answer queries from /etc/hosts
# or DHCP but should never forward queries on that domain to any upstream servers.
local=/xxxx.yyy/

# host entries flushed via dnsmasq_watcher.py [isc] and a dump of the static reservations
addn-hosts=/var/etc/dnsmasq-hosts
addn-hosts=/var/etc/dnsmasq-leases

dns-forward-max=5000
cache-size=10000
local-ttl=1

conf-dir=/usr/local/etc/dnsmasq.conf.d,*.conf

dhcp-range=tag:igb1,192.168.0.1,192.168.0.99,86400

domain=xxxx.yyy,192.168.0.1,192.168.0.99

dhcp-host=xx:xx:xx:xx:24:21,192.168.0.101,host1
dhcp-host=xx:xx:xx:xx:8e:7f,192.168.0.102,host2
dhcp-host=xx:xx:xx:xx:ba:5e,192.168.0.106,host3
dhcp-host=xx:xx:xx:xx:ca:1c,192.168.0.110,host4
dhcp-host=xx:xx:xx:xx:8a:1e,192.168.0.111,host5
dhcp-host=xx:xx:xx:xx:25:6e,192.168.0.112,host6
dhcp-host=xx:xx:xx:xx:72:df,192.168.0.113,host7
dhcp-host=xx:xx:xx:xx:d9:d4,192.168.0.103,host8
dhcp-host=xx:xx:xx:xx:16:cb,192.168.0.109,host9
dhcp-host=xx:xx:xx:xx:1d:e6,192.168.0.253,accesspoint

dhcp-option=3,192.168.0.254
dhcp-option=6,192.168.0.254
dhcp-option=15,xxxx.yyy
dhcp-option=81
dhcp-option=42,192.168.0.254
dhcp-option=1,255.255.255.0



no-ident

You are right again - frustration is never a good companion. Couldn't help it though.

Anyway, I am currently trying again. Unfortunately, with the same result. I simply can't get DHCP to serve my hosts. They won't get an IP assigned, only 169.x.x.x.

I have a 192.168.0/24 network with .253 assigned to my access point. Did I miss something to enable on the DHCP side in order to serve the hosts querying through the AP?

As soon as a dhcp-range is defined in dnsmasq, it will try to bind port 67 to either all interfaces, or the interfaces defined with the strict interface setting in advanced mode.

no dhcp will just ignore DHCP packets, but it will not unbind from port 67 as long as there are defined dhcp-ranges.

You were right. I needed the better part of yesterday's (late) evening to confirm this. Btw: Is this behavior intentional? It seems a bit unintuitive not to say awkward tbh.

Anyway, at first, I tried to finish my half-baked migration from ISC DHCPv4 to dnsmasq DNS & DHCP, but although following the documentation by the word, recreating all hosts, DHCP ranges and DHCP options, I ended up in a complete mess. dnsmasq's DNS & DHCP service was running, debug logs were flawless, but it persistently failed to serve my hosts - whether connecting via LAN or WLAN. I must have checked, set and unset the [no dhcp] flags at least a dozen times, I restarted the service, I restarted the firewall. Nothing. Around midnight my frustration had grown that big, that I have eradicated all changes made to dnsmasq DNS & DHCP and set the [no dhcp] flags again for all adapters. So, I could at least confirm your solution.

Now I am running again my rock solid ISC DHCPv4 + dnsmasq combination - either I am simply too untalented or the dnsmasq DNS & DHCP service is really as confusing to configure and troubleshoot as it feels.

As soon as a dhcp-range is defined in dnsmasq, it will try to bind port 67 to either all interfaces, or the interfaces defined with the strict interface setting in advanced mode.

no dhcp will just ignore DHCP packets, but it will not unbind from port 67 as long as there are defined dhcp-ranges.

Thanks, that must be it! I have had a DHCP-range defined, because I wanted to switch from ISC-DHCP to dnsmasq-DHCP some time ago. I have stopped in midcourse and have left the DHCP-range as defined. I just have set [no dhcp] for all interfaces.

So I guess I will spend this evening and finally finish what I have started... ;-)

Unfortunately the issue persists after a reboot.

I just updated to 25.1.11 and my network is shot. Dnsmasq service won't start, throwing the error ,,failed to bind DHCP Server socket: Address already in use".

It tries to bind its DHCP socket although all interfaces are configured [no dhcp] within Dnsmasq Gerneral settings. I still use ISC DHCPv4, hence the conflict.

I guess this might be a bug in this release. Anyone else experiencing this?

Maybe they are guarded by their hosts-firewalls?

Thanks for the suggestion, but no. The firewall rules are not the issue.

ChatGPT pointed me to the solution:

Code Select Expand

Adjust WireGuard Peer Configurations

On each WireGuard client (peer), check the AllowedIPs setting:
Change AllowedIPs = 0.0.0.0/0 (or similar) to include the LAN network:

     AllowedIPs = 192.168.0.0/24, 0.0.0.0/0

This ensures that traffic destined for 192.168.0.0/24 is sent through the VPN tunnel.
Restart the WireGuard client after making the changes.
Adding 192.168.0.0/24 to AllowedIPs did the trick.

Dear all,

Coming from a years-old OpenVPN setup, I just have configured WireGuard. I followed the "WireGuard Road Warrior Setup" installation guide and successfully completed the setup. I have one instance and two peers connecting flawlessly from LAN and WAN, including the firewall rule for peers to access the Internet.

However, there is still one task open. My WireGuard service uses the private network 192.168.1.0/24 and my LAN uses the private network 192.168.0.0/24. While the WireGuard peers can access the Internet, they cannot access any of my LAN services. I tried several firewall rules with the LAN and WireGuard interfaces, but no success so far. I had a similar setup with OpenVPN working, using two separate private networks.

I know the solution must be rather trivial, but I simply don't get to it. Could you please help me out?