VPN tunnel for apps

[Lonkle]

I'm near positive the way to route NGINX properly is to to add another reverse proxy which leads from the Docker randomized app.http port to the exposedPort (AKA app.manifest.httpPort). I'm not sure how though. But I can clearly access the exposedPort's data from either terminal.

In the terminal of either of the two network-bonded apps (the LAMP or the VPN Client) - I can curl (localhost) the exposed ports of either app (the VPN Client or the LAMP) and get back the correct HTML pages.

It's just that the reverse proxy is forwarding it to a port that Docker wasn't allowed to bind. So with no binding, that means no NGINX web page.

[Lonkle]

For people just joining and for me to read this in the future:

Cloudron has a user-defined network cloudron that it uses for all of it's apps and services. I'm connecting my OpenVPN Client app directly to another app (LAMP for testing) using NetworkMode which is the official way to do this. When doing so, both apps share the exact same network space (including both being connected to the cloudron network) and can, in fact, even talk to each other directly (I need to set the OpenVPN Client's exposed port to something ridiculous like in the 50000s so it doesn't conflict with any regular app's commonly exposed ports - but in the end the OpenVPN Client will expose all of it's internal network ports -P for compatibility with all other apps connecting to it - but for now, this will do since I'm just testing).

Now, the NGINX Reverse Proxy resides on the main box level of Cloudron and routes to the randomized Docker binding port of the app which forwards it to it's "real" port (I honestly don't know where the IP translation takes place...I can't find it).

So, solution, place a second NGINX proxy at the randomized Docker app.http port and have that nginx server be inside of the internal network of the LAMP testing app so it can then internally forward the web request to it's exposedPort which is, also, port 80 (for LAMP anyway).

[Lonkle]

^^^^ -- Does anyone know how to do this?

[Lonkle]

@mehdi said in VPN tunnel for apps:

There is no good reason to make all the traffic, even the local one, be through OpenVPN.

All local traffic is local, it doesn't go through the VPN. All of the connected-to-the-vpn-client apps run indefinitely. Eventually after Cloudron says "Starting..." it switches the message to "Not Responding" but the app will continue indefinitely because there's nothing actually wrong with it. It's connecting to all the local services it needs, it's just, this feature was designed without consideration of Cloudron's network. That's why from within the app's terminal, I can access everything locally and everything externally (the open web) from Cloudron and the web sees my VPN Client's IP Address instead of Cloudrons. This is a perfectly running app. Except...I can't expose it's internal IP:ExposedPort to NGINX to have it actually pass the health check (meaning the web app isn't being routed to the right place and I think I need a second NGINX reverse proxy to get me routed to the app's exposed port). It gets as far as app.httpPort and then because there is no binding for the app.mainfest.httpPort (AKA: ExposedPort), it just gets stuck on the web side of things.

I can curl all I want into it the LAMP welcome. But can't access it from outside the container itself.

[Lonkle]

Quick example of all local processes running for the second container:

Oct 02 12:05:28 2020-10-02 16:05:28,718 INFO success: redis entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
Oct 02 12:05:28 2020-10-02 16:05:28,719 INFO success: redis-service entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
Oct 02 12:05:40 [GET] /healthcheck

It just gets stuck at the health check because NGINX is giving it a 502 Bad Gateway since port 80 is not bound to port app.httpPort. That's what I still need to figure out and I think what's best is @robi's double nginx server suggestion. I just don't know how to set up NGINX inside of the LAMP container from box code though I'm sure it's possible.

[Lonkle]

I still think the solution lies in this function:

https://git.cloudron.io/cloudron/box/-/blob/master/src/reverseproxy.js#L463

But that function is setting NGINX config listening on the server's public IP port. I need NGINX inside of the container to forward to the app.manifest.httpPort (in LAMP's case it's port 80).

Or maybe it doesn't need to be inside of the container...since if I SSH into the VPS and do curl ip-address-of-lamp:80 then it returns the HTML just fine.

[Lonkle]

SUCCESS!!!

I'm so close. I can manually edit the NGINX configuration of the LAMP-test app and get it's web app working using it's local IP (not 127.0.0.1:app.httpPort, but 172.18.0.3:80 - the port 80 is what LAMP uses). Both web pages come up for their each individual domain names. WOOOO!

It still doesn't make it past the "starting..." step though. That might be because I'm editing the NGINX file and then restarting the app to make it's web interface work. If the NGINX file was properly created from the beginning the check might pass.

[Lonkle]

Which...now I need to find the function to get the IP address of the VPN container (the app connected to it share's it's IP address).

[mehdi]

@Lonk said in VPN tunnel for apps:

@mehdi said in VPN tunnel for apps:

There is no good reason to make all the traffic, even the local one, be through OpenVPN.

All local traffic is local, it doesn't go through the VPN.

Sorry, I meant: There is no good reason to make all the traffic, even the local one, be through the OpenVPN client container.

[mehdi]

What you should try to achieve is making only the app's outgoing traffic go through OpenVPN, and the connexion between it and Nginx and stuff stay exactly the same as it currently is

[Lonkle]

@mehdi said in VPN tunnel for apps:

What you should try to achieve is making only the app's outgoing traffic go through OpenVPN, and the connexion between it and Nginx and stuff stay exactly the same as it currently is

That is currently the case as far as I can tell. All incoming traffic bypasses the VPN entirely. Outgoing traffic uses the VPN's connection. But the NGINX needs an incredibly minor change. There's no way around that.

[Lonkle]

But the bigger deal is that it works now!

Okay, I know it says not responding but it actually is fully working (web page and everything). The "not responding" status is something I think will fix itself when I get the Nginx IP proxy_pass working. Because it's sort of a race condition as to when I start the app and when I manually rewrite the Nginx IP. And I'll never go fast enough to beat the "Not responding message".

[Lonkle]

I just need a function like getAppByManifestId(manifestID) - and this will be a fully functioning proof of concept. And then another function for getLocalIPAddressByApp(app).

Oh, and I need to change some slight NGINX config, make it more dynamic (Cloudron hardcodes it's proxy_pass to 127.0.0.1 rn and it needs to be dynamic).

[Lonkle]

@girish The post above this one, do you know off the top of your head how to get those values?

[girish]

You can't getAppByManifestId since there can be many apps for a given manifest id. I think you have to store whatever you want in the database in the apps table. Then when you get the app, you can get that information (like say the network id). Sorry, if my answer is totally off since I didn't read the full thread completely.

[Lonkle]

@girish I had actually nailed that issue out actually as a matter of fact. The only thing I have left is getLocalIPAddressByApp(app) - but maybe the app object already stores its internal IP (I didn’t think it did, but it stores a lot)?

[Lonkle]

@girish As for the first function, it was mainly due to me needing to find a way to identify the VPN client app by the only unique identifier I knew. I’ve hardcoded it for my use case rn...but that won’t work for the production version now that I think about it - so I’ll still need to get app data using the manifest.id (com.joelstickney.openvpn-client-cloudron). So when the app that needs to connect to it starts, it attaches to the container ID of the Open VPN client on containerCreate.

Maybe right now I’ll store the things I need in ENV variables and find a way to use the “apps” object to parse through all of them till I find the VPN client.

[Lonkle]

@girish I think you’re right about using the app table. I’ll try to RE how you use it to populate the apps variable.

And no worries not following along with this thread. It’s been really difficult for me to get this working so I used this as kind of note-taking. Now that I’m nearly finished, people won’t get as bugged by my posting here every time I discover something new about the way box works.

[Lonkle]

Oh wait, the container object, would contain the IP and the container ID. I could intercept that right after it’s created. 🧐

[Lonkle]

@girish said in VPN tunnel for apps:

getAppByManifestId

I guess the proper function name then would be getAppsByManifestId - the point is to get the possibly multiple VPN Clients installed to populated the drop down box in other app’s configs asking which VPN Client app they would like to share a network with. So this is a needed function and I can parse through the app DB to collect the data.

I found your function to getIDByIPAddressand I’m basically using it as a reference to write the opposite function now getIPAddressById. Would you like me to make this a function or would you like me to just put the code in the NginxAppConfig function the singular time I need to use it? It’s needed to make all of this work.

I need you to know of the singular limitation of the VPN Client app though:

• Multiple apps can connect to a singular VPN Client app unless two apps exposed httpPorts are the same. So you couldn’t connect two of the same app or different apps that use the same web port. I cannot find a way around this except to install a second VPN Client. Which I don’t think is a bad solution given how small my app is. But that will have to be enforced in the drop down box via a new function. I don’t plan on touching dashboard code tho so I’ll leave that up to you. But when you get to that step, tell me and I’ll write you a function to only show you the VPN clients whose connected app.manifest.httpPorts don’t conflict with the app being configured in the dashboard to protect users from port conflicts.