Reaching the console from elsewhere

So opening it from another machine means choosing a route first. Neither route needs port 8092 opened in your firewall.

⭐ If you are unsure, take the tunnel. It makes you prove you can get into the host every single time, so getting it wrong means "cannot connect", not "somebody else connected".

2. Reverse proxy: give it a URL

For several people using it day to day, or to read it on a phone, put the console behind your own Apache or nginx and let that handle HTTPS and access control.

On the console side there is one thing to set — and possibly nothing at all:

[web]
listen_addr = 127.0.0.1:8092   ; stay local, so the proxy is the only way in
base_path = /agent             ; only when mounting under a sub-path

On its own subdomain (https://guard.example.com/), leave base_path out. Set it only when sharing a domain with something else, under https://example.com/agent.

⚠️ Restart the service afterwards. The configuration file is read once, at start-up.

Apache

<VirtualHost *:443>
    ServerName guard.example.com
    # certificate directives omitted

    # Worth keeping — see "How the source address is decided" below
    RequestHeader unset X-Forwarded-For

    ProxyPreserveHost On
    ProxyPass        / http://127.0.0.1:8092/
    ProxyPassReverse / http://127.0.0.1:8092/
</VirtualHost>

Under a sub-path (with base_path = /agent in the file):

ProxyPass        /agent http://127.0.0.1:8092/agent
ProxyPassReverse /agent http://127.0.0.1:8092/agent

nginx

server {
    listen 443 ssl;
    server_name guard.example.com;
    # certificate directives omitted

    location / {
        proxy_pass http://127.0.0.1:8092;
        proxy_set_header Host              $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        # ⛔ $remote_addr, NOT $proxy_add_x_forwarded_for
        proxy_set_header X-Forwarded-For   $remote_addr;
    }
}

How the source address is decided (and why the proxy belongs on the same host)

The console has to be able to say who signed in, and its sign-in lockout counts per source address: ten failures from one address within fifteen minutes and it locks. So where a request came from cannot be something the caller gets to declare.

It decides in two steps:

• The connection itself comes from this same host — the proxy sits on the same machine as the console, pointing at 127.0.0.1:8092 as in both configurations above ⇒ X-Forwarded-For is believed, and only its last element. Apache and nginx both append the peer they actually saw, so the last element is the real one; anything an outsider put in stays in front of it and is ignored.
• The connection comes from another machine ⇒ X-Forwarded-For is not read at all and the connecting address is used.

One line in each configuration above is worth keeping: it leaves the header clean and makes the result predictable when more than one proxy is involved.

• Apache: RequestHeader unset X-Forwarded-For. Clear what came from outside; mod_proxy then fills in the peer it actually saw.
• nginx: proxy_set_header X-Forwarded-For $remote_addr;. ⚠️ The $proxy_add_x_forwarded_for copied all over the internet means "keep what arrived and append the real source" — still correct here, but it leaves a stranger's text in the header for no reason.

Three more

• HTTPS is not optional. Sign-in is a username and a password; in the clear it is a gift to everyone along the way.
• The cookie's Secure flag follows X-Forwarded-Proto on its own, so with that header set there is nothing to do. To force it, set [web] cookie_secure = true. ⚠️ Do not set true before HTTPS is actually in place — you will not be able to sign in, because the browser will never send the cookie back.
• Add a second layer at the proxy. Allow known source addresses only, or add Basic authentication, or put it behind a VPN. The console's own password should be the last line, not the only one.

Host not linked to an account yet?

Hosts with no browser can be paired from the command line. The steps are on the Get Started page.

Pair from the command line →