Before a Juju charm becomes your VPN: identity, contract, ports

Someone finds a charm that claims to run a VPN, deploys it, exposes the application and waits for a client to connect. The deployment succeeds, the port opens, and the tunnel still does not work, because three unrelated promises were collapsed into one. A charm is a deployment implementation with a specific contract. Walk those promises separately and the gaps show up before the rollout rather than after it.

Step one: pin the artifact you are reading about

Read the candidate's own metadata for the publisher, source repository, channel, revision, base and architecture. Then establish who maintains the VPN software inside the workload and who ships its security updates, because those are often two different parties. An unmaintained upstream inside a well-maintained charm is a support problem waiting for a bad week.

juju info CHARM_NAME reports channels, bases and architectures in Juju 3.6, and the documentation notes that a specific revision query cannot be combined with those filters. Query the revision on its own rather than building a combination the command rejects. Read the base and architecture too, since a channel can cover more than one.

Record the exact combination you reviewed next to the deployment. A refresh that moves the channel is then an intentional change with a before and after, not a surprise on a Monday.

Step two: read the configuration as a contract

Determine the role the charm plays: terminating remote access, joining an existing VPN, or something else entirely. Then find how it documents client enrolment, trusted issuers, credential rotation and revocation. Those four decide whether you can operate the thing, and a generated client file is sensitive output rather than a file for a ticket.

Follow the interfaces and actions the charm actually exposes. Do not assume an enrolment action exists because a different charm for the same software has one.

Ask what reconciliation does to hand edits. If the charm overwrites a configuration file on the next update, a manual fix has a shelf life measured in one upgrade. Ask the maintainers where that behaviour is documented, and treat silence as unknown.

Step three: separate the listener from the forwarded path

The outer listener is the socket that accepts the tunnel. Forwarding is what happens to traffic inside it, and a return path is what lets replies come back. A charm can deliver the first and leave the other two to the infrastructure team.

Egress is a third piece. If tunnel clients should reach the internet through this host, an addressing or translation arrangement has to exist, and it is not created by opening a port. Assign an owner to that piece before the first client arrives.

Step four: exposure is a firewall action

In Juju 3.6, exposing an application adjusts cloud firewall rules, and by default it permits traffic from any source to the ports the workload has opened. The command's endpoint and CIDR selectors exist precisely so that default can be narrowed.

Exposure does not create VPN users, validate their credentials, or install forwarding policy. It also does not prove that the workload is listening on the address and transport you expect, which is why the test after exposure matters more than the success message. Check the listening socket on the unit as well as the cloud rule.

Step five: accept with four tests

After an approved deployment, enrol a new client and confirm the intended private service. Then revoke that identity and confirm the access actually ends rather than only the next login being refused. Repeat the check from a network you do not control, and then from inside the office, because those two paths answer different questions.

Finish with an upgrade and a reconnect, because that is where reconciliation, credential handling and service restarts interact. If the documentation cannot explain who owns one of those operations, write that down as an adoption gap instead of filling it with an unmaintained recipe behind the same charm name. A gap written down is a decision; a gap filled quietly is a future outage. Hand it to whoever owns the service decision, with the date you found it.