Messages

[Other observations]

@meyergru I don't know if it is a firewall issue, but this behaviour started when opnsense was installed.

@Patrick M. Hausen I will try to packet trace the homeassistant container.

@Linwood Reverting to the original router is possible but disruptive. Let me address your other points:

1. IGMP Proxy on WAN and LAN & Reverse Proxy
I installed the IGMP Proxy, mDNS Repeater, UDP Broadcast Relay, and Universal Plug and Play plugins to get Sonos and Spotify working on my network. They may not be configured correctly, as I only have a WAN and LAN interface active. They may not be needed, as I have floating rules for the various ports needed. Access to Home Assistant is configured to be local. All clients will use the internal IP addresses when connected to the local network.

2. MQTT
The issue is always that Home Assistant fails to connect to MQTT - all the other services that use MQTT report no issues (double-take, frigate, teslamate, zigbee2mqtt, zwave).

3. Zigbee issues
I removed Zigbee Home Assistant (ZHA) and migrated to zigbee2mqtt. This removed the ZHA errors, which I think were a red herring. I suspect some traffic ws blocked and that caused a timeout in the ZHA module.

Other observations

Uptime Kuma, running locally on the same host as Home Assistant, can see that Home Assistant stops responding multiple times.

System : Routes : Log Files notes the following:

Code Select Expand

2025-10-20T09:03:39-06:00 Warning miniupnpd SSDP packet sender 198.53.116.247:51405 (if_index=1) not from a LAN, ignoring
2025-10-20T09:03:32-06:00 Warning miniupnpd SSDP packet sender 198.53.116.247:45970 (if_index=1) not from a LAN, ignoring
2025-10-20T09:02:46-06:00 Warning miniupnpd SSDP packet sender 198.53.116.247:52417 (if_index=1) not from a LAN, ignoring
2025-10-20T09:02:46-06:00 Warning miniupnpd SSDP packet sender 198.53.116.247:52417 (if_index=1) not from a LAN, ignoring
2025-10-20T09:02:45-06:00 Warning miniupnpd SSDP packet sender 198.53.116.247:52417 (if_index=1) not from a LAN, ignoring
2025-10-20T09:01:05-06:00 Warning miniupnpd SSDP packet sender 198.53.116.247:49463 (if_index=1) not from a LAN, ignoring
2025-10-20T09:01:05-06:00 Warning miniupnpd SSDP packet sender 198.53.116.247:49463 (if_index=1) not from a LAN, ignoring
2025-10-20T09:01:05-06:00 Warning miniupnpd SSDP packet sender 198.53.116.247:49463 (if_index=1) not from a LAN, ignoring
2025-10-20T09:01:03-06:00 Warning miniupnpd SSDP packet sender 198.53.116.247:45605 (if_index=1) not from a LAN, ignoring
2025-10-20T09:01:03-06:00 Warning miniupnpd SSDP packet sender 198.53.116.247:45605 (if_index=1) not from a LAN, ignoring
2025-10-20T09:01:02-06:00 Warning miniupnpd SSDP packet sender 198.53.116.247:45605 (if_index=1) not from a LAN, ignoring
2025-10-20T09:00:38-06:00 Warning miniupnpd SSDP packet sender 198.53.116.247:60255 (if_index=1) not from a LAN, ignoring
2025-10-20T09:00:38-06:00 Warning miniupnpd SSDP packet sender 198.53.116.247:60255 (if_index=1) not from a LAN, ignoring
2025-10-20T09:00:38-06:00 Warning miniupnpd SSDP packet sender 198.53.116.247:60255 (if_index=1) not from a LAN, ignoring
2025-10-20T09:00:07-06:00 Warning miniupnpd SSDP packet sender 198.53.116.247:44025 (if_index=1) not from a LAN, ignoring
2025-10-20T09:00:06-06:00 Warning miniupnpd SSDP packet sender 198.53.116.247:34690 (if_index=1) not from a LAN, ignoring
2025-10-20T08:58:39-06:00 Warning miniupnpd SSDP packet sender 198.53.116.247:51405 (if_index=1) not from a LAN, ignoring
2025-10-20T08:58:32-06:00 Warning miniupnpd SSDP packet sender 198.53.116.247:45970 (if_index=1) not from a LAN, ignoring
2025-10-20T08:57:47-06:00 Warning miniupnpd SSDP packet sender 198.53.116.247:52417 (if_index=1) not from a LAN, ignoring
2025-10-20T08:57:46-06:00 Warning miniupnpd SSDP packet sender 198.53.116.247:52417 (if_index=1) not from a LAN, ignoring
2025-10-20T08:57:46-06:00 Warning miniupnpd SSDP packet sender 198.53.116.247:52417 (if_index=1) not from a LAN, ignoring

