OpenClaw Tailscale UDP false: fix relay fallback fast

Problem statement: you enabled Tailscale for your OpenClaw instance expecting fast direct peer-to-peer connections through your tailnet. Instead, the Addons UI shows UDP=false and relay usage is elevated. Connections work but feel sluggish compared to direct WireGuard tunnels. You want to restore UDP connectivity so traffic flows directly between devices instead of routing through Tailscale DERP relays.

Why UDP matters for Tailscale performance

Tailscale uses WireGuard, a modern VPN protocol that prefers UDP for establishing direct peer-to-peer connections. When UDP works, your OpenClaw instance connects directly to devices on your tailnet with minimal latency. When UDP fails, Tailscale falls back to DERP relays—servers operated by Tailscale that route your traffic through an intermediate hop.

Relay fallback is functionally correct and maintains encryption, but it introduces performance penalties:

• Added latency: each request routes through a relay server instead of flowing directly between peers.
• Bandwidth constraints: relays may impose throughput limits that direct connections do not have.
• Dependency on relay availability: you rely on Tailscale's relay infrastructure being reachable from your cluster.

For interactive workflows like browser automation or real-time API calls, relay latency becomes noticeable. Fixing UDP=false restores the snappy responsiveness that makes Tailscale compelling.

How UDP blocking happens in Kubernetes environments

Kubernetes clusters often default to restrictive network policies. When you enable Tailscale for an OpenClaw instance, the sidecar container needs to send and receive UDP traffic to establish direct peer connections. Without explicit policy allowing this, the cluster's network plugin drops UDP packets, forcing Tailscale into relay mode.

• Default deny policies: many clusters start with a default-deny posture that blocks all traffic unless explicitly allowed.
• TCP-only assumptions: some network policies are written only for TCP traffic, leaving UDP implicitly blocked.
• Egress restrictions: cluster-wide egress policies may prevent UDP from reaching Tailscale coordination servers.
• Namespace isolation: policies that isolate namespaces may inadvertently block UDP between the Tailscale sidecar and the network.

Diagnosing UDP=false on your OpenClaw instance

Check the Addons UI for UDP status

The first diagnostic is the Addons tab in your OpenClaw dashboard:

• Open your instance and navigate to the Addons tab.
• Locate the Tailscale status section.
• Look for the UDP field—it should show true for optimal performance.
• If UDP shows false, note whether relay-risk is also elevated.
• The connection state should still be active even with UDP=false, confirming that relay fallback is working.

Verify NetworkPolicy is applied

From the cluster running your OpenClaw instance, check for the required NetworkPolicy:

• Run kubectl get networkpolicy -A | grep tailscale to find Tailscale-related policies.
• Look for openclaw-pod-tailscale-udp in the policy list.
• If the policy is missing, apply it from manifests/network-policy.yaml.
• Verify the policy targets pods with the label tailscale-enabled=true.
• Check that the policy allows UDP egress to port 41641 and UDP traffic to Tailscale endpoints.

Check for cluster-level egress restrictions

Some clusters impose egress restrictions at the infrastructure level:

• Verify the cluster can reach Tailscale coordination servers on UDP ports.
• Check for cluster-wide egress policies that might block UDP regardless of namespace-level policies.
• Confirm your cloud provider's firewall rules allow UDP traffic from worker nodes.
• Test with a simple netcat or curl command from a pod to verify UDP connectivity.

Run netcheck for detailed diagnostics

Tailscale's netcheck tool provides comprehensive connectivity diagnostics:

• Execute tailscale netcheck --format=json from within the Tailscale sidecar.
• Look for UDP port availability in the output—this shows whether UDP can reach the internet.
• Check for NAT type information which affects peer-to-peer connection establishment.
• Review the DERP relay list to see which relays are being used as fallback.
• Note that newer container builds may emit a warning line before the JSON body—the platform strips this automatically.

Fixing UDP=false with NetworkPolicy configuration

Apply the label-scoped UDP egress policy

The standard fix is applying the UDP egress NetworkPolicy included with OpenClaw Setup:

• Locate manifests/network-policy.yaml in the OpenClaw Setup repository.
• Find the openclaw-pod-tailscale-udp policy definition.
• Apply it to your cluster: kubectl apply -f manifests/network-policy.yaml.
• Verify the policy is applied: kubectl get networkpolicy openclaw-pod-tailscale-udp.
• Confirm your Tailscale-enabled pods have the tailscale-enabled=true label.

This policy is label-scoped, meaning it only affects pods that explicitly opt into Tailscale support. Pods without the label are unaffected, which preserves the security posture of non-Tailscale workloads.

Verify label assignment on your pods

The NetworkPolicy uses pod selector labels to determine which pods get UDP egress:

• Run kubectl get pods -n --show-labels to see pod labels.
• Identify your OpenClaw instance pod and check for tailscale-enabled=true.
• If the label is missing, the platform should add it automatically when Tailscale is enabled in the Addons tab.
• Manually add the label if needed: kubectl label pod tailscale-enabled=true.
• Restart the pod after adding the label to ensure NetworkPolicy selection works correctly.

Handle cluster-wide egress restrictions

If applying NetworkPolicy does not resolve UDP=false, the issue may be at the cluster level:

