Other Pangolin maintainer here! A little more on how the WireGuard connection authenticates the connection if you are curious: the client makes a websocket connection to the server to receive command and control. That is authed with the user’s token obtained from logging in. It shares its new WG public key with the server and the server provisions a peer and the WG handshake completes. Now we have an outbound WG tunnel from the client to the server. Next the client overrides the DNS of the computer. All DNS queries make it into the tunnel where we grab them. If they are within our range of resources we give a direct reply, otherwise we send it upstream to public servers. So now we have an IP when Claude makes the request which is on the other end of the tunnel. Claude makes the request, it gets routed to the server and hits. Because we trust the WG connection packet headers on the server side we can associate this peer with an identity inside of the gateway. No key required.
Other Pangolin maintainer here! A little more on how the WireGuard connection authenticates the connection if you are curious: the client makes a websocket connection to the server to receive command and control. That is authed with the user’s token obtained from logging in. It shares its new WG public key with the server and the server provisions a peer and the WG handshake completes. Now we have an outbound WG tunnel from the client to the server. Next the client overrides the DNS of the computer. All DNS queries make it into the tunnel where we grab them. If they are within our range of resources we give a direct reply, otherwise we send it upstream to public servers. So now we have an IP when Claude makes the request which is on the other end of the tunnel. Claude makes the request, it gets routed to the server and hits. Because we trust the WG connection packet headers on the server side we can associate this peer with an identity inside of the gateway. No key required.