I am referring to the following topic. We had some discussions about the public-url and it’s bandwidth. Sometimes it appears to be very slow so @mccollam came up with the following advice:
Is it possible to set up my own VPN? So that the device connects to my VPN instead of resin.ios official VPN?
PS.: Originally I intended to post this as a comment to an existing topic but somehow I accidentally created a new topic. I am not sure if I can move or delete this so I am leaving this here.
Yes, you can set up and connect to your own VPN from a device managed by resin.io. I’d be cautious about saying “instead of” the resin.io VPN though – this would be an additional VPN connection in parallel to the default VPN connection.
The default resin.io VPN connection is what allows you to access things on the device like logs, the terminal, real-time status (running/downloading/installing), etc. We also use it to tunnel in the Device URL if you turn that on.
So if you set up another VPN in your infrastructure somewhere, you can connect to it from the device exactly as you would if the device were not managed by Resin. It just becomes one more connection outbound from your device, but doesn’t replace the resin.io VPN.
(Having said all that, it is possible to turn off the default VPN. You lose the real-time aspects I mentioned and devices will only get updates whenever they poll, so if you set the polling interval to be very long it could be a long time before they notice a new update! But it can be useful if you have very limited connectivity, bandwidth, or power. There’s a blog post that goes over exactly how all of this works if you are interested.)
I’ll see if I can find some time to poke at this a bit and maybe provide an example. It could be useful to lots of people, I think!
Ok I see. But that means that I have to start a VPN Client in my Container since I cannot hook up another VPN to the underlying base OS I guess, right?
Exactly. Your container will have the VPN client, configuration, credentials, etc. embedded in it. You would just start the VPN client as part of your container startup.
Ok. Which is very similar to starting ngrok from within the container. But since we are currently working with a single user-container this will somehow be against the “one process per container” thing. Somehow. But it will work of course.
I’ve just set up a container which starts ngrok using systemd and exposes the containers web server through the ngrok servers. I might share this since this also is very interesting for a lot of people I guess since it does quite the same and ngrok is a very fast and reliable service.
Also ngrok allows configuration of the tunnel via API for enabling things like whitelisting, etc. Nice stuff.
@mccollam @imrehg The following might be interesting for you, too.
I’ve managed to set up ngrok.io from within a container and ran a small Flask Application that communicates over Web Sockets (SocketIO) and sends a ping from the server to the browser. The browser returns it and the average time this takes is being measured:
Here’s the result:
On the left you can see the flask page and the ping/pong being send through resins public-url. Result is about ~350ms. On the right the same browser connects to the same device (at the same time) using the ngrok url. The result is about ~80ms!
Very nice! This is something I’m going to have to play with as well!
It makes sense that the resin.io VPN is slower – it’s not optimized for this sort of use case but rather for management and status of containers on devices. The device URL forwarding is more a “nice to have” for things like debugging or simple remote management rather than a platform to build a remote connection on. (That’s generally where we’d expect people to use a service like ngrok or their own VPN.)
Ok. I see. But I remember some posts on your blog where people used the public URL for tunneling sensor data or web APIs / web sockets.
I guess that in our case where we are using the public URL for our devices to have remote controlling via web socket or http API the speed of the tunneling is totally ok.
Even if you don’t intended the public URL to be a robust remote connection to a device - you might change that opinion since it offers so much potential!
Oh it’s definitely available if you want to use it for that 
It’s just not something we’ve focused on optimizing for real-time use cases.
I would still opt for a top tier VPN over something that wasn’t designed for that, my friend.
It’s not that hard, really.
I would choose a top-tier VPN. I can’t understand why you have such problems with VPN. I found good website TopVPNchoice with reviews, rates and even with plans. Choose with the best rates is
Nord VPN. Everything works, no problem.
Generally, average these issues come with an average vpn software and that is why it is important to choose the right vpn according to requirement. Like you mentioned, It is indeed good vpn service. I would also recommend to read reviews from cnet, pcmag before choosing any vpn service
