OpenVPN Client (with poll)

[girish]

@Lonk Thanks for the write up! So what I am thinking is that instead of making people install an app, maybe we can integrate this into the box code itself as a "service". Service is simply just a docker container (addon which an app uses like mysql/postgres/redis/mongodb or just something standalone like sftp/graphite etc). Then in the box code, maybe in the Network view, we can add a way for people to upload openvpn credentials. This simply configures the openvpn client docker container. This also makes it trivial to route an app's traffic via this container.

@nebulon thoughts?

[mehdi]

@girish I like the idea of having it integrated into box, I think the user experience would be cleaner. However, like @imc67 just said, some people would prefer a Wiregard client, some others will also prefer an L2TP client, ... I think the UI you guys design should take multiple protocols into account from the get go.

Also, re-reading your post, I think you may be saying that you would want to route all traffic through the VPN. However, I think a significant part of users would like to route only a few of their apps through a VPN, not everything (for torrents maybe? )

[girish]

@mehdi Ok, I adjusted my reply. I didn't mean to say all Cloudron traffic should be routed by the container. One can select it at the app level (which is actually the easier option anyways when having thevpn client running as a container).

As for OpenVPN vs wireguard, I think supporting both makes sense. But of course, it's probably OpenVPN to start with because that's what @Lonk has started on.

[Lonkle]

@girish said in OpenVPN Client (with poll):

@Lonk Thanks for the write up! So what I am thinking is that instead of making people install an app, maybe we can integrate this into the box code itself as a "service". Service is simply just a docker container (addon which an app uses like mysql/postgres/redis/mongodb or just something standalone like sftp/graphite etc). Then in the box code, maybe in the Network view, we can add a way for people to upload openvpn credentials. This simply configures the openvpn client docker container. This also makes it trivial to route an app's traffic via this container.

@nebulon thoughts?

I agree with the user experience of this completely, and would really set you apart in the intranet world.

I'll give you the full app this week. along with the hotpatch to make it work. Just so you can understand it's mechanisms a bit bitter.

And again, everyone, I'll be adding more protocols to this as time goes on, whether it be as an add-on, or as it's own app. OpenVPN is just the most common right now and it's the easiest, so don't worry, I've left room for more than one protocol.

[girish]

@lonk I would also like to have an understanding how routing works (if you have this figured out).

Specifically, when I visit an app (which is routed via the VPN with network=container:vpn), is outbound traffic and inbound traffic all going via the VPN? I assume that when you visit the https site, it will come directly but then the responses go via the VPN, is it?

[imc67]

@girish and all I think it's good to clarify the requirements of this functionality in a more logical way, let me try/suggest:

1. Do you need a VPN connection FROM an app to a VPN server?
   Yes, next step
   No, stop reading

2. What kind of VPN protocol?
   OpenVPN
   Wireguard
   L2TP over IPsec

3. What kind of connection settings?
   Always connected and auto-reconnect
   Schedule based
   etc.?

4. What kind of routing?
   App can only be reached via VPN, access via Cloudron IP/subdomain is blocked
   App can be reached via VPN and via Cloudron IP/subdomain
   etc.?

5. Do you needs mounts over VPN?
   ie. networkshare on VPN server side mounted as external storage for Cloudron app (this would be awesome!! )

If we discuss it by the number the discussion keeps clear, additions are very welcome

Marcel.

[Lonkle]

@girish said in OpenVPN Client (with poll):

@lonk I would also like to have an understanding how routing works (if you have this figured out).

Specifically, when I visit an app (which is routed via the VPN with network=container:vpn), is outbound traffic and inbound traffic all going via the VPN? I assume that when you visit the https site, it will come directly but then the responses go via the VPN, is it?

Yup, all outbound and inbound traffic flows through the VPN, the only exception is the web interface, which as you guessed, is direct to Cloudron and routed through Nginx like any other app.

[girish]

@lonk said in OpenVPN Client (with poll):

Yup, all outbound and inbound traffic flows through the VPN, the only exception is the web interface, which as you guessed, is direct to Cloudron and routed through Nginx like any other app.

So, inbound connection to https will come via nginx. But the response (to the https request) will get routed via the VPN?

[girish]

@imc67 said in OpenVPN Client (with poll):

I will answer this from my point of view. But this is @Lonk's baby and he probably has different use cases.

The most important thing is the use case (and not the implementation). A use case was to hide the IP address of apps making outbound connections. Example, ttrss exposes my home IP address currently since it queries all the feeds straight from my house :). A way to circumvent this is to have ttrss route it's network traffic via a VPN. The VPN server can be some service or maybe even some other Cloudron server having OpenVPN app installed.

If you or others have different use cases, please feel free to open a separate thread. OpenVPN has so many different scenarios/use cases, so it's good you brought this up first and foremost.

To answer your questions, then:

Do you need a VPN connection FROM an app to a VPN server?

Yes. This way the server's IP address is hidden.

What kind of VPN protocol?

First step is OpenVPN. We have to make it work before we try other protocols. Besides we don't have a wireguard server on cloudron.

What kind of connection settings?

It's always on. The VPN tunnel is selected on a per-app basis.

What kind of routing?
App can only be reached via VPN, access via Cloudron IP/subdomain is blocked

App can be reached from anywhere. So, I can still view ttrss from my mobile app and browser without connecting to some VPN.

Do you needs mounts over VPN?
ie. networkshare on VPN server side mounted as external storage for Cloudron app (this would be awesome!! )

No.

[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?