These are repeated many times.

I'll try a packet capture on the server that runs my services. I'll also enable debug logs on Home Assistant to see if there's anything that indicates a port, protocol, or ip that has an issue.

I used this guide to set up caddy for my opnsense installation. I have both external and internal domains. The FAQ states that:

Port Forwards, NAT Reflection, Split Horizon DNS or DNS Overrides in Unbound are not required. Only create Firewall rules that allow traffic to the default ports of Caddy.

My internal domains did not resolve until I added an override in unbound for *.example.com to 192.168.1.1 (my router address). This may be due to the changes in the base opnsense configuration since the guide was updated.

[Issue]

@meyergru All the endpoints are using ip addresses to avoid any DNS confusion, which leads me to assume the issue is a firewall one rather than a DNS one. The hostnames resolve to 192.168.1.91 because of the override in Unbound DNS which forwards all requests for example.com to my Traefik reverse proxy. To be clear, all inter-machine communication uses ip addresses and ports. There are no FQDNs or hostnames.

@cookiemonster I am using all multicast DNS plugins because without them Sonos wasn't working. I plan to slowly remove them and test to confirm what I actually need. I currently have:

• A set of floating rules to allow SSDP, mDNS, GDM, Plex, Sonos, Spotify, and Windows Sharing
• IGMP Proxy between WAN and LAN for all internal ip ranges
• mDNS Repeater between WAN and LAN
• UDP Broadcast Relay for SSDP, mDNS, GDM, and Sonos
• Universal Plug and Play allowing all UPnP IGD and NAT-PMP mappings by default

My goal is to replicate what I had with my commercial router before hardening things.

@Linwood A very good question, let me define the behaviour I am experiencing and hopefully it'll add clarity.

Issue
Web connection to Home Assistant fails every 40-60 seconds. Logs indicate a websocket issue.

Host
Intel NUC7CJYHN 16GB RAM 500GB SSD

Services

Service	IP and Port	MQTT Topic	HA Connection	Log Issues	Purpose
homeassistant	192.168.1.93:8123	homeassistant 192.168.1.93:1883	n/a	websocket related	home automation hub
mqtt	192.168.1.93:1883	n/a	any 192.168.1.93:1883	none	message broker
node-red	192.168.1.93:1880	192.168.1.93:1883	192.168.1.93:8123	none	visual automation engine
zigbee2mqtt	192.168.1.93:8321	zigbee2mqtt 192.168.1.93:1883	mqtt discovery	none	zigbee coordinator
zwave-js-ui	192.168.1.93:8091	zwave 192.168.1.93:1883	websocket 192.168.1.93:3000	none	zwave coordinator

All services are run in docker containers. All connections use host IP addresses and ports.

Behaviour
Since migrating from my Netgear router to opnsense, home assistant has been unstable. The ui will become unresponsive and restart multiple times.

Initial errors in the log files indicated timeouts, usually with the Zigbee Home Automation service.

Code Select Expand

homeassistant  | 2025-10-13T14:15:59.106199110Z bellows.ash.NcpFailure: NcpResetCode.ERROR_EXCEEDED_MAXIMUM_ACK_TIMEOUT_COUNT␛[0m
homeassistant  | 2025-10-13T14:15:59.229743107Z ␛[31m2025-10-13 08:15:59.184 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [140318389399968] Unexpected exception
homeassistant  | 2025-10-13T14:15:59.231156264Z bellows.ash.NcpFailure: NcpResetCode.ERROR_EXCEEDED_MAXIMUM_ACK_TIMEOUT_COUNT␛[0m
homeassistant  | 2025-10-13T14:15:59.465955299Z ␛[31m2025-10-13 08:15:59.464 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [140318389399968] Error during service call to light.turn_on: Failed to send request: ApplicationController is not running␛[0m
homeassistant  | 2025-10-13T14:17:52.757669048Z ␛[33m2025-10-13 08:17:52.751 WARNING (MainThread) [homeassistant.components.media_player] Updating webostv media_player took longer than the scheduled update interval 0:00:10␛[0m
homeassistant  | 2025-10-13T14:17:52.769933176Z ␛[33m2025-10-13 08:17:52.751 WARNING (MainThread) [homeassistant.helpers.entity] Update of media_player.lg_webos_tv_bedroom1 is taking over 10 seconds␛[0m
homeassistant  | 2025-10-13T14:17:52.919683463Z ␛[31m2025-10-13 08:17:52.910 ERROR (MainThread) [homeassistant.components.tautulli] Error fetching tautulli data: Request timeout for 'http://192.168.1.95:8282/api/v2?apikey=[REDACTED_API_TOKEN]&cmd=get_home_stats'␛[0m
homeassistant  | 2025-10-13T14:17:52.937803502Z ␛[33m2025-10-13 08:17:52.931 WARNING (MainThread) [zigpy.application] Watchdog failure
homeassistant  | 2025-10-13T14:17:53.302102073Z ␛[31m2025-10-13 08:17:53.301 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [140318389399968] Error during service call to light.turn_on: Failed to send request: ApplicationController is not running␛[0m


Troubleshooting
In an effort to resolve this, the following steps were taken:

• Add Firewall Floating Rule for ports 8123 and 1883 - no obvious impact
• Migrate from Zigbee Home Assistant to zigbee2mqqt - reduced errors in Home Assistant but did not change behaviour
• Change version of Home Assistant from latest to 2025.9 - no obvious impact

Current State
I am running Home Assistant 2025.9 in host networking mode. The web ui will work for 30-50 seconds then become unresponsive. The message "Connection lost. Reconnecting..." appears on the UI and 20-30 seconds later the page is responsive again.

@cookiemonster Services on the same server but different port is relatively standard and I am confirming that the same ip address and ports are accessible from the network prior to moving to opnsense and after stabilising with opnsense.

@Linwood I made sure everything uses ip addresses, but I will check that to confirm. Everything is in a docker container, and exposed via host ip and port. I appreciate your thought process, when you are inside a bug it's hard to step back.

I have 5 servers running Debian, each of which uses a static IP:

• edge1 - 192.168.1.91
• edge2 - 192.168.1.92
• services - 192.168.1.93
• security - 192.168.1.94
• media - 192.168.1.95

The routers (Netgear or opnsense) have never needed to issue an ip address, and do recognise the servers on the network.

opnsense is using unbound and dnsmasq for DNS and DHCP. I've tried to change this to using my two pi-holes but it fails each time, that's a separate issue.

opnsense is configured to:

• use domain home.arpa
• have no specified dns servers
• serve the web gui on port 8443

Unbound is configured to:

• Be Enabled
• Override example.com to 192.168.1.91 where traefik will reverse proxy requests

dnsmasq is configured to:

• Be Enabled
• Listen on LAN
• DHCP FQDN
• DHCP local domain
• DHCP register firewall rules
• Register the 5 servers under Hosts
• Server ip addresses in the range 192.168.1.100 to 192.168.1.245

Here's how dig resolves for the hostnames:

Code Select Expand

$ docker exec homeassistant dig +noall +answer homeassistant.example.com
homeassistant.example.com. 3600 IN A      192.168.1.91

$ docker exec homeassistant dig +noall +answer mqtt.example.com
mqtt.example.com. 3600    IN      A       192.168.1.91

$ dig +noall +answer homeassistant.example.com
homeassistant.example.com. 3600 IN A      192.168.1.91

$ dig +noall +answer mqtt.example.com
mqtt.example.com. 3600    IN      A       192.168.1.91

Here's how nc feels about the ports:

Code Select Expand

$ nc -vz 192.168.1.93 1883
services.example.com [192.168.1.93] 1883 (?) open

$ nc -vz 192.168.1.93 8123
services.example.com [192.168.1.93] 8123 (?) open

$ nc -vz 192.168.1.93 5000
services.example.com [192.168.1.93] 5000 (?) open

$ nc -vz 192.168.1.93 1880
services.example.com [192.168.1.93] 1880 (?) open

$ docker exec homeassistant nc -vz 192.168.1.93 1883
192.168.1.93 (192.168.1.93:1883) open

$ docker exec homeassistant nc -vz 192.168.1.93 8123
192.168.1.93 (192.168.1.93:8123) open

$ docker exec homeassistant nc -vz 192.168.1.93 5000
192.168.1.93 (192.168.1.93:5000) open

$ docker exec homeassistant nc -vz 192.168.1.93 1880
192.168.1.93 (192.168.1.93:1880) open

This is a real puzzler.

Prior to migrating from my Netgear router to opnsense, my configuration was solid and tested. Here's how it is set up:

• 192.168.1.93:1883 - MQTT
• 192.168.1.93:5000 - MQTT UI
• 192.168.1.93:8123 - Home Assistant
• 192.168.1.93:1880 - Node-Red

Home Assistant has an integration to MQTT using 192.168.1.93:1883

It's been stable for over 3 years. Shifting to opnsense has caused the errors in Node-Red and Home Assistant. The ip addresses have not changed. MQTT UI shows traffic from zwave-js-ui, frigate, teslamate, doubletake, and homeassistant.

Any suggestions on how I could troubleshoot the issue using the diagnostic tools in opnsense?

I upgraded from a Netgear Orbi RBR850 to opnsense. I'm running 25.7.5 with the following plugins:

• IGMP Proxy
• mDNS Repeater
• UDP Broadcast Relay
• Universal Plug and Play

In an effort to incrementally introduce complexity whilst focusing on stabilising my configuration, I am trying to replicate my previous network setup.

I have two interfaces:

• WAN - connects to a fibre ont
• LAN - connects to my unmanaged switch

My LAN contains a few servers with static IPs including my services server which hosts Home Assistant. Prior to moving to opnsense, Home Assistant was working with no issues. Since the upgrade the service is restarting with the same errors:

Code Select Expand

WARNING (MainThread) [zigpy.application] Watchdog failure
WARNING (MainThread) [zigpy.backups] Failed to create a network backup
ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved (None)
WARNING (MainThread) [bellows.thread] Attempted to use a closed event loop
ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [139864590888416] Unexpected exception
WARNING (MainThread) [py.warnings] /usr/local/lib/python3.13/asyncio/base_events.py:2035: RuntimeWarning: coroutine 'ClusterHandler.async_initialize' was never awaited
WARNING (MainThread) [py.warnings] /usr/local/lib/python3.13/asyncio/base_events.py:2051: RuntimeWarning: coroutine 'Device.async_initialize' was never awaited
ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [139864590888416] Error during service call to light.turn_on: Failed to send request: ApplicationController is not running
WARNING (MainThread) [homeassistant.components.mqtt.client] Error returned from MQTT server: The connection was lost.
ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [139864590888416] Error during service call to light.turn_on: Failed to send request: ApplicationController is not running
WARNING (MainThread) [zha.decorators] [<Task pending name='sensor_state_poller_00:0d:6f:00:05:42:89:88-1-2820_PolledElectricalMeasurement' coro=<periodic.<locals>.scheduler.<locals>.wrapper() running at /usr/local/lib/python3.13/site-packages/zha/decorators.py:92> cb=[set.remove()]>] Failed to poll using method [zha.application.platforms.sensor::PollableSensor._refresh]

These appear to indicate that the service can't see the mqtt server or the websocket, which is causing other components to fail.

I'd like to troubleshoot this but I'm not sure the best way to start. I've started Packet Capture on the server ip and port for Home Assistant but nothing seems to be included.

I am using OPNsense 25.7.4. I have two interfaces, WAN and LAN, with no VLANs or other bridged. I have Plex installed on a media server.

To get Plex working I performed the following steps:

1. Access System : Settings : Administration
   1.1. Web GUI : Protocol: HTTPS
   1.2. Web GUI : TCP port: 8443
   1.3. Web GUI : HTTP Redirect: checked
2. Access Firewall : Categories and click Add
   2.1. Colour: yellow
   2.2. Name: media
3. Access Firewall : Aliases and click Add
   3.1. Enabled: checked
   3.2. Name: server_media
   3.3. Type: Host(s)
   3.4. Category: media
   3.5. Content: ip address of media server
   3.6. Description: Media server
4. Access Firewall : NAT : Port Forward and click Add
   4.1. Interface: WAN
   4.2. TCP/IP Version: IPv4
   4.3. Protocol: TCP
   4.4. Destination: WAN address
   4.5. Destination Port Range From: 32400
   4.6. Destination Port Range To: 32400
   4.7. Redirect Target IP: server_media (alias)
   4.8. Redirect Target Port: 32400
   4.9. Category: media
   4.10. Description: plex
   4.11. NAT Reflection: Enable
   4.12. Filter Rule Association: Add associated filter rule
5. Access Firewall : Rules : WAN and check the associated plex rule has been created
6. Launch Plex and view your settings using your admin account then access Server : Settings : Remote Access to view the status

This was all that was needed to provision external access.

After a day of testing I can confirm that the issues with my work laptop connected to a zscaler tunnel using the Zscaler Client Connector have been resolved.

The solution was as follows:
1. Copy the URLs listed on the Cloud Enforcement Node Ranges page into a comma separated list
2. Create a Firewall Category:
   2.1. Colour: blue
   2.2. Name: zscaler
3. Create and apply a Firewall Alias:
  3.1. Name: ranges_zscaler
  3.2. Type: Network(s)
  3.3. Categories: zscaler
  3.4. Content: Paste comma separated list
  3.5. Description: Whitelist events from zscaler aggregate ip address ranges
4. Create and apply a Firewall Rule Floating:
   4.1. Action: Pass
   4.2. Quick: checked
   4.3. Direction: in
   4.4. TCP/IP Version: IPv4+IPv6
   4.5. Protocol: any
   4.6. Source: ranges_zscaler
   4.7. Category: zscaler
   4.8. Description: allow zscaler traffic

I will continue to monitor the access and behaviour over the next week.

I changed the Firewall Rules from WAN to Floating and the matched and pass values in the alias have gone up but some network issues still exist:

name	loaded	matched	block	pass
zscaler_ranges	49	334	0	1826

I expect I am missing something obvious here, being a newbie with opnsense.

I have installed OPNsense 25.7.4-amd64 to replace a NetGear Orbi RBR850.

On my home network I occasionally use a work laptop that uses the Zscaler Client Connector to create a secure tunnel to my work. Zscaler provide a Cloud Enforcement Node Ranges page that lists all URLs in CIDR format for inclusion into an allow list. I have previously included this whitelist in Crowdsec to allow access to my services from my work laptop.

After installing opnsense I noticed the default deny / state violation rule was being triggered when I enabled the Zscaler tunnel on my work laptop. I created an Firewall Alias with the following details:

1. Enabled: checked
2. Name: zscaler_ranges
3. Type: Network(s)
4. Categories: blank
5. Content: CIDRs from Cloud Enforcement Node Ranges
6. Statistics: unchecked
7. Description: Whitelist events from zscaler aggregate ip address ranges

I saved and validated this alias and then created a Firewall Rule under my WAN interface:

1. Action: pass
2. Disabled: unchecked
3. Quick: checked
4. Interface: WAN
5. Direction:  in
6. TCP/IP Version: IPv4+IPv6
7. Protocol: any
8. Source / Invert: unchecked
9. Source: zscaler_ranges
10. Destination / Invert: unchecked
11. Destination: any
12. Description: allow zscaler traffic

I saved and applied this rule.

When I check Firewall : Log Files : Live View I can still see many entries being denied, and the alias reports the following:

name	loaded	matched	in block packet	in pass packet
zscaler_ranges	49	156	0	836

Is there anything I am missing with this configuration?