Skip to content

[Bug]: Offline node after successful pairing over VPN connection #65

Open
Open
[Bug]: Offline node after successful pairing over VPN connection#65
Assignees
ckelseynvnvrithik
Labels
bugSomething isn't working

Description

@mihaigiurgeanu
mihaigiurgeanu
opened on Sep 12, 2026

PAIR version or commit

0.1.1.463

Affected component

Desktop application

Environment

OS: macOS 15.7.8
architecture: arm
GPU: M4 Max
driver: N/A (Apple Silicon / Metal)
engine/version: ollama version is 0.33.3
model: qwen3.8:27b-mlx
cluster size: 2

I have installed PAIR desktop on both computers, Apple M4 Max, macOS.
On both computers I already had ollama up and running.
PAIR discovered the ollama on both computers.
Computers are connected through VPN (Wireguard).
I successfully paired the computers.
The nodes show offline on both computers.

% netstat -an | grep 11435                      
tcp46      0      0  *.11435                *.*                    LISTEN 

% netstat -an | grep 14321
tcp4       0      0  10.0.0.2.51278         10.0.0.12.14321        ESTABLISHED
tcp4       0      0  10.0.0.2.14321         10.0.0.12.49602        ESTABLISHED
tcp46      0      0  *.14321                *.*                    LISTEN
Image

Steps to reproduce

  1. Install ollama on both computers and pull some modells.
  2. Install PAIR desktop on both computers, Apple M4 Max, macOS.
  3. Setup VPN connection between the computers (I am using Wireguard).
  4. Turn off the firewall on both computers.
  5. Pair the 2 instances of PAIR from desktop app

The nodes show offline on both computers.

Expected behavior

The nodes should show online.

Actual behavior

The nodes show offline.

Sanitized logs or screenshots

% netstat -an | grep 11435                      
tcp46      0      0  *.11435                *.*                    LISTEN 

% netstat -an | grep 14321
tcp4       0      0  10.0.0.2.51278         10.0.0.12.14321        ESTABLISHED
tcp4       0      0  10.0.0.2.14321         10.0.0.12.49602        ESTABLISHED
tcp46      0      0  *.14321                *.*                    LISTEN

Confirmations

  • I searched existing issues for duplicates.
  • This is not a security vulnerability.
  • I agree to follow the Code of Conduct.

Activity

  1. mihaigiurgeanu
    added
    bugSomething isn't working
    on Sep 12, 2026

  2. lodos2005 commented on Sep 16, 2026

    @lodos2005
    lodos2005
    on Sep 16, 2026

    We're experiencing the same issue as well.

  3. Noah-Tervalon-Nvidia
    assigned
    ckelseynv
    on Sep 18, 2026

  4. d3v2a commented on Sep 20, 2026

    @d3v2a
    d3v2a
    on Sep 20, 2026

    It's not a bug; the node declares his presence with mDNS, which is not transferred to the VPN.

    uuid can be found in /Users/[user]/Library/Application Support/Nvidia Corporation/Personal AI Router/cluster

    On all machines, run this with uv run --with zeroconf script.py, with the information of remote machine

    from zeroconf import ServiceInfo, Zeroconf
import time, socket

zc = Zeroconf()

info = ServiceInfo(
    "_nvpair-node._tcp.local.",
    "[name_of_machine]._nvpair-node._tcp.local.",
    addresses=[socket.inet_aton("[ip of remote machine]")],
    port=14318,
    properties={
        b"v": b"1",
        b"uuid": b"[id of remote machine]",
        b"cluster-uuid": b"[id of cluster]",
        b"ip": b"[ip of remote machine]",
        b"ips": b"[ip of remote machine]",
        b"ni": b"14318",
        b"ol": b"11434",
        b"er": b"14319",
        b"wl": b"14320",
        b"cl": b"14321",
        b"em": b"14322",
        b"ec": b"14323",
    },
    server="[name_of_machine].local.",
)

zc.register_service(info)
try:
    while True:
        time.sleep(60)
except KeyboardInterrupt:
    zc.unregister_service(info)
    zc.close()
  5. Noah-Tervalon-Nvidia
    assigned
    nvrithik
    on Oct 14, 2026

  6. nvrithik commented on Oct 21, 2026

    @nvrithik
    nvrithik
    on Oct 21, 2026
    Collaborator

    I reproduced this on two machines over a VPN (Ubuntu x86_64 and macOS arm64) with 1.0.0. Pairing by IP succeeds, then both sides
    show Offline with no models.

    Cause: mDNS is multicast and doesn't cross a VPN. Pairing saves the peer's address in the cluster roster, but status, models and
    trust read only the scanner's list, which only mDNS fills.

    It's a known issue, also described in #91. PR #10 ("Make a node added by address a first-class peer") looks like the fix for it,
    so I'm not opening a competing change.

    I also have a small local prototype that feeds paired members' addresses to the scanner. It showed the peer online with its
    models over the VPN. It doesn't cover routing. I can share it if it's useful, or drop it if #10 covers this.

    @Noah-Tervalon-Nvidia @ckelseynv is #10 the intended fix for #65?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions