OpenVPN Client (with poll)

[imc67]

@girish I think it's a pity if you create core box functionality for just one use case.

My "steps approach" was meant from a Cloudron user/admin perspective and that way, depending on the outcome it creates many use cases.

My favorite UC is: Wireguard, always connected, app also available via Cloudron (sub)domain and a mount of a folder on VPN server side.

Maybe creating "options" in box code you can open up already more than one UC?

[girish]

@imc67 In your case, is the folder mounted via nfs over VPN?

• Cloudron 6 will have a way to mount directories from the host into apps. This is already done.
• OpenVPN/Wireguard client is a built-in service. You configure what the client connects to say in the Network view of Cloudron. This is what is being worked on.
• You can then set the network of an app to this openvpn client. This is also what is being worked on.
• So, if you make a NFS mount that goes somehow via this openvpn client, then your problem is solved, no? I assume just putting an entry as nfs mount magically works, but I don't know. Currently, cloudron does manage system disks and mount points, so this has to be done manually (it's a one time task anyways).

I don't really know how the routing works with the built-in service, this is what I was asking @Lonk about. At the end of the day, the service is just a containerized process, so it's just a vpn client. If you can make it work with openvpn/wireguard running on a normal non-cloudron server plus some nfs mounting, it should work with what we are implementing here.

To be clear, when I say "being worked on", I am only giving @Lonk some direction, so that we can make it useful in general. This is not what @nebulon or I are actively working on. This is quite low priority overall (unless someone contributes it).

[Lonkle]

@girish said in OpenVPN Client (with poll)

• OpenVPN/Wireguard client is a built-in service. You configure what the client connects to say in the Network view of Cloudron. This is what is being worked on.
• You can then set the network of an app to this openvpn client. This is also what is being worked on.

This is my favorite implementation, though I'm 99% done with it as a Cloudron "Add-on" app. Very very little needs to be done code-wise to box whether we bring it into box like @girish suggests (which I think provides the most conveyance). If you guys could tell when I was posting it, this was mostly R&D (I'd never used Docker, Cloudron, or Node before), the amount of code that it needs is v small. And it's containerized so it's only running when needed (though I leave mine running 24/7). I suggest one of two option:

• Add a File Chooser in an Cloudron's App Settings to choose a .ovpn or .conf file and after hitting save it will restart the OpenVPN Client Container to pick up the new VPN Server, and rebuild / repair the container that is connecting to it (needed because without a repair, it won't fully connect to the VPN Containers network and error out)
• Add a dropdown in the "Network" Preferences tab to select an app and then a file chooser will appear to add the .ovpn or .conf file.

I don't really know how the routing works with the built-in service, this is what I was asking @Lonk about.

The outgoing and incoming traffic to the app obviously runs through the VPN Client app. Incoming traffic to the VPN Client web apps runs regularly as via any other Cloudron app (this "backend" interface is only needed if @girish decides not to bring the whole thing into box). The only difference for incoming routing to a web app connected to an VPN Client Container is that since they share the same NetworkMode any client that needs to be accessed "from the outside" needs NGINX to route the web app to it's internal IP - 10.0.1.8:3000 (<--- same IP as VPN Client) rather than localhost:randomport. THIS is why there is a technical restriction to one VPN container per App connected to it. Technically you could connect multiples and I encourage that route if the routing was intelligent to prevent any local IP ports from clashing.

To do so, in box is WAY WAY easier than outside of box which is why I recommend it go in box personally.

box can check the exposedPort of an app connecting to a VPN Client Container (I imagine internal non-app containers will work similarly to REDIS except more than one app can connect to one container as long as the local IP ports don't clash). If two ports clash or a different VPN Server is chosen, it spawns a new container and connects it to the chosen VPN Server which box will then connect to the Cloudron app chosen. This would eliminate the "one app per VPN Client Container" limitation existing right now and it will be completely be invisible to the user rather if it's in "App Settings" or "Network Settings."

But this is @Lonk's baby and he probably has different use cases.

I only ever had one use case. I needed one of my custom web apps to connect to certain web app's sitting behind a VPN (access to it's local intranet). And it's working perfectly for my hobby project and hasn't stopped working since it was finished so it's def production ready. I've said all of this to say that I'm done with what I wanted, it's more about what the community @p44 / @girish / anyone else who sees this as beneficial would like to see it done. I'm a perfectionist so I prefer @girish's suggestion of moving the whole container into box (just like REDIS). I'll do whatever the community wants / needs as long as it doesn't clash with my use case (I need to be able to POST to it new VPN credentials and have it restart the VPN container, and rebuild all containers connected to it - which the app already does, but I only needed one app working, so it only works on a 1:1 basis).

[Lonkle]

Note: I'll continue to work on the container regardless if it integrates into box. I want to, down the line, add new protocols (like WireGuard or whatever comes after). But that's the only thing I plan to contribute aside from porting the container to ARM with the work nebulon's doing on the Rasberry PI 4 / Cloudron rn.

[girish]

@lonk Yes, please, take your time. Once you have a "standalone" vpn client container (no ui needed even) we can look into integrating it step by step into box code (after Cloudron 6, of course). In fact, a customer reached out asking if this will support cloudflare argo. So, lots of exciting possibilities.

[Lonkle]

@girish Oh, that's definitely going on the wishlist. I'll make one in the next post.

I think it'll be best for me to actively maintain my "standalone" VPN Client app (which it'll be renamed to when it gets more protocols) - so I can continue to work on it as a proof of concept. I'll commit to that repo and tag releases for your reviewal to replace with the internal (akin to redis) container you use for this.

The app already has a full UI (shows VPN Server Connectivity status and a file chooser to connect to a new one and there's also an API endpoing to POST a new VPN Server config). User logs in via LDAP, the app grabs a Cloudron token from the API thanks to LDAP, and does the restarting / repairing as needed (really only on a server change - restarting the VPN Client, and rebuilding the app connected to it).

[Lonkle]

CURRENT IN 1.0

• Backend interface with full UI and LDAP logging in capability to view the server connected to and change it using a File Chooser for .ovpn and .conf files.
• POST endpoint (it's actually just root), to change the VPN server on-demand from the outside (needs a Cloudron App token).
• Connects to a single other Cloudron app which is chosen right now using a file in the File Manager (there's no UI for this, which is why I'm working with @girish for box integration).

WISHLIST FOR 2.0

• Add direct integration to box working with @girish in doing so.
• Add WireGuard support as per @imc67 suggestion.
• Add Algo support (https://github.com/trailofbits/algo) which is a combination of an IPSEC VPN and IKEv2

[Lonkle]

I'll be uploading 1.0 to git.cloudron.io next week and @girish and I can go from there.

[drpaneas]

What's the status of this?

[Lonkle]

@drpaneas It's still working for me in Cloudron v5.6.3 (current version is 6.0.1), and I'm waiting for @girish to release 6.1 which I believe is happening near the end of this month. I'll port the code over to the latest version of Cloudron's box code. @girish and I will discuss how we want the end user to see / use it.I'm partial to Girish's plan of integrating the OpenVPN Client Container directly within box in the same way the redis container is - so we can upload an .ovpn file inside of an app's setting and it'll automagically spin up an OpenVPN Client Connector and hook into the app so that all traffic goes through it until you disable it within the Cloudron's App Settings.

Though, I don't know if Girish has changed his mind about integrating it in that way, but I do believe that's the best UX for this feature. And depending on Girish's time to discuss this post-6.1, I could see us adding this before the next update of Cloudron.

[Lonkle]

@drpaneas I also noticed you requested access to the OpenVPN Client Gitlab code, I actually still have it hosted in Github. But I'd be happy to give you access when I port it over to Gitlab. What's your use case for this, and are you also a developer?

[drpaneas]

@lonk said in OpenVPN Client (with poll):

@drpaneas I also noticed you requested access to the OpenVPN Client Gitlab code, I actually still have it hosted in Github. But I'd be happy to give you access when I port it over to Gitlab. What's your use case for this, and are you also a developer?

Hi @lonk, the link to github would be more than enough -- no need for extra access to gitlab

You can read about my use-case here

I am new to cloudron, just installed it yesterday

[Lonkle]

Hey @girish, I'll be ready to start full time working on integrating this into Cloudron V6.1 in two weeks. I'll probably send you a couple DMs about how you'd like to implement this. I am personally in favor of doing this in the way you described within this thread integrating this as a Cloudron service. It would work very similar to the way you've introduced redis (and I can explain the technical reason why that's needed in DMs) except the vpn-client service wouldn't be running 24/7 like redis given it's an on-demand setting per app.

[girish]

@lonk sounds great! If you can push out the OpenVPN client at some point, I think I can help in coding the box side as well.

[Lonkle]

@girish said in OpenVPN Client (with poll):

@lonk sounds great! If you can push out the OpenVPN client at some point, I think I can help in coding the box side as well.

I'll try to push the client before the end of this month and I'll do a technical write up when I do so so that you'll have a reference point for how the VPN Client container needs to interact with the box to achieve its functionality. ️

[Mastadamus]

I could really really use this.
If u couple this with an ability to divert searx traffic to the VPN this would be a huge benefit towards at least partial anonymous searching.