Meshcentral: Cannot add agents to subdomains when in LAN/Multicast mode

Created on 2 Oct 2019  ·  10Comments  ·  Source: Ylianst/MeshCentral

Environment

OS: Ubuntu 18 LTS for both agent and server
Version: v0.4.1-n
Config.json

{
  "settings": {
    "Port": 443,
    "RedirPort": 80,
    "LANonly": true,
  },
  "domains": {
    "": {
      "Title": "MyServer",
      "Title2": "Servername",
      "UserQuota": 1048576,
      "MeshQuota": 248576,
      "NewAccounts" : false,
      "Footer": "<a href='https://twitter.com/mytwitter'>Twitter</a>"
    },
    "customer1": {
      "Title": "Title1",
      "Title2": "Title2!",
      "UserQuota": 1048576,
      "MeshQuota": 248576,
      "NewAccounts" : false,
      "Footer": "<a href='https://twitter.com/mytwitter'>Twitter</a>"
    }
  }
}
  • I've renamed my subdomains in the examples here from reality to obfuscate customer information (but there are no special characters, just numbers and letters)
  • Agent and Server are both on the same ESXi host, using the same vSwitch.
  • IPv6 is enabled on the vSwitch, and the agent is choosing this IP in the successful connection
  • It's the same server and agent being used in all tests demonstrated below

Observations

  • In the only successful connection, we see IPv6 address (but the IPv4 works)
# nc -zvw3 10.60.30.21 443
Connection to 10.60.30.21 443 port [tcp/https] succeeded!
# nc -zvw3 10.60.30.21 80
Connection to 10.60.30.21 80 port [tcp/http] succeeded!
  • In the Linux agent, the line endings are set to windows. Tried to remove incorrect line endings (^M), as observed below, there is no change in behavior

Original

MeshName=Endpoints^M
MeshType=2^M
MeshID=0xCC50A496F45250615DA2D0D2915937FD610E24F5181F34F179FAD0B5DA71E987746A8CF871AA743913969A08EAEB40AB^M
ServerID=B95AA3BB1C5EF73C4877E9C4D210994BB0E53ED5DFB7D5A6DEB8ABA51429E11309956EFCDB8207C37E59E32FF479B277^M
MeshServer=local^M
ignoreProxyFile=1^M
StartupType=1

Corrected

MeshName=Endpoints
MeshType=2
MeshID=0xCC50A496F45250615DA2D0D2915937FD610E24F5181F34F179FAD0B5DA71E987746A8CF871AA743913969A08EAEB40AB
ServerID=B95AA3BB1C5EF73C4877E9C4D210994BB0E53ED5DFB7D5A6DEB8ABA51429E11309956EFCDB8207C37E59E32FF479B277
MeshServer=local
ignoreProxyFile=1
StartupType=1

Replication Steps

1) Navigate to the main domain ("") (https://10.60.30.21/)
2) Login as administrator (named 'root')
3) Create a group
4) Create an invite link, and use generated script to install the agent
5) Observe that the agent connects very quickly (I want to say immediately)
6) Uninstall the agent using the steps from the invite link
7) Navigate to the subdomain (https://10.60.30.21/customer1)
8) Login as administrator (named 'root')
9) Create a group
10) Create an invite link, and use generated script to install the agent
11) Observe that the agent does not connect
12) Uninstall the agent using the steps from the invite link
13) Navigate to the main domain ("") (https://10.60.30.21/)
14) Login as administrator (named 'root')
15) Click on the group
16) Create an invite link, and use generated script to install the agent
17) Observe that the agent connects very quickly again as it did in step 5 (I want to say immediately)

Compare and contrast

Without subdomain (working)

  • No meshagent.log in the /usr/local/mesh directory
  • meshagent.msh
MeshName=testgroup
MeshType=2
MeshID=0x05201124AF76764D3BBAC7EA07F8B74AC02A9B40619EFEF042537A577476EB7FC9BAD7E2572F061B31080C8E10542E8C
ServerID=B95AA3BB1C5EF73C4877E9C4D210994BB0E53ED5DFB7D5A6DEB8ABA51429E11309956EFCDB8207C37E59E32FF479B277
MeshServer=local
ignoreProxyFile=1
StartupType=1
  • Add controlChannelDebug=1 to /usr/local/mesh/meshagent.msh and restart service
[2019-10-02 03:17:39 PM] Connecting to: wss://[fe80::20c:29ff:fedd:a40c%2]:443/agent.ashx
[2019-10-02 03:17:39 PM] Control Channel Connection Established...
[2019-10-02 03:17:39 PM] TLS Server Cert matches Mesh Server Cert...
[2019-10-02 03:17:39 PM] Sending Authentication Data...
[2019-10-02 03:17:39 PM] ProcessCommand(1)...
[2019-10-02 03:17:39 PM] Processing Authentication Request...
[2019-10-02 03:17:39 PM] ProcessCommand(4)...
[2019-10-02 03:17:39 PM] Authentication Complete...
[2019-10-02 03:17:39 PM] ProcessCommand(12)...
[2019-10-02 03:17:39 PM] BinaryCommand(12, 0)...
[2019-10-02 03:17:39 PM] ProcessCommand(11)...
[2019-10-02 03:17:39 PM] BinaryCommand(11, 0)...
[2019-10-02 03:17:39 PM] ProcessCommand(16)...
[2019-10-02 03:17:39 PM] BinaryCommand(16, 0)...
[2019-10-02 03:17:39 PM] ProcessCommand(31522)...
  • Service Status
