Ylianst / MeshCentral

A complete web-based remote monitoring and management web site. Once setup you can install agents and perform remote desktop session to devices on the local network or over the Internet.
https://meshcentral.com
Apache License 2.0
3.67k stars 510 forks source link

[Feature Request] Enable multiple certURLs #3798

Open PrplHaz4 opened 2 years ago

PrplHaz4 commented 2 years ago

Enable multiple certURLs to allow automatic configuration for split-horizon dns or multiple tls proxies in front of meshcentral.

This would resolve numerous outstanding issues related to CloudFlare connectivity. Most recently (?), https://github.com/Ylianst/MeshCentral/issues/3580

Simple use case:

This would allow internet-facing clients to connect and be aware of only the CF proxy, while internal clients can connect directly to your internal reverse proxy.

There may be a more elegant solution to this problem, but it seems common enough, and IMO allowing meshcentral to hide behind CF is a great way to mitigate the risk of exposing a service like this to the public internet.

Keep up the great work - you guys really deliver a truly remarkable OSS product!

Ylianst commented 2 years ago

I do agree that having MeshCentral behind Cloud Flare is a good security measure. If I understand correct, your asking that MeshCentral be allowed to be behind multiple TLS certificates. So, you could have MeshCentral behind a reverse proxy using a LE cert? and a different reverse proxy using a Amazon AWS cert?

The purpose of "CertURL" is to tell MeshCentral what TLS certificate it's going to be behind. Having multiple "CerlURL" would allows for multiple certs. Is that correct?

PrplHaz4 commented 2 years ago

I do agree that having MeshCentral behind Cloud Flare is a good security measure. If I understand correct, your asking that MeshCentral be allowed to be behind multiple TLS certificates. So, you could have MeshCentral behind a reverse proxy using a LE cert? and a different reverse proxy using a Amazon AWS cert?

The purpose of "CertURL" is to tell MeshCentral what TLS certificate it's going to be behind. Having multiple "CerlURL" would allows for multiple certs. Is that correct?

Correct on all fronts (from my point of view at least)!

PrplHaz4 commented 2 years ago

I do agree that having MeshCentral behind Cloud Flare is a good security measure. If I understand correct, your asking that MeshCentral be allowed to be behind multiple TLS certificates. So, you could have MeshCentral behind a reverse proxy using a LE cert? and a different reverse proxy using a Amazon AWS cert?

The purpose of "CertURL" is to tell MeshCentral what TLS certificate it's going to be behind. Having multiple "CerlURL" would allows for multiple certs. Is that correct?

Quick diagram of this proposal: image

aj-bayanat commented 1 year ago

Hi, I have the same problem that this feature would solve. I am running MC behind Caddy with a cloudflare cert and a internal DNS that points to the Caddy server. I do NOT want to port forward on my work network, so instead I opted for using cloudflare tunnels. (Now thats its free for everyone, yay! ). I get the same mismatch of SHA certs for clients trying to connect from outside my network. One way I tried to solve this was to remove my internal dns and only use cloudflare however this results in the error Failed to load certs from mesh.mydomain.com. I suspect this is because my internal dns (windows server) has to route my domain by using a cname. This is because I have many other internal web applications so I need to route mydomain.com through my internal DNS. Usually to bypass this for some webapps the internal DNS is set to point to CNAME, so for example mesh.mydomain.com.cdn.cloudflare.net, this usually works but for some reason MC is not able to grab the cert when I do this. Any advice would be greatly appreciated.

twistedsanity commented 1 month ago

I'm also having this issue split cloudflare and local. Any progress would be amazing.

si458 commented 1 month ago

@twistedsanity can u explain a little more for me plz about ur setup etc?

I'm trying to figure out why u would have split dns? Surely ur meshcentral dns is just ur reverse proxy ip on the Internet? And internal devices do a hairpin nat (miktorik terms) so it can connect to the reverse proxy internally even tho u use its external ip?

Renaud11232 commented 1 month ago

Hello,

Adding my 2 cents here :

When using Cloudflare, your DNS records, even tho they can, most likely don't point to your actual IP but rather to CF's reverse proxies, which then forwards requests to your actual server IP.

Without split horizon DNS, accessing your hosted services (such as MeshCentral) from your local network would cause un-needed traffic from your public IP to Cloudflare's servers and back, just to access resources that actually are on the same local network.

PrplHaz4 commented 1 month ago

Hello,

Adding my 2 cents here :

When using Cloudflare, your DNS records, even tho they can, most likely don't point to your actual IP but rather to CF's reverse proxies, which then forwards requests to your actual server IP.

Without split horizon DNS, accessing your hosted services (such as MeshCentral) from your local network would cause un-needed traffic from your public IP to Cloudflare's servers and back, just to access resources that actually are on the same local network.

This is exactly the situation that prompted me to open this request.

si458 commented 1 month ago

@PrplHaz4 so does ur internal dns resolve the IP of ur meshcentral to the the reverse proxy internally, and then everyone outside would get the meshcentral ip of cloudflare which in turn tunnels it to reverse proxy?

Just trying to get an idea, so I can setup environment and get testing!

twistedsanity commented 1 month ago

@Renaud11232 explained the issue perfectly. Also the diagram @PrplHaz4 provided is almost identical to my setup.

I run meshcentral behind an reverse proxy (HAProxy) which services clients locally. This same HAProxy server also sits behind cloudflare, which I use for security, protection and a few other features. I really do not want to forward internal clients out via the internet 'hairpinning', therefore split DNS allows me to keep all internal traffic internal. Also due to the fantastic and free protections cloudflare offers is its not something I would wish to disable.

The actual issue is that the two different routes use two different certificates, even though they are both perfectly valid. My internal clients get presented and try to use a lets encrypt cert automatically managed by acme certificates (let's encrypt) for my external url (wildcard). The external route via cloudflare uses its own automatically managed (by CF) let's encrypt cert which is also for my same external url (wildcard). With cloudflare unless you pay silly money for a large enterprise grade account and have the knowledge to manage all cert changes programmatically this is an unchangeable scenario unfortunately.

@si458 I would be more than happy to jump on a session and share some config I wouldn't share publicly if it helps at all.

si458 commented 1 month ago

@twistedsanity right thank u for that! It does explain it and I understand now! So in theory as the issue says u need certurl to be able to have multiple set so it can then verify with 1 cert or another!

I will have a look at source code over the weekend!

twistedsanity commented 3 weeks ago

Just wondered if anyone had a look at the possibility/feasibility of being able to add multiple certs? I have managed to set up a sort of hairpin setup to enable all internal clients to go out and back in again. This is not a long time solution but a ok'ish temporary workaround.

PrplHaz4 commented 3 weeks ago

@PrplHaz4 so does ur internal dns resolve the IP of ur meshcentral to the the reverse proxy internally, and then everyone outside would get the meshcentral ip of cloudflare which in turn tunnels it to reverse proxy?

Just trying to get an idea, so I can setup environment and get testing!

Sorry for not responding! Yes, that is how it works - internal network clients use internal DNS to resolve and hit the RP IP directly, external clients use unknown DNS server to resolve the URL to cloudflare IPs (which then point to RP IP).