Lantern DSSE is an open-source (Apache-2.0), self-hosted zero-trust network: ZTNA and a secure web gateway that you run on your own servers. This post installs the 0.4.2 release on a single Linux server and connects a Windows PC to it.
Lantern DSSE is an experimental release. The single-server layout below is for trying it out: if that server stops, everything stops. Do not use it in production.
What Lantern DSSE does
It grew out of work on ransomware defense: if a device is compromised, which internal systems can it reach, and what can it send out?
- Internal traffic. Observe which internal connections devices make, then limit each device to the applications it needs. Applications are reached through connectors that dial out to the Edge.
- Out-of-band authentication with your IdP. For the internal destinations you mark, a connection such as SSH, RDP or SMB is held while the user signs in to your identity provider (OIDC) in a browser, and continues only after that.
- Outbound traffic. Sites are allowed or denied by rule, and every decision is logged.
- TLS inspection. For the traffic you choose, the Edge decrypts TLS with your organization's own certificate authority.
The same applies to AI agents. Prompts and guardrails shape what an agent tries to do, not what it can reach. We think the most dependable control is to decide access to each resource from an authenticated identity, outside the agent, and to log every decision.
What we are building
One server runs everything as containers.
What you need
- One Linux x86-64 server with Docker Engine and Compose v2. I used a 4 vCPU, 16 GiB instance in AWS Tokyo with Ubuntu 24.04. You do not need Go or the source.
- Port 443 open. Devices and administrators both come in through it.
- The deployment's names resolving to the server, through DNS or hosts files. I used hosts files.
- A Windows PC and the signed MSI from the release (
DsseAgent-0.4.2-windows-x64.msi).
I did not limit port 443 by source address; the Console is protected by sign-in. Only SSH was limited to my own address.
1. Get the installer
Download the installer and the release manifest. The installer reads which container images to run from the manifest.
R=https://github.com/lantern-networks/dsse-core/releases/download/v0.4.2-experimental curl -fLO $R/dsse-install-0.4.2-linux-amd64 curl -fLO $R/release-manifest.json curl -fLO $R/SHA256SUMS sha256sum -c --ignore-missing SHA256SUMS sudo install -m 0755 dsse-install-0.4.2-linux-amd64 /usr/local/bin/dsse-install sudo install -d -o "$USER" -g "$USER" -m 0755 /opt/dsse 2. Register the names
Choose a name for the deployment (one you control; example.test is a placeholder) and use the address the server actually has. The installer prints the line to add to the hosts file.
A='-up -deployment example.test -address 10.20.1.10 -admin-email admin@example.test -dir /opt/dsse/region-a -release-manifest release-manifest.json' dsse-install $A -print-names | sudo tee -a /etc/hosts It prints one line: the address followed by eight names. On the administrator's PC and on the Windows PC, point the same names at the server's public address.
3. Install with one command
dsse-install $A The installer runs six steps in order. For me it took about four minutes, including pulling the images.
| Step | What it does |
|---|---|
| 1 | Creates the deployment's certificate authorities, certificates and configuration |
| 2 | Starts the containers |
| 3 | Creates the first administrator |
| 4 | Restarts the control plane and the Edge |
| 5 | Turns on the authentication features |
| 6 | Checks the whole deployment |
The last step passes when nothing fails. I got 50 checks passed out of 51, with one not applicable because no customer organization existed yet. If a step fails, fix the cause and run the same command again: it skips the finished steps and continues.
Three of the files it creates in /opt/dsse/region-a are worth knowing:
| File | Contents |
|---|---|
admin-credentials.txt | The first administrator's password, the key for an authenticator app, and recovery codes. Readable only by its owner, and never printed to the screen |
deployment-anchor.pem | The certificate of this deployment's root authority. It holds no private key, so you can hand it out. Used on the administrator's PC in step 4 |
authority/ | The private keys of the authorities. Guard this above everything else |
admin-credentials.txt has this shape, with some notes around it:
password <the password> second factor <the TOTP secret> recovery codes <recovery codes, separated by spaces> | Line | Use |
|---|---|
password | The password for signing in to the Console |
second factor | The key you register in an authenticator app (in step 4). At sign-in you enter the six digits the app shows |
recovery codes | Entered instead of the six digits when the app is unavailable. Each code works once |
A layout with several servers is installed with the same -up and a plan file; see the deployment guide.
4. Create an organization in the Console
Copy /opt/dsse/region-a/deployment-anchor.pem from the server to the administrator's PC and trust it. On Windows, in an elevated PowerShell:
Get-FileHash .\deployment-anchor.pem # must equal sha256sum on the server Import-Certificate -FilePath .\deployment-anchor.pem -CertStoreLocation Cert:\LocalMachine\Root Before signing in, register the second factor value in an authenticator app on your phone (Google Authenticator, Microsoft Authenticator and so on):
- Open the screen that adds an account by typing a key (in Google Authenticator, "Enter a setup key").
- Give the account a name you will recognize, for example the address you passed as
-admin-email. - Enter the
second factorvalue as the key (32 capital letters and digits), with the key type "time based".
When the app shows six digits that change every 30 seconds, it is registered. Sign-in fails if the phone's clock is far off.
Open https://console.region-a.<your deployment>/console.html in a browser and sign in with the -admin-email address, the password from admin-credentials.txt, and the six digits from the app.
The tenant_default organization that already exists belongs to the operator. Create a customer organization (a tenant) for your devices:
- Under Tenants, press + Add tenant and give it a display name. Leave Who runs it at its default, We run it for them.
- Press Manage on that organization in the list. Inside it, under Certificates & PKI → Certificates, press Let this deployment issue them for device identity and Let this deployment make one for traffic inspection. In the dialog that appears first, press Ask for 20 minutes.
- Under Device configuration, press Make the configuration, then Download everything for one device to get the set for Windows.
The set contains the configuration (install_profile.json), the key that verifies its signature (profile_signing_key.txt) and a one-time enrolment token (enrolment_token.txt). It does not contain the MSI: download DsseAgent-0.4.2-windows-x64.msi from the release and put it in the same folder as DsseAgent.msi.
5. Install on Windows
Check the signatures of the MSI and the configuration first. dsse-profileverify.exe checks the configuration; build it on Windows from a clone of the repository with go build -o dsse-profileverify.exe ./cmd/dsse-profileverify.
Get-AuthenticodeSignature .\DsseAgent.msi | Format-List Status,SignerCertificate .\dsse-profileverify.exe -profile install_profile.json -pin profile_signing_key.txt The MSI must be Valid with the signer LANTERN NETWORKS, INC., and the configuration must report "signed by the pinned key" (it then prints the configuration itself, which holds certificates and public keys but no secret). In real use, the key reaches the device by a different route from the configuration.
Install from an elevated PowerShell:
$msi = (Resolve-Path .\DsseAgent.msi).Path $config = (Resolve-Path .\install_profile.json).Path $token = (Resolve-Path .\enrolment_token.txt).Path $pin = (Resolve-Path .\profile_signing_key.txt).Path $log = Join-Path $PWD 'install.log' $p = Start-Process msiexec.exe -Wait -PassThru -ArgumentList "/i `"$msi`" /qn /l*v `"$log`" CONFIG=`"$config`" TOKEN=`"$token`" PIN=`"$pin`"" $p.ExitCode When it prints 0, start the agent. On its first start the device enrols in the organization.
Get-Service DsseSteer,DsseWfp Start-Service DsseSteer Get-CimInstance Win32_Service -Filter "Name='DsseSteer'" | Select-Object State,StartMode It takes about half a minute before traffic goes through DSSE. It is ready when C:\Program Files\DSSE\dsse-steer.log shows steer_capture backend=wfp armed=true. The device also appears under Devices in the Console.
6. Check allow and deny
A new organization's Internet Access starts with one rule that allows and inspects everything. The idea is to make the traffic visible first and narrow it from there.
Add a rule that denies one site:
- Under Groups & Services, press + Add server and create the destination
example.org. - Under Internet Access, create a rule with
example.orgas the destination and Deny as the access. Give it a priority lower than the first rule's 100, for example 20 (the lower number wins).
In the PC's browser, an allowed site opens without a certificate warning, and the denied site shows a block page.
Logs & Audit records both the allowed and the denied requests, with the rule and the reason.
If you try it
If you try this in a lab, please tell us in an issue which version and operating system you used, what you tried, and where a step or the behaviour differed from what you expected. Do not include tokens, private keys or personal information. A star on GitHub is appreciated.
