Which address goes in DNS for a VPN-connected server?
A hosted server holds three addresses and they are not interchangeable. Choose the value each service needs, then confirm it from outside the machine.
A hosted server with a VPN installed ends up holding three addresses, and only one of them belongs in each place you are about to configure. Copying the number from a provider dashboard into DNS, into a listener or into an allowlist is how a working tunnel turns into a service nobody can reach. This runbook orders the work so every address is chosen for a stated purpose. It also lists the commands that confirm what you actually published.
Map the three addresses before you publish anything
Name them by function. The underlay address is what the machine uses to reach the VPN endpoint across the internet, and it is often private behind provider NAT. The tunnel address lives inside the VPN, handed out by the server or the client depending on the product. The public exit is the address a remote website logs after translation, and it need not exist on any interface you can query.
A dashboard showing one public address for a machine tells you very little about the other two roles. Underlay reachability is a requirement, not a purchase: a laptop behind a home router can reach a hosted VPN endpoint without owning a public IPv4 address. What you cannot do is invent an inbound path by writing a name that resolves to an address nobody forwards.
Pick the address by the service, not by the label
Write down what the server must do before choosing a number. Outbound API calls need a stable exit when the far side keeps an allowlist. Private access needs a tunnel address that clients can route to and a listener bound to it. Public hosting needs an inbound mapping the provider actually offers, which the exit address alone does not supply.
A single machine can serve all three purposes and still use three different addresses. What breaks is the assumption that one value covers them:
| Requirement | Value that belongs there | What you see when the roles are swapped |
|---|---|---|
| Outbound allowlisting | Public exit | Requests reach the service but are rejected |
| Private client access | Tunnel address | Client connects, nothing answers |
| Inbound web service | Provider mapping | Name resolves, connection times out |
The inbound row is the one people argue about. A record pointing at the exit address creates no listener, no firewall opening and no port mapping, and waiting does not change that. When the provider sells a dedicated address together with an inbound rule, that bundle is the capability you bought; the address by itself is not the entitlement.
Commands that show which address is which
Read the machine, not the dashboard. Interface names differ between systems, so match addresses to devices instead of trusting a label.
The first line lists every IPv4 address and its device, and the second asks the kernel which device it would use for a known outside destination:
ip -brief -4 addr show
ip -4 route get 198.51.100.10
curl -4 -s https://ifconfig.me
ss -lntp | grep -E ':(443|1194)'If the route lookup answers with a tunnel device for public traffic, your full tunnel is in effect. The listener check matters as much, because a process bound only to 127.0.0.1 will never answer on the tunnel address, no matter which name you publish.
Publish it, then verify from the outside
Publish the value the service needs and nothing more: an A or AAAA record for hosting, an allowlist entry for outbound calls, a client profile for private access. Then test from the position that matters, which is never the machine you just edited.
Two checks cover most of it, and both are cheap enough to keep in a script:
dig +short vpn.example.net A
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://vpn.example.net/healthA DNS answer proving your record exists is not proof that a request arrives, and one successful request proves only that one path works from one network. Repeat the check from a mobile connection when an allowlist is involved, because the exit you observe can depend on the address family and the route taken. Note which family you verified; a working IPv4 path says nothing at all about IPv6.
If the service is inbound, the exit address is not enough
Inbound access needs four things lined up: a name or address a client can reach, a route that delivers the packet to the machine, a listener that accepts it, and a policy that does not drop it. A VPN changes the second item and sometimes the first, and it does nothing for the third and fourth. When the tunnel is the delivery path, clients connect to the tunnel address, not to the exit.
Record which address each service depends on, then revisit that record whenever the provider changes its routing model. A server that answers privately and fails publicly is usually not broken; it is answering on the wrong identity, and the repair is a mapping decision rather than a firewall change.