Hi, I have been using TD TDAbleton over WAN with a friend and have been experience loss of connection at random times.
Searches reveal UDP ports on routers being closed if they are not kept open continuously.
Has anyone experienced this? Is there a know native solution besides VPNs or Grok or the like?
An Open Claude question result:
Yes, UDP over WAN is fundamentally the root cause, and UDP hole punching is part of the picture — but there are actually several layered reasons this happens. Let me break it down:
The core issue: TDAbleton uses OSC over UDP
TDAbleton communicates with TouchDesigner via OSC using UDP. Derivative UDP is a connectionless, “fire and forget” protocol — it has no built-in acknowledgement, session state, or reconnection mechanism. This is great for low-latency LAN use, but it creates serious problems over WAN.
Why WAN specifically breaks it:
NAT state timeouts — This is the big one, and closely related to what you’re describing. When you send UDP packets through a NAT router, the router creates a temporary state/mapping to know where to route return packets. Unlike TCP (which has explicit open/close handshakes), UDP has no connection signal, so routers just let the state expire after a timeout — typically anywhere from 30 seconds to a few minutes of inactivity. If TDAbleton goes quiet (no messages passing in either direction), the NAT entry silently expires, and return packets from Ableton are dropped on the far side with no notification to either end.
UDP hole punching — You’re right that this is relevant. Standard UDP hole punching requires both sides to send packets “simultaneously” through their respective NATs to keep the pinholes open. TDAbleton isn’t designed to do this — it doesn’t have a keepalive heartbeat mechanism to maintain the NAT mapping on both sides of a WAN link.
Firewalls blocking unsolicited inbound UDP — Most consumer and enterprise firewalls will drop inbound UDP packets that don’t correspond to an existing outbound flow in the state table. If the state expires (see above), the incoming OSC messages from Ableton get silently dropped.
Port forwarding requirements — Over WAN, the Ableton-side machine is typically behind NAT, meaning its private IP is not directly reachable. Without explicit port forwarding on both ends (for the bidirectional OSC communication), one direction of the link will simply never arrive. TDAbleton uses separate ports for each direction: the “In Port” for TouchDesigner to receive from Ableton, and the “Ableton Port” for Ableton to receive messages. Derivative Both need to be reachable.
The practical upshot:
TDAbleton is really designed for LAN use (or localhost), where NAT isn’t in the picture at all. The OSC protocol using UDP/IP makes it possible for TouchDesigner and Ableton Live to run on separate computers Interactive & Immersive, but “separate computers” was intended for local network scenarios — not internet-separated ones.
If you want reliable WAN connectivity, your options are:
VPN (e.g. Tailscale, ZeroTier, WireGuard) — makes remote machines appear LAN-local, bypasses all the NAT/firewall issues entirely. This is by far the most reliable approach.
Manual port forwarding + static IPs on both ends, plus a keepalive mechanism to stop NAT states from expiring.
Dedicated relay/tunnel — some setups use tools like ngrok or frp to expose UDP ports, though latency becomes a concern for live performance.