• Consult your cluster administrator about UDP egress policies.
• Request an exception for Tailscale UDP traffic to coordination servers and DERP relays.
• Document the specific Tailscale endpoints that need UDP access for your security review.
• As a workaround, consider whether relay-only operation is acceptable for your use case.

Verifying the fix restored UDP connectivity

1. Return to the Addons UI and refresh the Tailscale status section.
2. Confirm UDP now shows true instead of false.
3. Check that relay-risk indicator has decreased compared to before the fix.
4. Run tailscale status to see if connections show as direct instead of relay.
5. Test actual network latency with a ping or quick API call through the tailnet.
6. Verify that connections from your local machine to the instance show reduced latency.

Edge cases that can persist despite NetworkPolicy fixes

Sometimes UDP=false persists even with correct NetworkPolicy configuration:

• Peer-side NAT issues: if the device you are connecting from is behind restrictive NAT, direct UDP may fail regardless of cluster configuration.
• Corporate firewall blocking: some enterprise firewalls block all UDP traffic except for specific whitelisted services.
• ISP-level restrictions: residential ISPs sometimes restrict UDP to prevent certain protocols.
• Multi-hop routing: complex network topologies with multiple proxies or NAT layers can prevent UDP establishment.
• IPv6 vs IPv4: dual-stack issues may cause UDP to work on one protocol family but not the other.

Typical mistakes that delay fixing UDP=false

• Assuming the issue is on the local machine when the cluster egress is actually blocked.
• Applying NetworkPolicy to the wrong namespace or forgetting to apply it at all.
• Missing the tailscale-enabled=true label on pods, causing the NetworkPolicy selector to skip them.
• Confusing TCP port 443 for Tailscale API with UDP port 41641 needed for WireGuard.
• Restarting pods repeatedly without applying the underlying NetworkPolicy, wasting time on symptom rather than cause.
• Ignoring cluster-level restrictions that override namespace-level NetworkPolicy configuration.

Security considerations for UDP egress policies

Allowing UDP egress for Tailscale is safe because WireGuard traffic is encrypted and authenticated. The label-scoped policy ensures that only pods explicitly using Tailscale get UDP egress—other pods remain subject to default-deny rules. This maintains security while enabling the performance benefits of direct peer connections.

The NetworkPolicy specifically allows UDP to Tailscale infrastructure endpoints, not arbitrary internet destinations. This targeted approach minimizes security exposure while solving the relay fallback issue.

When relay-only operation may be acceptable

In some environments, UDP cannot be made to work regardless of configuration. Corporate networks, restrictive cloud providers, or regulatory environments may block UDP entirely. In these cases, relay-only operation still provides secure, encrypted access—just with higher latency. Evaluate whether your workflows can tolerate the additional latency before investing significant effort in UDP troubleshooting.

Fix once. Stop recurring Tailscale UDP and relay connectivity issues.

If this keeps coming back, you can move your existing setup to managed OpenClaw cloud hosting instead of rebuilding the same stack. Import your current instance, keep your context, and move onto a runtime with lower ops overhead.

• Import flow in ~1 minute
• Keep your current instance context
• Run with managed security and reliability defaults

If you would rather compare options first, review OpenClaw cloud hosting or see the best OpenClaw hosting options before deciding.

Import your current OpenClaw instance in 1 click Keep self-hosted: apply fix checklist

FAQ

Will enabling UDP egress create a security vulnerability?

No. The label-scoped NetworkPolicy only allows UDP to Tailscale endpoints, and all WireGuard traffic is encrypted and authenticated. The policy applies only to pods with the tailscale-enabled=true label, so other pods remain unaffected.

How long does it take for UDP to start working after applying NetworkPolicy?

NetworkPolicy applies immediately to new connections, but existing Tailscale sessions may need to re-establish. Restarting the Tailscale sidecar or the entire pod can speed up the transition. Usually UDP connectivity is restored within a minute of applying the correct policy.

Can I test UDP connectivity without enabling Tailscale first?

Yes. You can test UDP egress from a pod using tools like netcat to reach Tailscale coordination servers. However, the simplest test is to enable Tailscale and check the Addons UI—this gives you a definitive answer about UDP availability for the actual Tailscale workload.

What if UDP works but relay usage is still high?

This indicates the issue is on the peer side rather than the cluster side. Your OpenClaw instance can send UDP, but devices connecting to it may have NAT or firewall issues preventing direct peer establishment. Focus troubleshooting on the client-side network environment in this case.

Does UDP=false affect all tailnet connections or just some?

UDP status is evaluated per-peer. Some peers may establish direct UDP connections while others fall back to relays, depending on their network environment. The Addons UI shows aggregate status, but you may see mixed behavior when connecting from different locations.

Sources

• Tailscale DERP relay architecture: how relay fallback works
• Tailscale UDP vs TCP: why UDP matters for performance
• OpenClaw Setup repository: commit afbee31 implementing label-scoped UDP egress NetworkPolicy
• Worklog entry 2026-04-03-tailscale-sidecar.md: complete Tailscale sidecar implementation notes including netcheck handling and UDP diagnostics
• Chrome Extension relay: browser automation with Tailscale backend
• OpenClaw cloud hosting: managed platform with Tailscale and UDP support