In this example, we will:
• MeshCentral on non-standard ports, but alias HTTPS to port 443.
• NGINX will be using standard ports 80 and 443.
• We will have NGINX perform all TLS authentication & encryption.
• MeshCentral will read the NGINX web certificate so agents will perform correct server
authentication.
• NGINX will be setup with long timeouts, because agents have long standard web socket
connections.
Let’s get started by configuring MeshCentral with the following values in config.json:
{
"settings": {
"Cert": "myservername.domain.com"
"Port": 4430,
"AliasPort": 443,
"RedirPort": 800,
"AgentPong": 300,
"TlsOffload": "127.0.0.1"
},
"domains": {
"": {
"certUrl": "https://127.0.0.1:443/"
}
}
}
With this configuration, MeshCentral will be using port 4430 instead of port 443, but because
“TlsOffload” is set, TLS will not be performed on port 4430. The server name is set to
“myservername.domain.com”, so that is the name that MeshCentral will give to agents to connect
to. Also, the alias port is set to 443. So agents will be told to connect to
“myservername.domain.com:443”.
The “AgentPong” line instructs the server to send data to the agent each 300 seconds and the
agent by default will send data to the server every 120 seconds. As long as NGINX timeouts are
longer than this, connections should remain open.
When agents connect, they will see the NGINX TLS certificate on port 443. MeshCentral needs to
know about the NGINX certificate so that it can tell the agents this is the correct certificate they
should expect to see. So, “certUrl” is used to tell MeshCentral where to get the certificates that
agents will see when connecting.
When NGINX forwards connections to MeshCentral, extra X-Forwarded headers will be added to
each request. MeshCentral needs to know if these headers can be trusted or not. By setting
“TlsOffload” to “127.0.0.1”, MeshCentral is told to trust these headers when requests come from
“127.0.0.1”.
In this example, make sure to change “127.0.0.1” to the IP address of NGINX and “Cert” to the
external DNS name of the NGINX server.
Next, we need to configure and launch NGINX. Here is an ngnix.conf to get started:
worker_processes 1;
events {
worker_connections 1024;
}
http {
# HTTP server. In this example, we use a wildcard as server name.
server {
listen 80;
server_name _;
location / {
proxy_pass http://127.0.0.1:800/;
proxy_http_version 1.1;
# Inform MeshCentral about the real host, port and protocol
proxy_set_header X-Forwarded-Host $host:$server_port;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
# HTTPS server. In this example, we use a wildcard as server name.
server {
listen 443 ssl;
server_name _;
# MeshCentral uses long standing web socket connections, set longer timeouts.
proxy_send_timeout 330s;
proxy_read_timeout 330s;
# We can use the MeshCentral generated certificate & key
ssl_certificate webserver-cert-public.crt;
ssl_certificate_key webserver-cert-private.key;
ssl_session_cache shared:WEBSSL:10m;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
location / {
proxy_pass http://127.0.0.1:4430/;
proxy_http_version 1.1;
# Allows websockets over HTTPS.
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
# Inform MeshCentral about the real host, port and protocol
proxy_set_header X-Forwarded-Host $host:$server_port;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
}
As indicated in the comments of this NGINX configuration file, we set timeouts to be really long.
We forward HTTP port 80 and HTTPS port 443 to the corresponding ports on MeshCentral. In
this example, we happen to use the web certificates that where generated by MeshCentral, but
any certificate is ok. We also add extra “X-Forward” headers, this tells MeshCentral information
that would normally be hidden by NGINX, like the client’s IP address and more.