3

in my office I have an Ubuntu workstation with a decent gaming GPU. At home, I have only a 13" MacBook Pro which is not that much a gaming machine.

Fortunately, Steam has this great feature called In Home Streaming, where you can stream games from one machine to another. But unfortunately, both have to be in the same network.

Since the gaming machine in my office is behind a firewall and does not have a public IP (I could get one, but I do not want because of security reasons), we have a VPN installed on a gateway to access our business network using IPFire. As we do not need layer 2 information over VPN, we do not have a bridged tap device but a tun device, which only does the layer 3 routing.

Now, the Internet is full of tutorials how to use Steam In Home streaming over a VPN connection. But: since Steam uses UDP broadcasts for service discovery and our VPN and the office network are different subnets, this does obviously not work because of our VPN setup.

At this point I decided to use ZeroTier, which can be configured as a layer 2 VPN (virtual layer 1 in ZeroTier terminology).

Now the strange things begin:

The Linux workstation and the MacBook Pro do see each other over the ZeroTier network and I can ping each other. But they do not see each other on Steam. A workmate told me, he got it working using a Windows machine. So I borrowed a Windows device, installed Steam and ZeroTier and it worked. I could see the Linux workstation and the MacBook.

So, here is my guess: the discovery process for macOS and Linux is broken. In the Steam logs I could see, that they are listening on 0.0.0.0, but I could not see on which interface they are sending the broadcast packets. I assume that they are sending the packets on the default interface, which is not the zt0 interface set up by ZeroTier. But on Windows it seems to work and after the *nix machine sees the Windows computer, they are able to set up the connection between them.

My question is now if you have any idea how I can fix this problem. I've somewhat run out if ideas. I would be grateful for any help.

P.S.: If this is the wrong stackexchange site, please let me know. I will then repost this question on the appropriate page.


Update:

My assumption was true. I had a look into Wireshark and could clearly see, that Steam uses the first non-loopback interface. I guess a redirection of the Steam ports could solve the problem. What do you think?

  • actually, steam uses the first interface it finds with a default route. this is why if i restart the steam client on my linux desktop (which also handles the pppoe adsl interface) it won't see the steam client on my win7 steam "games console" until I restart steam on that too. I could fix that by running steam in docker or something but it's not important enough to overcome my laziness :) – cas Aug 1 '17 at 11:36
  • btw, does your employer and/or their IT staff know what you're doing? you've just punched a hole through their firewall so you can play some games on their desktop machine. this is sometimes spelled "sackable offence". and unless you have a very fast connection at home and at the office, performance will be awful anyway. – cas Aug 1 '17 at 11:39
  • Everybody knows what I'm doing. In fact, my employer is curious if I can get it working. We are pretty free. We are just 10 employees and managing our infrastructure by our own. And I think I know what I'm doing so far :) – user244362 Aug 1 '17 at 11:48
  • 1
    ok, that's cool. just making sure that this wasn't a case of not realising that a new desktop gaming pc costs a lot less than having to find a new job. – cas Aug 1 '17 at 11:51
  • so yeah, the iface discovery process is broken. and there's no way to tell the steam client to listen on a specific interface. IIRC there's a bug report in one of the steam discussion or support forums about it. I'm pretty sure I posted one about that some time ago. i didn't get the impression that it was a high (or even low) priority for valve. – cas Aug 1 '17 at 11:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy