Trying to integrate Tesla Powerwall on separate subnet

Configuration
1

I’m having a routing issue with a Home Assistant Green that prevents it from reaching another LAN subnet (trying to integrate Tesla Powerwall), even though the router/firewall is configured to allow it.

Environment

  • Hardware: Home Assistant Green
  • HA OS: (current stable as of April 2026 – 17.2/2026.4.2)
  • Router: Synology RT6600ax, SRM 1.3.1‑9346 U14
  • LANs:
    • Main LAN: 10.0.4.0/24 (router/gateway 10.0.4.1)
    • IoT LAN: 192.168.0.0/24 (Tesla Powerwall gateway 192.168.0.104)
  • Goal: Home Assistant Green at 10.0.4.105 should talk to the Tesla Powerwall at 192.168.0.104 (HTTPS 443, plus ICMP for testing).

Router side

  • On SRM, I’ve enabled inter‑LAN routing and added explicit LAN firewall rules:
    • Source IP: 10.0.4.105
    • Destination IP: 192.168.0.104
    • Protocols: ICMP and TCP 443
    • Action: Allow, rules are saved and at the top of the LAN rule list.
  • From a laptop on 192.168.0.x, I can successfully:
    • ping 192.168.0.104
    • Open https://192.168.0.104/ (Tesla Backup Gateway UI).

So the Tesla gateway is definitely reachable on that subnet, and routing from the router works.

Home Assistant network config (as shown in UI)
Under Settings → System → Network:

  • Interface end0 shows:
    • IPv4: 10.0.4.105/24
    • Gateway: 10.0.4.1
    • DNS: 10.0.4.1
    • Method: Automatic (via DHCP)
  • “Network adapter” section has Autoconfigure checked and lists end0 (10.0.4.105/24, …) as the adapter used for integrations.

But on the HA shell:
Running in the SSH/terminal add‑on:

ha network info

shows:

docker:
  address: 172.30.32.0/23
  dns: 172.30.32.3
  gateway: 172.30.32.1
  interface: hassio
interfaces:
  - interface: end0
    ipv4:
      address:
        - 10.0.4.105/24
      gateway: 10.0.4.1
      method: auto
      nameservers:
        - 10.0.4.1
    ...

But ip route still shows:

default via 172.30.32.1 dev eth0
172.30.32.0/23 dev eth0 scope link src 172.30.33.0

So the system default gateway is still 172.30.32.1 on eth0 (Docker network), not 10.0.4.1 on end0, even though ha network info knows about the correct 10.0.4.x configuration.

Connectivity tests from HA shell

ping 10.0.4.1         # works
ping 192.168.0.104    # prints "PING ..." then hangs, no replies
curl -k https://192.168.0.104/  # also hangs

So packets from HA go out via 172.30.32.1 and never reach the 192.168.0.x LAN.

What I’ve tried

  • Changed network settings via the UI (Automatic vs Static), Saved, and rebooted the host.
  • Used ha network update end0 --ipv4-method static ... from the CLI; I got errors about ipv4.method 'manual' requires at least an address or a route.
  • Tried again with the full parameter set; command appears to succeed but ip route still shows the default via 172.30.32.1.
  • Attempted to drop into the host OS shell with login from the add‑on’s shell, but got “login incorrect” (this is the container, not the host). I have not yet been able to SSH to the host OS on port 22222 because this Green was bought pre‑installed and I haven’t set up host‑OS SSH keys.

Symptoms in HA

  • When I add the built‑in Tesla Powerwall integration and point it at https://192.168.0.104, I get “A connection error occurred while connecting to the Powerwall,” which is consistent with the inability to reach that IP from the HA shell.

Ask

  1. Why is HAOS still using the internal Docker network (172.30.32.0/23 via 172.30.32.1) as the default route even though end0 is correctly configured on 10.0.4.105/24 with gateway 10.0.4.1?
  2. How can I correctly force end0 to be the default route on a Home Assistant Green, ideally without having to open the box or reflash the image?
  3. Is there a known issue where ha network update doesn’t actually change the default route, or where interface names (eth0 vs end0) cause this behavior?
  4. Given this environment, what is the recommended, supported way to reset networking on HA Green so it comes up cleanly on my 10.0.4.0/24 LAN?

Any guidance on fixing the default route / interface selection would be appreciated; once HA can actually route from 10.0.4.105 → 192.168.0.104, I expect the Tesla integration issues to go away.

2

HAOS is not meant to be “tempered” with.

Firstly it use NetworkManager for network configuration, but I do not know if routes are part of that suite.
Secondly if you succeed in making your changes, then the chances they will survive an update are very small.

3

OK - but then what do I do? Any additional firewall rules? Config elsewhere?

4

The usual answer is 1 flat network containing HA and everything it needs to talk to.

If you want better isolation (protect your high value devices from HA) you can have a second subnet/VLAN, but you should only use that for accessing the GUI (i.e. via HTTP/HTTPS).

5

Yea this isn’t right… not sure if its the SSH Terminal Addon, but I think you will need to put some effort into getting into the -p22222 to get to the HAOS shell as that will be the way to tell for sure, and if nmcli can actually set a persistent route, you will need to get to the HAOS shell to do it.

6

As I understand your post your ha green is communicating only inside docker network. This is probably the reason you can’t reach ipv4 with your vlan.
You should put ha green on some subnet 192.168.x.x as main lan and this tesla thing on vlan 192.168.x.x.