Think Renaming the Pritunl Server Changes Its Endpoint?

Renaming a Pritunl server changes a label in the console. It does not change the address that client profiles dial, and it does not create a DNS record. The value that matters is the host's Public Address, and it accepts a name as readily as an address.

The name clients dial lives in one host field

Pritunl exposes the endpoint through the host's Public Address setting, which takes either a public IP address or a DNS name. Put vpn.example.net there and the generated profiles and authenticated sync hand that name to clients. The record must already exist and resolve to the listener that accepts VPN transport; the field advertises a destination, it does not publish one. A server object's display name is administrative metadata and never reaches the client's connection attempt.

So the first move is not renaming anything. Open the host settings, change Public Address, and save through the supported interface.

Three fields that look similar and are not

Local Address serves replication and routing between Pritunl hosts. Link Address describes how linked servers reach each other. Neither is the address a client dials, and copying the public name into them breaks the topology they describe. Public IPv6 Address is a separate field with its own record and path; an A record for IPv4 does not establish IPv6 reachability.

A DNS name also carries no port mapping and no listener. If the service listens on 1194 UDP, the name still resolves to a host that must accept 1194 UDP. An HTTP reverse proxy on port 443 that serves the web console is not the VPN transport endpoint, even when both share the same name.

Domain-based routing inside the tunnel is a different layer again. Naming the outer endpoint says nothing about which private destinations a client may reach.

Push the new name to the clients that exist

Changing the field does not rewrite profiles that already left the server. Pritunl's authenticated configuration sync can deliver host address and port changes to compatible clients, and the documented CLI client syncs before it connects or reconnects. A profile imported into NetworkManager or a standalone OpenVPN client has no such channel and needs an approved replacement. Existing sessions prove nothing, because they were established against the old value.

Where the web console sits behind a load balancer, Pritunl documents a separate Sync Address setting for the sync path. Do not reuse the console hostname for the VPN listener just because both are Pritunl.

Deliver the change in this order: save the host setting, export or sync the current profile, replace the client's copy, then reconnect. Record which clients are managed by sync and which hold imported files, because the second group will not follow automatically. A list of client ownership is more useful here than another DNS record.

Accept the change with a real connection

Resolution is the weakest possible test. dig +short vpn.example.net returning an address only proves that a record exists.

The acceptance test is a fresh authenticated connection from a client holding the new profile, followed by a request to a private resource that should be reachable through the tunnel. Check the client log for the endpoint it actually used, not the one you intended. Keep a management path that does not depend on the name being changed correctly, so a mistake cannot lock you out of the console.

Later, when the public address moves, update the record and plan for client caching and reconnect behavior. A hostname decouples clients from a numeric address; it does not move a live socket or make an unreachable listener answer.