Tailscale Add-on loses connectivity after ISP daily IP change

[Morpheus2018]

Environment

• Home Assistant OS 2026.5.4 - 17.3
• Tailscale Home Assistant Add-on 0.28.1
• Main router: AVM Fritz!Box (gateway: 192.168.178.1)
• Additional AVM Fritz!Box 7590 configured as Mesh Repeater (192.168.178.38)
• ISP performs a daily WAN reconnect resulting in a new public IP address

Configuration

accept_dns: true
accept_routes: true
advertise_exit_node: true
advertise_connector: true
advertise_routes:
  - local_subnets
always_use_derp: false
log_level: info
login_server: https://controlplane.tailscale.com
share_homeassistant: funnel
share_on_port: "443"
snat_subnet_routes: true
stateful_filtering: true
tags: []
taildrive:
  addons: false
  addon_configs: false
  backup: false
  config: false
  media: false
  share: false
  ssl: false
taildrop: false
userspace_networking: false

Problem

Tailscale works normally during regular operation.

However, whenever my ISP performs the daily reconnect and assigns a new public IP address, the Tailscale connection appears to be interrupted. After the WAN IP changes, Home Assistant is no longer reliably reachable through Tailscale.

I would like to know whether this is expected behavior, a bug in the add-on, or a known issue related to WAN IP changes.

Relevant Logs

2026/05/31 03:24:16 [RATELIMIT] format("%s: %s %d %s\n%s") (1 dropped)
2026/05/31 03:24:16 Drop: TCP{[fd7a:115c:a2e0::c001:l8n8]:21153 > [fd7a:115c:a1e0::be34:3121]:33714} 80 no rules matched
2026/05/31 03:24:16 wgengine: Reconfig: configuring userspace WireGuard config (with 1/23 peers)
2026/05/31 08:17:55 Received error: PollNetMap: read tcp 192.168.178.237:37234->192.200.0.108:80: read: connection reset by peer
2026/05/31 08:17:56 control: controlhttp: forcing port 443 dial due to recent noise dial
2026/05/31 08:17:56 control: netmap: got new dial plan from control
2026/05/31 08:17:56 netmap: suggested exit node:  ()
2026/05/31 08:17:56 appc: handling domains: [] and wildcards: []
2026/05/31 08:17:56 wgengine: Reconfig: configuring userspace WireGuard config (with 0/23 peers)
2026/05/31 08:17:57 magicsock: [0x3e870ea52780] derp.Recv(derp-4): derp.Recv: read tcp4 192.168.178.237:44778->155.41.234.53:443: read: connection reset by peer
2026/05/31 08:17:57 derphttp.Client.Recv: connecting to derp-4 (fra)
2026/05/31 08:17:57 portmapper: failed to get PCP mapping: Does not appear to be PCP MAP response
2026/05/31 08:17:57 portmapper: UPnP discovery response from 192.168.178.38, but gateway IP is 192.168.178.1
2026/05/31 08:17:57 magicsock: derp-4 connected; connGen=2
2026/05/31 08:17:57 [RATELIMIT] format("health(warnable=%s): ok") (3 dropped)
2026/05/31 08:17:57 health(warnable=no-derp-connection): ok
2026/05/31 08:17:57 control: NetInfo: NetInfo{varies=false ipv6=false ipv6os=true udp=true icmpv4=false derp=#4 portmap=U link="" firewallmode="ipt-default"}
2026/05/31 08:17:57 magicsock: endpoints changed: 89.175.257.116:34068 (stun), 172.30.32.1:34068 (local), 172.30.232.1:34068 (local), 192.168.178.237:34068 (local)

Additional Information

The logs seem to indicate that Tailscale detects the new WAN endpoint and reconnects to DERP successfully (derp-4 connected and endpoints changed), but connectivity is still disrupted after the ISP reconnect.

Has anyone seen similar behavior after WAN IP changes on Home Assistant OS? Is there a recommended workaround or additional debugging that I can perform?

[lmagyar]

Welcome in the club. :/

OK, your issue seems to be slightly different, but see: tailscale/tailscale#12021 So this is a TS bug.

Do you have watchdog enabled for the app/add-on (Info tab, under start on boot). When the app detects that Tailscale has gone offline, it reports itelf unhealthy after 5 minutes and HA will restart it, usually after a restart it recovers. Don't you see restarts in the log?

If you have watchdog enabled and there is no restart, please check TS's status when it is unreachable (I hope you have some alternative access to it). In the Advanced SSH terminal app, execute:

 docker exec -it $(docker ps -q -f name="tailscale") /bin/bash
/opt/tailscale status --json --self=true --peers=false | jq '.BackendState, .Self.Online'

If .BackendState is not Running or .Self.Online is not true, then the healthcheck logic should restart it.

---

I'm courious why stateful_filtering is true, AFAIK usually this is not necessary.

[lmagyar]

Yesterday I've run into something similar:

• WAN->WWAN failover, losing connection, unhealthy, automatic restart, connected to derp 4 and 26
• switching back, ie. WWAN->WAN, derp reconnect only to derp 4, healthy, really, the TS client is accessible through the tailnet, but funnel is broken, I've waited ~30 minutes, no change, manual restart, works fine

So my new question is, when you write "connectivity is still disrupted after the ISP reconnect" does this mean unreachable through the tailnet (eg. can't curl even from a tailnet connected device), or it is reachable through the tailnet, but unreachable through funnel (ie. funnel's TCP forwarders are broken, again)?

If this is the later, we can't do anything. I've checked, there's nothing in the TS cient's status that would indicate that funnel is broken. It knows, that it is connected to the tailnet successfully.

Nasty workaround, maybe: when we detect "control: netmap: got new dial plan from control" or sg. similar, we get the external/public non-tailnet IP for funnel from TS's DNS, curl ourselves through this IP (ping is not enough, that works), if it fails, that means unhealthy, causing automatic restart. Pfff, ugly.

[github-actions]

There hasn't been any activity on this issue recently, so we clean up some of the older and inactive issues.
Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by leaving a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thanks!

[lmagyar]

not stale yet