Three address decisions before you put IoT sensors behind a VPN
Three addresses do three jobs: the public hub, the authenticated site peer, and the sensor's private address. Plan each before allocating anything public.
Three addresses get tangled in every IoT-over-VPN plan, and they are not the same kind of decision. One is how a remote operator finds the tunnel endpoint, one is how the site proves that it is the site, and one is where the sensor's service actually listens. Answer them in that order and the design mostly falls out. Answer them as a single question and you end up assigning public addresses to devices that never needed one. A sensor behind an outbound site tunnel is reachable by an authorized operator with no inbound rule pointing at the sensor at all.
Start with who initiates
Who dials determines almost everything downstream. When the site dials out to a hub, the site needs no inbound reachability, and the hub needs a name or address the site can resolve. That single choice removes most of the static public addressing debate before it begins.
The three roles then separate cleanly, and the table below is the shortest form of the decision.
| Decision | What you are actually choosing | Usual default |
|---|---|---|
| Hub endpoint | How the tunnel service is published | A DNS name, no inbound rule toward the site |
| Site peer | How the site proves its identity and which prefixes it carries | One key pair or certificate per site, prefix in the tunnel config |
| Sensor service | How the application is addressed inside the site | A stable private address from the site plan |
Each row has a different owner, which is the real point. The hub belongs to whoever runs the VPN service, the site peer belongs to the network team, and the sensor address belongs to whoever owns the device.
The hub address is bootstrap, not a destination
A name that resolves to a maintained public address is enough for the hub. A DNS record can follow the endpoint when it moves, without editing every site configuration by hand. What DNS does not do is create reachability or refresh a client that caches the old answer, and those are separate problems with separate fixes.
If you run site-to-site tunnels with no hub, the same logic holds in a different shape: one side needs a reachable endpoint, or both sides dial a third party. Someone still has to own that address and its renewals.
The site peer is an identity with a prefix attached
The peer is an identity first and a prefix second. In WireGuard terms the peer holds a key pair and the hub's AllowedIPs entry binds that key to the site's prefix. In IKEv2 terms a certificate or pre-shared key identifies the site and its traffic selectors say what it may carry. Changing either half alone breaks the arrangement, which is why an address change must never be treated as an identity change.
Keep key or certificate ownership with the site rather than with the hub operator, so a change of provider does not become a change of identity.
The prefix is the part people forget to plan. The hub has to associate the sensor subnet with the right peer, and the operator's client needs a route for it; a route that exists only on the client sends traffic into a tunnel that quietly drops it. Write the prefix into the site record next to the key fingerprint, so a replacement gateway cannot come up with different coverage unnoticed.
The sensor address belongs to the application
A private address from the site's plan is sufficient, and what it needs is stability rather than public reachability: a DHCP reservation, a static assignment, or a name in the site's own zone. If the device cannot be renumbered, translation on the site gateway is a legitimate answer as long as the translation is documented and the return traffic follows it.
One more habit worth keeping: never paste the public hub address into a next-hop field on the sensor's host. The VPN installs its own path, and an ordinary Ethernet adjacency to a public endpoint is a fiction that produces convincing-looking configuration.
Replies are the half that gets skipped. The device has to send its answer back toward the tunnel, either through a route to the operator's client or through the same gateway that translated the request. A sensor with the wrong default gateway accepts the request and answers into nothing, and the forwarding notes explain why arrival and reply routing are two requirements rather than one.
Decide, then write the boundary
Write the access boundary down before anyone connects. Restrict the gateway to the IoT segment and to the specific services the operator needs, because a working route tends to become general access by accident. Keep read-only monitoring and configuration authority as separate roles with separate identities, and name the person who removes access when the contract ends.
Approval belongs to the network owner, and being in a DMZ is not an access policy.
The test after deployment is dull and conclusive: one request inside the permitted prefix that succeeds, a counter that increments on the gateway, and one deliberate attempt outside the prefix that fails.