The NAT traversal logic here is really basic and won't hold up well in practice.
A good chunk of NAT devices will pick external port based on [src ip/port, dst ip/port] combo, not just [src ip/port], so "WAN IP/port" you get from STUN will get you nothing useful. Not by itself.
STUNs should be used for discovering the pattern in NAT port overloading logic and then using it to predict which port your peer will use towards you if you were to try and connect now.
That is, you need to know the overloading pattern and then also time stuff correctly.
For that reason you will need a rendezvous server and it's also the best to let the server drive the whole process (as opposed to what STUN-based setups do, which is to let clients do it).
PS. In my past life I made a P2P VPN called Hamachi, which used all this stuff very extensively.
Anyone know if there are any open-source libraries which wrap this all into a usable `get_{tcp,udp}_connection(peer_id)` API, preferably with fallback to a relay server? I feel like there really should be, but nearly all the tools I’ve seen with this functionality are closed source, and the few open-source things all do their own custom logic rather than a shared library :/
Hamachi letted me play Command and Conquer online with my friends! We used Hamachi all the time to be able to play games online through LAN. Thank you so much for improving my childhoods quality of life :)
It's not a terribly complicated subject, but you do need a fair understanding of IP and UDP. TCP too, because it is possible to establish direct TCP connection through two NATs using the symmetrical open clause of the TCP handshake. Looks like magic when you see it work for the first time.
Stevens' book is a must read, yes, but it has nothing even on NAT (iirc), leave alone on working around it. Look at how NAT works, what types of it exist, etc. Then look at "hole punching". For bonus points skim through p2p-hackers mailing list archives from 2003 and thereabouts.
Very little has changed in this area since mid-00's, people just rediscover and re-implement the same thing over and over again. Few get it 100% right (IMO) due to sticking to prediction being done client-side. That's inferior to the server doing it, because it gets you more precise timing and better prediction rate.
Am I the only one that has long since given up traditional desktop streaming software like TeamViewer/AnyDesk and the like for game streaming software (Parsec, Rainway, Steam Remote Play, etc) that just happen to offer desktop streaming because they can? The actual streaming tech in those feels worlds ahead in terms of quality/efficiency/stability/latency. And the UX has generally felt better as well with much more streamlined onboarding and everyday operation.
I personally have been using Parsec most often these days and might even start paying money for it soon for some of their advanced features, as they've recently pivoted their marketing towards the productivity side, which is a move I'm happy to support with my wallet. I honestly don't see a reason why someone would use any of the traditional players in the space these days for personal use. Not sure how the tech in this project compares, but I think it should try to measure itself against something like Parsec/Rainway rather than TeamViewer/AnyDesk if it wants to compete at the state of the art.
I think the difference is that Teamviewer/AnyDesk is intended mostly for corporate usage. Their software is optimised for images that are mostly static, letting them get away with much less bandwidth without making text blurry or illegible. Standard H.264/H.265 encoded video needs sharpening and extra filters to be both low bandwidth and legible in many cases.
Parsec and friends use more bandwidth and hardware resources to get a stream going, but that stream is of much higher quality. You probably won't be running a fully-staffed remote support company over DSL or basic cable with Parsec, but with Teamviewer you just might. I've made several remote support connections at the same time on ≤8Mbps down on a simple Core i3, you just can't get that done with a game streaming solution like Parsec. Modern streaming services also require hardware encoding support or their CPU requirements are huge, and the endpoints support software often connect to isn't that powerful.
Microsoft's RDP solution in excellent on all fronts, though. Normal H.264 encoding for moving content and static-optimized codecs for office machines, all with heuristics to switch codecs on the fly. Sadly, this is all locked away behind licenses for consumer devices, but the technology is there.
Yes, RDP is mind blowingly good compared to VNC and most other tools for "office" applications. I'm fairly sure for non video/game content it just sends the "vectors" of the UI over which get rendered on your local machine instead of compressed bitmaps (I could be wrong on this though).
You're basically correct. RDP can model and transfer data semantically - i.e. it's not just pixels, but higher order objects like toolbars, buttons, and the like. VNC and most others just do raw image/video transfer, with whatever codecs and compression they choose. Of course, RDP can only use semantic data for apps that support it, and it makes sense these would be official MS apps first.
Just to add to the anecdotes.. I regularly run RDP over VPNs and web gateways all over WiFi and only occasionally feel a little bit of lag, otherwise it's so fast I forget it's not my local device. I largely use CLI's, IDE's, Office, web browsing, and often tell myself off for watching YouTube videos over the RDP connection instead of locally.
i use rdp over zerotier and it works like magic. the "server" is having a 30mbps connection so i'm limited by that. still, the experience of over 15 concurrent users is not bad.
i do excel, word, Libreoffice, firefox, heck employees even watch youtube on firefox over rdp and its "slightly" difficult to have it desync video and audio sometimes but it works.
my only problem is getting rdpwrap to patch every 3-4 months. i run ltsc so i should be getting less updates but what do you know, it messes up and all hell breaks loose.
Huh? Something must be seriously wrong with your network. I did everything via RDP (including watching movies) for years, over ADSL, with no issues whatsoever.
You can already stream games from a Linux machine with Steam and then get to the desktop. It's baked in, but I'm not sure you can directly stream the desktop without launching a game before, but it works pretty well. I managed to play a game running on my Linux desktop in the UK while being in mainland Europe ! Wasn't a bad experience at all.
With the protocols you mention, are you able to reach an unattended machine and take control of it or does someone have to be at that machine to grant you remote access?
If I've got 350 desktops to manage, is there a console/dashboard for doing that with Parsec? The pricing page looks like they want you to manage a small team or go 'Enterprise', which is 'Call for pricing', which automatically makes me think I'll be wasting time.
No. It's meant for giving user's access to their personal (physical, not VDI) desktop or for giving access to a pool of physical desktops to people to share.
This is one thing I'm surprised the open source community hasn't developed a popular alternative for: Teamviewer.
The core idea is simple: a video stream from one computer to another, with mouse and keyboard controls sent the other way. Connection negotiation can be done Magic Wormhole style, via basic STUN, encryption can be done in a number of ways. Add some clipboard and P2P file transfer features and you've got most of Teamviewer/Anydesk/whatever implemented. There's VNC, but that's horribly outdated and the UX is absolutely terrible.
I think there's a business to be built here; open source remote support with a Gitlab-style self-hosted option companies can put down in their own networks, or have them pay you for management and servers.
This project is a good starting place, as any. With some tweaks you could probably build this into a end-user friendly system with your usual numeric code and random password. There's a business to be built in this space, I'm sure of it. I wish I had the expertise to take advantage of that.
Code signing for Windows is a pain for anything self hosted. I tried every open source, self-hosted option I could find last week and none of it was usable. IIRC the only one that had signed executables was Remotely and it was a 150MB client that bundles .NET.
All the rest seem to copy the terrible design of on demand code signing and that doesn’t work. If you get an EV certificate for instant SmartScreen reputation the key is on a HSM. If you get an OV certificate that is easier to automate with you need to build SmartScreen reputation which is brutal.
The RuskDesk project mentioned below was the most interesting to me. It’s a small executable and works pretty good. That’s enough to tell me that someone should be able to build a great product if they have instant support executables signed with an EV certificate.
What it comes down to though is that everyone needs their own code signing certificate or someone needs to run a matchmaking service. I’m sure you could build something that works well with Cloudflare Workers/KV by sending hashed (+salted) IDs to a matchmaking Worker. When a customer reads me the ID I know the secret and can tell the matchmaker “here’s the secret, please redirect the client to my self hosted server, relay, etc. at support.example.com.”
Also, Screego is another interesting project to check out.
SmartScreen becomes less of a pain when people start downloading the software more. In fact, if you don't have a lot of downloads, SmartScreen will block your executable even if you pay for the privilege of signing your executables! If you sign your executable + config files on the fly, you end up with SmartScreen warnings all over the shop!
A possible solution would be to distribute the client through something like the Windows Store on Windows, and a URL connection handler. The support-receiving website (or intranet support page) could work by opening a URL like remote-support://internal.domain.eu/listen from a web page and if that fails, link to the Windows Store and install directions instead. An unsigned, backup download of unsigned executables can be added to that download page if you so desire.
Theoretically, you could also set up some kind of DHT or TOR-like network where nodes can just find each other. You wouldn't want to send standard Bittorrent or TOR traffic without warning in corporate networks, of course, but the technology exists.
For businesses, the unsigned executable with config could just be distributed by the IT department with their own certificate or the necessary exemptions, and launch an autoconnect daemon, if necessary.
The _real_ challenge, I think, for building such a tool is that if it works well, scammers will use it and slander your product. Some might even patch out any warnings or alerts that you add to protect innocent people from scams. Scammers aren't intelligent enough to make their own RAT, but just one tech-savvy criminal could make loads of money with some slight modifications.
> In fact, if you don't have a lot of downloads, SmartScreen will block your executable even if you pay for the privilege of signing your executables!
There's more nuance here which OP is alluding to. If you form a corporation and get an EV cert, you will not get a SmartScreen block, not even on your very first download. Immediate SmartScreen reputation is the point of getting an EV cert for this; Microsoft says this explicitly. If you get an OV cert (the only kind that an individual developer can get!), you will get blocked and will have to build reputation.
As an individual open source developer, I have an OV signing cert :( At least it shows my name on the SmartScreen prompt.
You don’t need to code sign on the fly in order to append “config” data to an authenticode executable.
I’ve never done it myself but there was a posting here about 8 years ago about how Dropbox distributed their installer and I took a quick look at it: https://news.ycombinator.com/item?id=8204454
> This is one thing I'm surprised the open source community hasn't developed a popular alternative for: Teamviewer.
That's because it's not only a matter of software but also a matter of service (STUN is not enough, TURN is required in many situations. And someone has to pay for the servers and bandwidth...). If IPv6 had succeded instead of IPv4+NAT, maybe the situation would be different.
In terms of software, the open-source x2go (based on nomachine NX libraries and protocol, see https://wiki.x2go.org/doku.php) has been very efficient in my cases when bandwidth was limited and when I had no big NAT issues.
I enjoy using x2go, but it's not exactly an easy to use system. If either end of the connection needs to change firewall settings or enter IP addresses, it's already far behind on usability. It could work with some setup in corporate environments, but doing this right is quite a pain for smaller businesses.
I agree that STUN/TURN servers are a necessity, but they're not _that_ expensive to self-host. You could stuff the STUN/TURN feature behind rate limits for the hosted version or put them behind a pay wall entirely so companies don't have to mess around with that stuff themselves.
This is something I've wanted for a while too. With TeamViewer I can get the client, log in, and then I can see all my other logged in machines and do remote control or exchange files. I don't need to worry about NAT or dynamic IPs etc and it works across Linux and Android and even Windows.
I'd really like to replicate this, even in a really simple CLI way but I haven't found all the right blocks to fit together. Naturally I don't have TeamViewer's account servers to rely on, and ideally I'd not use any centralised/third-party service at all (e.g. Zerotier or Tailscale).
My current idea is to make a GNUnet VPN and then use avahi to discover SSH or VNC servers, then I can use Remmina as a fancy GUI. This will probably be slow and difficult.
There are plenty of FOSS tools that do almost what I want, but none I've found quite gets there yet.
I noticed that as well just now. I have to say, emphasising open source remote desktop when in fact the server is closed software is a big antipattern and leads me to avoid the software already.
It seems like there's a basic version of the server software that's open source (only does one connection, no NAT or encryption, etc.) but someone could make a server based on that. It could get the bitwarden-rs treatment to make it more enticable.
What does the open source angle add to compete with the existing offerings? From what I can tell they are free for personal use and businesses pay, as you suggest. I’m not too familiar with these products.
The same Gitlab offers: the ability to customize and configure the system the way you want it, and the ability to patch the system even when the vendor stops supporting it if you're intent to. It also adds a small factor of trust because you can see the server code; there's probably important, private files flowing through the relay servers, after all.
The rates for decent remote support software are terrible. For €150 per month, you can use three simultaneous connections across your entire organization, limited to a certain number of users who might possibly use the system. Teamviewer once offered lifetime licenses, but then they inserted ads for their subscription model into the lifetime customers to get even more money out of them.
[Not open source, but] Liteviewer has been the best of what I could find for running a tiny pseudo-MSP on the side. Despite their site looking like it was ported from Geocities, the app itself has been pretty solid for my basic uses, and ~30 machines are free, I believe. I'm not affiliated.
These tools behave like trojans, allowing complete control over a machine. Why would anyone want to run something like that without being able to check for malicious code is beyond my comprehension.
For those wanting a simple Linux alternative: If you have SSH access as the same user as the one running the X11 session on the remote host, you can do this:
take a look at the way this type of software is used to abuse and scam older people who have no clue about how computers (and the associated scams work)
Take a look at any single video on any single one of those youtube channels and you will see that this is a problem that needs to be at least considered. It could be as simple as a massive warning detailing the scam on the installer.
Edit:
In fact heres a link
Its both hilarious and depressing all at the same time.
@mp85, I don't think your MIT license is compatible with AForge.NET's LGPL license. I'm not a lawyer, but I'm guessing your license should also become LGPL.
The LGPL is compatible with pretty much all licenses, even proprietary ones. Also the MIT license is GPL compatible and compatible with pretty much all licenses too.
I wanted to thank everyone for sharing your experiences, point of views, for the support, for suggestions, and for sharing projects similar to P2P Remote Desktop. Thanks for making this discussion very interesting and constructive.
Gratitude is the fairest blossom which springs from the soul. (Henry Ward Beecher)
Re. remote desktop stability, not sure if my experience as someone censored by the GFW makes any sense, but when my RDP to oversea Windows host become unstable, Jump Desktop gives me fast and stable connection, and for free. Their program is lightweight and fast too.
More or less, in this case apparently there is no server setup. In your case you probably have to configure a wireguard server and forward the router port. Here is just using a public stun google server for discovery
A good chunk of NAT devices will pick external port based on [src ip/port, dst ip/port] combo, not just [src ip/port], so "WAN IP/port" you get from STUN will get you nothing useful. Not by itself.
STUNs should be used for discovering the pattern in NAT port overloading logic and then using it to predict which port your peer will use towards you if you were to try and connect now.
That is, you need to know the overloading pattern and then also time stuff correctly.
For that reason you will need a rendezvous server and it's also the best to let the server drive the whole process (as opposed to what STUN-based setups do, which is to let clients do it).
PS. In my past life I made a P2P VPN called Hamachi, which used all this stuff very extensively.