Venus OS 3.75 on Raspberry Pi – all local LAN services suddenly refusing connections

Modifications
, , ,
1

Hi all,

Hoping someone can point me in the right direction. I’m running Venus OS 3.75 on a Raspberry Pi as my GX device, and until recently everything was fine. The Victron system itself is still working — it’s specifically the LAN services on the Venus device that have stopped responding.

GX device is on 192.168.1.201. From another Pi on the same network:

ping 192.168.1.201 — works fine.

But:

nc -zv 192.168.1.201 22 → connection refused
nc -zv 192.168.1.201 1883 → connection refused
nc -zv 192.168.1.201 8883 → connection refused
curl http://192.168.1.201 → connection refused
curl https://192.168.1.201 → connection refused

So it responds to ping but nothing else. I also tried from a Windows PC on the same LAN and got the same refusals on 1883 and 443, so I don’t think this is a Home Assistant or single-client issue.

I noticed this originally through Home Assistant, which pulls data from the GX over MQTT. MQTT access is enabled on Venus OS, and the HA log shows the connection dropped on 29 July 2026 with:

Unexpected disconnection from MQTT broker. Error: Keep alive timeout.

Since then it’s just kept trying to reconnect and failing. HA is on Core 2026.7.3 with victron-mqtt 2026.6.1.1, if that’s relevant.

Things I’ve already tried, none of which helped:

Rebooted the Pi through Venus OS
Pulled power and restarted it physically
Upgraded Venus OS from 3.73 to 3.75
Switched the LAN security profile to Weak, then Unsecured
Double-checked MQTT access and SSH access are both enabled

What’s throwing me is that the Victron side is completely unaffected — VRM is updating normally, the Remote Console works, and I’ve turned on Remote Support which shows “tunnel online”. So the device is clearly up and talking to Victron’s servers, it’s just LAN clients that get refused on every port.

Has anyone seen this before, or know why SSH, HTTP/HTTPS and MQTT would all stop listening locally while VRM and Remote Support keep working fine? Is there a way to check what’s actually running on the box remotely — whether FlashMQ, the web server and sshd are still alive — without SSH access, since that’s also refused?

I’ve held off on a factory reset or reinstall since the core system is working and I don’t want to break something that’s currently fine just to chase the LAN issue. I’ll leave Remote Support on in case it’s useful for anyone from Victron looking into this.

Thanks for any pointers.

4

Update — this is resolved. Posting the cause in case it helps anyone else who finds this thread.

The Venus OS device hadn’t actually broken — it had quietly moved to a different LAN IP address at some point, and everything (including Home Assistant) was still pointed at the old one. That’s why ping worked (the old address just happened to still get some response) but SSH, MQTT, and HTTP were all refused — nothing was actually listening there anymore.

Found this via the VRM Portal’s device page, which shows the device’s current LAN IP under “Remote on LAN” — it was different from what I’d been using. Confirmed it was genuinely the same physical device (not a coincidence) because its SSH host key matched entries already in my known_hosts file for several previous IP addresses — it’s clearly been drifting for a while, not just once.

Fix was simply updating the IP in Home Assistant’s Victron/MQTT integration to the new address — connected immediately.

Two side notes for anyone hitting something similar:

  • Venus OS resets the root SSH password on every firmware update (confirmed in Victron’s own docs — the password file lives on the replaceable root filesystem). Not a bug, just worth knowing before you assume you’re locked out.
  • After fixing the IP, SSH would authenticate but the shell itself would hang with no prompt. A clean reboot of the device fixed it — didn’t dig into the root cause since it hasn’t recurred.

Going to set a DHCP reservation on my router to stop it drifting again, but the underlying “everything refused except ping/VRM” mystery is fully explained now. Thanks to anyone who read this far.