Tailscale clients behind NAT lose control-plane connectivity every few hours after 26.7 upgrade (map long-poll timeout, UDP blocked; recovers only on daemon restart)

[pcsokonay]

---

name: Bug report
about: Create a report to help us improve OPNsense
title: ''
labels: ''
assignees: ''

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• I have read the contributing guidelines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue
• AI tools were used to create at least part of the text submitted herewith.

If AI was used, please disclose:

• Model used: Hermes (deepseek-v4-flash) drafting agent; report verified by the reporter.
• Extent of AI involvement: Text drafted from evidence collected automatically by the reporter's monitoring (journalctl excerpts, health-check logs, pfctl output). Technical content reviewed and confirmed by the reporter before filing.

Describe the bug

After upgrading OPNsense 26.1.x → 26.7.1_1 (2026-08-06), Tailscale clients behind the OPNsense NAT repeatedly lose coordination-server connectivity: tailscaled logs control: map response long-poll timed out! followed by PollNetMap: ... context canceled every ~2 minutes, the node flips to offline in the tailnet, and outbound UDP appears dead host-wide (netcheck: UDP is blocked). Recovery only happens when the daemon is restarted (fresh NAT states). An OPNsense reboot is not involved — OPNsense has been up continuously since the upgrade. TCP to the internet stays up throughout.

Last known working version: 26.1.x (no incidents in ~4 months prior).

To Reproduce

Environment:

• OPNsense 26.7.1_1 (amd64), running as a VM. WAN via DHCP (renews every ~15 min; WAN IP does not change).
• Outbound NAT mode: HYBRID (the 26.7 migration created the flattened automatic source-NAT rules; staticnatport=1 is already active for lan/lo0/opt1).
• pf UDP timeouts: defaults (udp.single=30s, udp.first=60s, udp.multiple=60s).
• monitor_killstates=0 (kill-states-on-gateway-failure OFF).
• Tailscale clients: Linux/FreeBSD/TrueNAS behind NAT, Tailscale 1.102.2 (current).

Observed fires (all after the 26.7.1_1 upgrade at 2026-08-06 11:33, OPNsense uptime continuous throughout):

1. 2026-08-06 ~14:17
2. 2026-08-07 ~23:45
3. 2026-08-08 09:55 degraded → 10:00 fired
4. 2026-08-08 15:10 fired
5. 2026-08-09 07:40 degraded → 07:45 fired

Affected set is not "every node behind NAT": some fires hit 3 nodes simultaneously, one hit only 1; one node on the same NAT was immune in every fire (tailscaled up continuously for days, zero errors). Nodes outside the NAT (different WAN) are never affected.

Expected behavior

Tailscale's long-lived UDP flows (WireGuard on 41641 / DERP) should keep working, or at minimum tailscaled should be able to re-establish after the NAT mapping drops — as it did on 26.1.x. Currently the daemon wedges until manually restarted.

Describe alternatives you considered

• Confirmed static-port source NAT is already active (26.7 flattened automatic rules) — adding more is a no-op.
• pf UDP state timeouts are not tunable from OPNsense config (no GUI/API fields).
• monitor_killstates is already off.
• Tailscale side: current version, no upgrade available; works fine behind other NATs.
• Workaround in place: a health-check script auto-restarts tailscaled when the signature is detected (~15-40 s recovery). This papers over the bug but does not fix it.

Relevant log files

Aug 9 fire, ubuntu tailscaled (journal):

Aug 09 07:35:30 ubuntu tailscaled: control: map response long-poll timed out!
Aug 09 07:35:30 ubuntu tailscaled: Received error: PollNetMap: context canceled
Aug 09 07:35:48 ubuntu tailscaled: magicsock: derp.Recv(derp-5): read tcp6 ... i/o timeout
Aug 09 07:35:49 ubuntu tailscaled: derphttp.Client.Recv: connecting to derp-5 (syd)
Aug 09 07:36:21 ubuntu tailscaled: control: map response long-poll timed out!
Aug 09 07:36:21 ubuntu tailscaled: control: lite map update error after 2m0.001s: Post "https://controlplane.tailscale.com/machine/map": context canceled
... (repeats every ~2 min until daemon restart at 07:45:16)

Aug 8 fire sequence (the clearest):

• 09:49:06 — OPNsense WAN dhclient RENEW on vtnet0 (no IP change).
• 09:50:34 — netcheck: UDP is blocked, trying HTTPS / NetInfo{... udp=false ...} (outbound UDP appears dead host-wide; even UDP DNS in a container timed out at 09:51:16).
• 09:57:36+ — map response long-poll timed out! + PollNetMap ... context canceled loop until daemon restart.
• TCP to 1.1.1.1 and Apprise HTTPS POST succeeded at 10:00:01 — only UDP was affected.

pve showed identical PollNetMap failures in the same window; truenas-scale went offline; a node on the same NAT (beelink) showed zero errors and normal DERP/disco traffic throughout.

Additional context

• Related: a way to change the NAT Type to Endpoint-Independent Filtering (rfc4787) core#8384 (OPNsense NAT type is address/port-dependent per RFC 4787 — breaks Tailscale/WireGuard hole punching; closed as feature/roadmap). This regression is a behavior change in 26.7's rewritten outbound/source NAT handling, distinct from that feature request.
• Related: Regression in opnsense NAT/NAT-PMP with using tailscale on client devices behind opnsense router with CGNAT WAN core#8070 (Tailscale behind OPNsense NAT regression, older).
• Working hypothesis: 26.7's rewritten automatic NAT drops long-lived UDP mappings, and with address/port-dependent NAT the client cannot re-establish them itself → netcheck reports UDP blocked → control-plane long-poll times out → daemon wedges until restart creates fresh NAT states. The recurring ~15-min WAN DHCP renew may be the trigger (the 09:49:06 renew directly preceded the 09:50:34 UDP block; the renew after recovery caused nothing).
• Happy to run diagnostics or test a dev build. This is the most impactful regression for homelab/self-hosted users on 26.7.

Environment

OPNsense 26.7.1_1 (amd64) — VM on Proxmox, vtnet0 WAN (DHCP), LAN + OPT behind NAT.