To elaborate on this a little bit...

The headset cannot use just the IP address to know if something is on the same network. If I have something on my test network here at work that is 192.168.0.108, and then I have my PC at home on *that* network that is 192.168.0.64, if I just look at the two IP addresses they look like they're on the same network, but they very much are not; to connect to one from the other, I would need to use the Steam proxy servers (which are fine for 2D gaming, less so for VR).

So to find each other and know the difference between "I can talk to this directly" versus "I will have to proxy through Steam servers to talk to this," Steam clients will send out little "Hi, I'm here!" broadcast packets on the local network. If a Steam client (including Steam Link) sees a broadcast packet from a given client come in over a given interface, it goes "Oh, I know that particular client *is* on the same network over this interface, and I wouldn't need to go through the Steam proxy servers!"

In which case, it knows it can talk to that client directly (and thus VR will work).

But if your VPN blocks broadcast packets, then the headset will never see the ones the PC sends out, and as such it does not think they're on the same network. If you allow broadcast packets through, they should see each other fine.

Originally posted by Packetdancer:

To elaborate on this a little bit...

The headset cannot use just the IP address to know if something is on the same network. If I have something on my test network here at work that is 192.168.0.108, and then I have my PC at home on *that* network that is 192.168.0.64, if I just look at the two IP addresses they look like they're on the same network, but they very much are not; to connect to one from the other, I would need to use the Steam proxy servers (which are fine for 2D gaming, less so for VR).

So to find each other and know the difference between "I can talk to this directly" versus "I will have to proxy through Steam servers to talk to this," Steam clients will send out little "Hi, I'm here!" broadcast packets on the local network. If a Steam client (including Steam Link) sees a broadcast packet from a given client come in over a given interface, it goes "Oh, I know that particular client *is* on the same network over this interface, and I wouldn't need to go through the Steam proxy servers!"

In which case, it knows it can talk to that client directly (and thus VR will work).

But if your VPN blocks broadcast packets, then the headset will never see the ones the PC sends out, and as such it does not think they're on the same network. If you allow broadcast packets through, they should see each other fine.

Admittedly my networking knowledge is pretty limited but the lack of level 2 tunneling in WireGuard indeed seems to be the problem; from what I can tell in-home streaming may be relying on mDNS for discovery? Not 100% sure about that but I guess it makes sense. It's annoying since similar tools like Moonlight/Sunshine and WiVRn allow you to enter an IP address manually, but there doesn't seem to be any way to do that here.

Made a bit of progress here, my attempt to get mDNS going through WireGuard doesn't quite seem to be working but it turns out the Steam console has a `connect_remote` command that lets you manually enter the IP address of a host PC. I was able to connect to my desktop that way and it's happy to allow me to start VR games ...but the streaming client (vrlink) segfaulted.

Finally discovered the existence of the vrlink logs on the Frame and looking through them it appears that despite manually providing an IP (with `connect_remote`) that vrlink acknowledges, it ends up timing out after 15 seconds of "getting information from the server". I tested with the wireless dongle on my laptop and there it logs "SVLDataLinkUber: Found primary link <IP>" before timing out for a different and expected reason (Intel iGPU moment) so it seems like there's definitely some sort of networking issue going on here, no idea what's up with the segfaults though.