● meshagent.service - MeshCentral Agent
   Loaded: loaded (/lib/systemd/system/meshagent.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2019-10-02 15:17:37 UTC; 1min 7s ago
 Main PID: 21593 (meshagent)
    Tasks: 4 (limit: 1110)
   CGroup: /system.slice/meshagent.service
           ├─21593 /usr/local/mesh/meshagent
           ├─21632 sh
           └─21662 sh

Oct 02 15:17:37 ubuntu18 systemd[1]: Started MeshCentral Agent.

With subdomain (not working)

  • No meshagent.log in the /usr/local/mesh directory
  • meshagent.msh (All but the last line have incorrect line endings)
MeshName=Endpoints^M
MeshType=2^M
MeshID=0xCC50A496F45250615DA2D0D2915937FD610E24F5181F34F179FAD0B5DA71E987746A8CF871AA743913969A08EAEB40AB^M
ServerID=B95AA3BB1C5EF73C4877E9C4D210994BB0E53ED5DFB7D5A6DEB8ABA51429E11309956EFCDB8207C37E59E32FF479B277^M
MeshServer=local^M
ignoreProxyFile=1^M
StartupType=1
  • Add controlChannelDebug=1 to /usr/local/mesh/meshagent.msh and restart service
  • meshagent.log
[2019-10-02 03:28:41 PM] Connecting to: wss://10.60.30.21:443/agent.ashx
[2019-10-02 03:28:41 PM] Control Channel Connection Established...
[2019-10-02 03:28:41 PM] TLS Server Cert matches Mesh Server Cert...
[2019-10-02 03:28:41 PM] Sending Authentication Data...
[2019-10-02 03:28:41 PM] ProcessCommand(1)...
[2019-10-02 03:28:41 PM] Processing Authentication Request...
  • Service Status
● meshagent.service - MeshCentral Agent
   Loaded: loaded (/lib/systemd/system/meshagent.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2019-10-02 15:28:39 UTC; 47s ago
 Main PID: 22101 (meshagent)
    Tasks: 2 (limit: 1110)
   CGroup: /system.slice/meshagent.service
           └─22101 /usr/local/mesh/meshagent

Oct 02 15:28:39 ubuntu18 systemd[1]: Started MeshCentral Agent.
Fixed - Confirm & Close bug

Most helpful comment

The URL should be:

MeshServer=wss://10.60.30.21:443/customer1/agent.ashx

It's a good workaround, but in multicast mode the server is not expected to have a static IP address and so, you would need to change all the agents when the server gets a different IP. I may work on fixing this since I want users to just have MeshCentral work without having to look at documentation too much.

All 10 comments

Oh... I don't think I have ever tested a multicast discovered server with multi-domain. I would need to add support for this or explicitly deny this case. The multicast system is intended for very small deployments in a LAN, I did not expect this usage.

My guess is that the agent will connect to the default domain instead of the sub-domain and will not find it's device group and just hold there. I would need to fix a bunch of things to make this work.

Feedback appreciated on this... should I deny this or enable it?

For me, in production, I will use this in WAN mode, but, for testing (and demos) I use LAN mode. If it won't break anything to specify WAN mode when actually using in LAN mode, that works for me (and what I was doing previously, but I'm trying to cut down on filing bugs for user errors :P )

As a workaround if I can specify MeshServer=wss://10.60.30.21/customer1:443/agent.ashx in /usr/local/mesh/meshagent.msh (that doesn't work for me, but I didn't' try too hard) that is 100% acceptable as well if it's documented.

The URL should be:

MeshServer=wss://10.60.30.21:443/customer1/agent.ashx

It's a good workaround, but in multicast mode the server is not expected to have a static IP address and so, you would need to change all the agents when the server gets a different IP. I may work on fixing this since I want users to just have MeshCentral work without having to look at documentation too much.

Your solution 100% works for me, thank you! Happy to close with this workaround.

Rather than fixing, you may wish to consider that during server startup, you error when there domains are configured and LAN mode is also selected (Unsupported configuration! LAN mode does not support subdomains! Please see manual X for more information) You may want to consider echoing on the screen as well, so the user doesn't have to check the service status? (not sure what that might look like in Windows though)

For real enterprise installations, multi-customer LAN mode may not be really be something they care about, but for home or small office installations, it might be really handy to be able to use LAN mode and have the different family members, friends, or teams use a different customer portal.

Published MeshCentral v0.4.1-r with a fix for this. Devices that find a server using multicast should show up even if in a sub-domain. Let me know if it works for you.

I will close this once since I am pretty sure it's fixed. Please re-open if there are any issues found.

I am also confident it's fixed. :) Thanks @Ylianst , sorry, I haven't had time to test back in my lab at work, but will do so in the near future and update this for completeness.

Sorry for the massive delay, confirmed this works as expected in v0.4.2-u

Was this page helpful?
0 / 5 - 0 ratings

Related issues

hellofaduck picture hellofaduck  ·  3Comments

Julien-asv picture Julien-asv  ·  3Comments

coolwormgit picture coolwormgit  ·  3Comments

guerby picture guerby  ·  3Comments

robclay picture robclay  ·  3Comments