VPN tunnel for apps

[Lonkle]

Okay, so there's a problem here:

appPortBindings.hostPort needs to be set for all of Cloudron's containers or Cloudron turns them off. The only reason I know my OpenVPN client works is because I curl icanhazip.com before box stops the container for not passing all of it's "checks."

But this is a special case. To connect to the VPN Client - the app container can't have a hostPort as it inherits that from the VPN Client as part of the connection. But Cloudron requires the App published to have a port (I hardcode it not to), so even though the app works, Cloudron will stop it from running eventually once it fails enough checks until I figure out how to deal with this reverse proxy thing works.

[Lonkle]

I just have to figure out how to let appdb.js know that there's an actual http port set, it's just not in the **connected-to-vpn-client's`` app / container, it's defined in the OpenVPN Client's app / container.

Barring figuring that out though, I have to have the openvpn-client app mirror the ports that are exposed for every app connnected to it (right now, I'm just letting one container connect since Cloudron doesn't support more than one exposed port). Ahhh, so basically the OpenVPN client's http port has to be variable depending on the connecting app (or apps if people want to connect more than one other app to it at a time - I only personally need one app connected to it). So that's manifest.js code to also modify to get this to work.

[Lonkle]

I'm climbing a mountain too tall for me rn.

[marcusquinn]

The first step in making any tunnel is digging a hole

[Lonkle]

Nice metaphor for a VPN tunnel app. I’m so close to get this working. I found the SQL that inserts the httpPort into the DB so I’m going to try to have the container “attaching to the openvpn client” inherit the port and port type from the VPN Client while still having it be discoverable by the database. Let’s hope this works.

[Lonkle]

