Is there a way to separate the admin/management/control web interface from the agent access and download for the clients?
This way we could make the agent and download visible to the internet while keeping the admin/management/control interface more restricted possibly protect it by VPN or more restrictive firewall rules.
Yes, use the following settings in the settings section of config.json:
"AgentPort": 443,
"AgentAliasPort": 889,
"AgentAliasDNS": "agents.mesh.meshcentral.com",
"AgentPortTls": true,
You probably just need "AgentPort", the rest is for more complex server configurations. If you set "agentport" to 443, make sure to change "port" to a different number. "AgentPort" will open a port that only the agents can connect to.
Hope that helps,
Ylian
I thought of an approach tonight that might work a little bit better than the current setup. What if it was set up with public and private ports instead of interface and alias? Everything currently exempted from UserAllowedIP would run on the public port while the interface would run on private. That way, you could further lock things down by firewalling off access to the actual interface while still allowing agents to communicate, invite links to be viewed, and guest access to desktops to function.
Yes, you can setup MeshCentral any way you like with a public and private port, this is exactly why "AgentPort" exists. "Port" will accept users and agents while "AgentPort" will only accept agents.
"Port": 443,
"AgentPort": 444,
Once this is understood, you can setup your reverse proxy and firewalls accordingly.
Right but unless I'm misunderstanding something, you can't restrict access to the "Port" via firewall without also breaking agent invites and, presumably since the feature didn't exist when I last tested this, guest desktop sharing as those both seem to use the Port value rather than AgentPort.
I see. We would need a list of features available on "GuestPort"? This said, you can block login on the "port" using "userAllowedIp". If there are any features that should be allowed even when "userAllowedIp" would block them, let me know.
That's what I'm currently doing (userAllowedIp) but I was suggesting this as an alternative to using that so access could be controlled at the firewall level instead. I could try to put together a list but as it stands, my initial idea is to have the anything restricted by userAllowedIp on the private side and anything exempted from it on the public side. Obviously, it's a little more complicated than that when you factor in AMT and the fact that things like agent invites and guest desktop access would need to run on a different port than the interface but I think as a general guideline, it gets the point across.