Today we’re pleased to announce the beta release of Raspberry Pi Connect: a secure and easy-to-use way to access your Raspberry Pi remotely, from anywhere on the planet, using just a web browser.
It’s often extremely useful to be able to access your Raspberry Pi’s desktop remotely. There are a number of technologies which can be used to do this, including VNC, and of course the X protocol itself. But they can be hard to configure, particularly when you are attempting to access a machine on a different local network; and of course with the transition to Wayland in Raspberry Pi OS Bookworm, classic X remote desktop support is no longer available.
We wanted to be able to provide you with this functionality with our usual “it just works” approach. Enter Raspberry Pi Connect.
Gordon Hollingworth
Pi Connect uses WebRTC, and a daemon running on your Pi listens for incoming screensharing requests from the Raspberry Pi website to connect the VNC server on your Pi to the VNC client running in your browser. The service is in beta, it’s free, but the one major downside is that for now, there’s only one TURN server for this service, located in the UK, but they might set up more of them if demand is high enough.
If you want to try this service on your own Pi running Raspberry Pi OS, you’re going to need to be using a Raspberry Pi 5, 4, or 400, using the latest version of the operating system running Wayland. Update your operating system, install the rpi-connect package, reboot, and you’re good to go.
So it’s free “at the moment” using the closed server infrastructure in the UK. I’ll give it a try, but if it’s not “free forever as in free beer” I might as well stick with something like NoMachine.
cpcf,
I realize how futile it is to complain about this now, but I do find it regrettable that the internet and software ended up evolving without global end to end connectivity during it’s growth phase. This wasn’t always the case, in the 90s it was normal to have computers directly routeable on the internet. Popular applications like quake supported this without any other dependencies. Of course IPv4 was a connectivity catastrophe waiting to happen. Now everything is designed around centralized services and I don’t see any going back even if IPv4 could be displaced today. The tech giants and game publishers are simply not interested in designing technology that takes their servers out of the loop.
I do my best to avoid centralized services for the networks I manage, but for the public at large I’m afraid it is a lost cause. Our tech giants would really need to push this but their business interests simply don’t align with end to end connectivity.
It’s a kludge, relying on a third party service to get around NAT.
Much better to give it a routable IPv6 address and dynamic dns if necessary, then you can use whatever technology (vnc, ssh etc) to reach it.
bert64,
You’re right that it’s a kludge, and I strongly prefer directly connecting to devices too using ssh/vnc/etc. But the kludge exists because the whole internet is a kludge. NAT is terrible, but then I don’t have a choice of service providers to avoid it. If I want IPv6, I need to route that over an IPv4 connection via a VPN to a 3rd party service provider (ie hurricane electric) because I can’t get it locally. Damn monopolies!
Even if I had ipv6, android’s stack is incomplete and lacks dhcp6, which means I cannot subnet my own /64 IPv6 block without once again resorting to NAT, which is beyond stupid! That’s 18446744073709551616 IPv6 addresses that cannot be subnetted because some google engineer wants to play network admin dictator. He’s personally responsible for holding back corporate IPv6 adoption in favor of IPv4 for over a decade.
https://issuetracker.google.com/issues/36949085
It’s so stupid. No other platform has this problem: ios, mac, windows, linux….what an ass.
Anyway I got sidetracked You’re absolutely right about kludges but they exist because our technology stack is such a mess when we peek under the hood, haha.