Alright, I got the container both running and entered into the database (I'm pretty sure). So Cloudron can "see" the app. I copied the exposed and host ports to the container returned at the end of createContainer while nulling them during the containers initialization.

That seems to be enough for app discovery, now to see if I can get the reverse proxy working which will be the last piece of the puzzle I hope.

[marcusquinn]

Dig, Forest, Dig!

[Lonkle]

@marcusquinn I’m not positive but I think the Nguni reverse proxy is being fed a null or 0 hostPort. The exposedPort is part of Cloudron’s environment variables. Maybe I’ll add the hostPort to that and read it back during reverse proxy configuration.

[Lonkle]

I hope nobody finds me logging my development on this app to be annoying. I needed a place to keep all of these new concepts in my head. I’ve never worked with Docker or Cloudron before this month and I’m trying to jot down my experiences for me to read later until I complete this.

If I hardcode the health checks to all pass. My app connected to the VPN stays connected and it’s terminal working but never gets past the “Starting” phase until it times out in like ten minutes (the reverse proxy doesn’t work so neither does Let’s Encrypt...which then times out the app). This is because it’s reverse proxy isn’t set up correctly. I believe that the NGINX reverse proxy either gets the wrong hostPort or the wrong exposedPort or both.

I’m actually amazed that I got this far. Because both the hostPort does make it into the database now for it to be discoverable by Cloudron. But why the reverse proxy WriteNginxReverseConfig receives different info than `apps.js’ “add-to-db” function (since that happens first) is really confusing. I’ll keep working on it though. I can’t hardcode (wellll...I technically can for the same container but don’t want to).

Another problem is that my NetworkMode to container changes only (for now) take effect upon installation. Have to figure out why that is - but I also have some guesses.

Nobody told me box code was this hard.

[Lonkle]

And I’m still using the app’s FQDN variable to hardcode its attachment to the VPN rather than its manifest ID since I can’t find the function to read an app’s manifest to get its ID. So much more work to be done (I need the VPN client’s containerCreate option exposedPort(s) to be variable depending on its ID and the app connecting to it) - which is another reason I need to learn to use manifest data. But that’s a simple function I’m sure I’m missing somewhere. @girish - do you know it off the top of your head?

[mehdi]

I suddently have a doubt about what your goal is ...

Are you trying to make the app itself, when it tries to connect to an external service, use the VPN, but still be exposed through normal internet?

Or are you trying to restrict the users from accessing the app itself if they are not going through the VPN?

[Lonkle]

I’m trying to accomplish your first idea.

I made a Cloudron app called “OpenVPN Client” and it works perfectly. It can connect to any OpenVPN Server. I put a basic Apache configuration in front of it just to pass the Cloudron’s Health Check.

Now, my use case is to have a singular other app (any app, but I’m using the basic LAMP from the Cloudron store for testing) route all of that app’s traffic through my OpenVPN Client app. I understand other users may want to connect more than one other app and it’s technically possible to do so via setting their NetworkMode to container:open-vpn-id - but that introduces an extra complexity of exposing more than one port which Cloudron cannot do rn (but is technically possible if girish wanted to make those edits). I don’t mind though since my use case is a 1:1 OpenVPN Client + Other Cloudron app connection.

That’s the entire thing in a nutshell. I’ve had to dig into a lot of box code to understand how to make it happen but my OpenVPN Client app is completely working and even passes all the Cloudron health checks but the singular app connecting to it and routing all of its web traffic through it does not pass the Cloudron Healthcheck because a container connecting to the network of another container is forced to inherit all the network properties of that container. That means, the reverse proxy sees no hostPort (Cloudron is looking for it in the wrong place) when trying to configure the app and thus literally stays in the **Starting up...” statuses (with it’s terminal working and traffic is verified routing through the OpenVPN Client).

[robi]

@Lonk sounds like you need an internal network interface for internal liveness checks and external interface for the outgoing VPN traffic and it's checks.

otherwise you're forced to check liveness on the wrong app just because it's routing through it.

[Lonkle]

@robi Well, the thing is. The second app should pass all the health checks just fine. It’s a web app after all that is exposed to the web (right now testing with the LAMP stack’s homepage). The only reason it doesn’t pass the check (which makes Cloudron stop the container) is because Cloudron is setting up the reverse nginx config incorrectly due to it believing the Cloudron app just installed has no hostPort even though it really does.

The nginx reverse config needs to account for this to make the second app connected to the VPN Client app to even work. Because right now all I can do is use its terminal to prove its working. But the Cloudron network is setup in such a way that it’s needed to reverse proxy it’s hostPort to its exposedPort.

My newest idea is to write the Docker randomized hostPort as part of the Cloudron environment variables it holds and then use that in the Nginx Reverse Proxy config if the starting app doesn’t appear to have one.

Working on box code is harder than app code (especially because I can’t access its database outside of the command line and, well...I don’t really know SQL syntax). But shoutout to @nebulon for making it easier for me!

[Lonkle]

This also leads to the discussion of exposedPorts in the OpenVPN Client app's side of things. Right now, it has to mirror each of it's connected containers (their can be multiple) exposed ports, but Cloudron (for good reason) has restricted app's exposed ports to one.

Dynamically assigning just the OpenVPN's exposed port(s) on demand (to logically sync up with the app that's connecting to it) is needed here and does 100% require a restart of the OpenVPN Client app unless we decide to go the route of opening x amount of the common ports and restricting multiple Cloudron app's from connecting to the OpenVPN Client to one exposed port per app (which ironically could be worked around with a dynamically assigned port forwarding to the real second containers port which then finally reverse proxies onto the hostPort + port 80 / 443 - but that seems like two much work just to connect more than one app per exposedPort at a time).

[mehdi]

(Disclaimer: I am no expert on docker networking magic)

I think instead of trying to find a way to expose the ports from the OpenVPN container, you should instead try and find a way to make it work directly from the app container itself.

Even if you do make it work for the exposedPort (which, I think, refers to the main web port exposed by the app, the one which is behind the reverse proxy, to expose its web interface and such, that's why there's only one: there's only one web interface), you're gonna have trouble with the extra ports (the ones defined in the manifest here https://docs.cloudron.io/custom-apps/manifest/#tcpports ) for apps that use these.

[Lonkle]

@mehdi Well, that would only need to be a box discussion if we wanted more than one other Cloudron app to connect to it at a time. It'd be an interesting discussion on how to make it work with no caveats. But I personally don't see a need to have more than one container connect to the OpenVPN Client container. It's not like you can't add a secondary VPN Client Cloudron app and connect it to another app if you really need more than one VPN connection, ya know?

Since that's how I'll be coding it, as soon as someone tells me how to use the app object in box to "get" the cloudron manifest ID. I'm assuming only girish or nebulon know that off the top of their head though so I'll have to reverse engineer that as soon as I figure out how to get the app passed this reverse nginx configuration barrier (which from the code looks like it's reading hostPort as null which is why no apps are working). It would be nice in that situation to know the function to get the hostPort of another container based on manifest id (my OpenVPN Client app to be exact). But once I RE those last two functions, I can do this.

[Lonkle]

Maybe these functions exist, maybe they don't. REing is hard. I've never really coded in Node (or used Docker) before this month so these are all new concepts to me.

[Lonkle]

Oh, I think the answer to my first question was really simple: app.manifest.id. ‍️

Last thing is - I still need to find a way to get either container environment variables or the app object via only knowing the the cloudron manifest id. Then this should work perfectly.

[Lonkle]

I mean, actually that would create a possible more than one object returned scenario.

That's fine though, I'll just take the first app of that mainfest id (since more than one Cloudron app with the same manifest id can be installed simultaneously).