Talos nodes don't reconnect to SideroLink after Omni pod restart

[0hlov3]

I deployed a self-hosted Omni instance in Kubernetes. Everything works as expected during cluster creation and normal operation.

The issue appears when the Omni pod is restarted. After the restart, all Talos nodes lose their SideroLink connection and do not reconnect automatically. The nodes only reconnect after I reboot them one by one.

I am trying to understand whether this is expected behavior, a networking issue on my side or a missing Omni configuration.

Environment

• Omni deployed via Helm in Kubernetes
• Single Omni replica
• Embedded etcd
• Talos nodes are located outside of the Kubernetes cluster
• Omni cannot directly connect to the Talos nodes
• Communication relies on the SideroLink WireGuard tunnel
• NSX-T based networking and load balancing

What works

• Initial cluster bootstrap
• Cluster creation
• Talos node registration
• Normal operation
• Talos nodes reconnect after a node reboot

What does not work

When the Omni pod is restarted:

1. Talos nodes lose their SideroLink connection
2. Omni shows the nodes as disconnected
3. The nodes do not reconnect automatically
4. Rebooting a Talos node causes it to reconnect successfully

This makes me think that the initial WireGuard setup is correct, but the nodes are not re-establishing the tunnel after the server side disappears and comes back.

Omni configuration

config:
  services:
    api:
      advertisedURL: https://omni.REDACTED

    kubernetesProxy:
      advertisedURL: https://omni-k8s.REDACTED

    siderolink:
      wireGuard:
        endpoint: 0.0.0.0:50180
        advertisedEndpoint: PUBLIC_IP:50180

    machineAPI:
      advertisedURL: https://omni-siderolink.REDACTED

The advertisedEndpoint is configured with the public IP address that is reachable from the Internet.

Services

NAME             TYPE           EXTERNAL-IP   PORT(S)
omni-wireguard   LoadBalancer   10.153.17.2  50180/UDP

Network topology

The WireGuard endpoint is not directly exposed from the Kubernetes node.

Traffic flow:

Talos Nodes
    ↓ SNAT
Internet
    ↓
Public IP
    ↓ DNAT
NSX LB VIP (<img width="1403" height="467" alt="Screenshot 2026-06-12 at 05 49 26" src="https://github.com/user-attachments/assets/2991271e-75d6-4423-b85b-c2c0e4009471" />
    ↓
NSX Load Balancer (L4 UDP)
    ↓
Kubernetes LoadBalancer Service
    ↓
Omni Pod

More detailed NSX path:

Tier-0 Router
  ↓
Tier-1 Router
  ↓
DNAT PUBLIC_IP:50180 -> 10.153.17.2:50180
  ↓
NSX Load Balancer
  ↓
VIP 10.153.17.2
  ↓
LB Pool
  ↓
SNAT Automap
  ↓
192.168.29.2 (Kubernetes backend)

Questions

1. Should Talos nodes automatically reconnect to SideroLink after an Omni restart?
2. Is there a known issue when Omni is deployed behind an L4 UDP load balancer with SNAT?
3. Is there additional configuration required when Omni is behind DNAT and a Kubernetes LoadBalancer service?
4. Does Omni need to be aware of the NSX VIP (10.153.17.2) or any other internal address?
5. Are there any logs or metrics that would be particularly useful to collect during the reconnect failure?

One suggestion I received was to test disableLastEndpoint: true, which I plan to try next.

[AdyaTech]

From what you've described, I don't think Talos nodes should need a reboot after an Omni restart. The SideroLink/WireGuard connection should normally reconnect automatically once Omni comes back online.

Since everything works correctly until the Omni pod restarts, the initial configuration looks fine. The interesting part is that rebooting a node immediately fixes the issue, which suggests the problem is happening during reconnection rather than during the initial setup.

A few things I would check:

• Since you're using an NSX L4 UDP load balancer with DNAT/SNAT, it's possible some UDP session or NAT state is not being refreshed correctly after the Omni pod restarts.
• Test disableLastEndpoint: true as suggested. WireGuard can remember the last endpoint it communicated with, and in NAT-heavy environments this can sometimes interfere with reconnects after the server disappears and comes back.
• Check whether Omni is receiving any new WireGuard handshake packets after the restart. If no packets arrive, the issue is likely somewhere in the LB/NAT path. If packets arrive but the tunnel is not established, the issue is likely closer to Omni or WireGuard itself.
• Collect Omni/SideroLink logs before and after the restart to see whether reconnection attempts are being detected.

I don't think Omni needs to know about the internal NSX VIP (10.153.17.2). As long as advertisedEndpoint points to the public IP and port that the Talos nodes can reach, that part looks correct.

My first test would be disableLastEndpoint: true and checking whether WireGuard handshakes are reaching Omni after a restart. That should help narrow down whether this is a WireGuard reconnection issue or a load balancer/NAT issue.