Endpoint Selection & NAT
When you add an edge to a peering group, you choose how that edge's tunnel endpoint address is determined — the address its peers send encrypted traffic to. The right choice depends on how the edge reaches the internet (or your private network), and whether it sits behind NAT.
This page explains the endpoint options, the default, and which NAT scenarios work out of the box.
What the endpoint is
Each member's tunnel needs the remote endpoint of the other side — the WireGuard
peer Endpoint, or the IPSec Security Association's peer address. When you add or edit a
member, SecureLink resolves that address from the member's endpoint source and
programs it into the configuration pushed to every affected edge.
SecureLink programs a fixed remote endpoint for each peer. It does not perform NAT hole-punching or relay traffic between edges. So a peer can be reached only if the endpoint chosen for it is reachable from the other side. This is what makes the NAT rules further down matter.
Endpoint source options
When picking an edge, you select one of four endpoint sources:
| Source | Address used | When to use it |
|---|---|---|
| Auto (default, recommended) | The learned address — a static WAN IP if configured, otherwise the discovered public (STUN) IP, otherwise the WAN interface IP | Normal internet edges and any edge with a changing IP. This is the only option that keeps tracking the edge's address automatically. |
| WAN interface IP | The IP of the WAN port you select | The edge is directly reachable at its WAN IP — a static WAN, or two edges sharing a routable private underlay (same LAN, MPLS, etc.). |
| STUN Public | The public IP discovered for the edge | The edge has a stable public IP and you want to pin the tunnel to it. |
| Manual (pinned) | An exact IP:PORT you type (e.g. 203.0.113.5:51822) — the port is required, and a bare hostname or DNS name is not accepted here | A port-forward / DNAT front where you know the public address and port. Never changed by discovery. |
STUN Public and WAN interface IP can be selected only once the edge has reported that address. Until then they show as disabled (e.g. "STUN Public — not discovered") — choose Auto, or wait for the edge's first check-in.
The default: "Auto"
New members default to Auto. "Auto" means:
static WAN IP → else discovered public (STUN) IP → else WAN interface IP
A statically-configured WAN IP is preferred because it means the edge is directly routable. If there is no static WAN, the publicly discovered IP is used; and if the edge has a static WAN interface configured, that address takes precedence over the discovered public IP (asymmetric NAT can make the discovered value unreliable).
Pinned vs. Auto
Any source other than Auto pins the endpoint — it is captured when you select it and then:
- survives heartbeats — a later edge check-in will not overwrite it. This is the point of pinning: a manual or fixed choice stays put behind flaky or asymmetric NAT.
- does not auto-track address changes — if a pinned public or WAN IP later changes, the pin goes stale until an admin re-applies it.
Auto is the opposite: it is re-learned on every heartbeat, so it always reflects the edge's current address. On a dynamic-IP edge, prefer Auto unless you specifically need a pin.
If you pin WAN interface IP (or enter a private address manually) and that IP is a
private / DHCP address such as 10.0.0.x or 192.168.x.x, peers can reach it only on
a routable underlay — the two edges on the same LAN, a private MPLS/L2 circuit, or a
VPN that already carries that subnet. A private address is not reachable across the
public internet when the edge sits behind NAT.
This is exactly the case where a private WAN IP is the right choice: two edges behind
the same NAT share one public IP, so a public-IP endpoint hairpins and fails,
whereas each edge's 10.0.0.x WAN IP reaches the other directly. Use WAN interface
IP for same-LAN / private-underlay peers; use STUN Public or Auto only when
the edges reach each other over a routable public path.
Supported NAT topologies
A NAT'd edge can only send outbound toward a routable peer and hold its NAT mapping open. For WireGuard peerings the peer then learns the NAT'd edge's real source address (endpoint roaming, aided by persistent-keepalive), which is what makes the "supported" rows below work. IPSec peerings use static Security Associations with no roaming and no keepalive, so a NAT'd edge generally needs a port-forward even in those rows — treat an IPSec spoke-behind-NAT the same as the hub-behind-NAT row.
| Topology | Supported | Why |
|---|---|---|
| Spoke behind NAT → routable hub | ✅ Yes (WireGuard), no extra config | The spoke dials the hub's routable endpoint and holds the mapping open; the hub learns the spoke's real source (WireGuard roaming). IPSec: no roaming — the NAT'd spoke needs a port-forward (see the note above). |
| Hub behind NAT | ❌ Not without a port-forward | Every spoke must dial the hub. Behind NAT the hub's endpoint isn't reachable, so no spoke tunnel comes up. |
| Spoke ↔ spoke, both behind NAT | ❌ Not without a port-forward | Neither side can be dialed. (Hub-spoke never links spokes directly — that traffic hairpins through the hub. This applies when you need a direct mesh link between two NAT'd edges.) |
| Both edges on the same LAN / private underlay | ✅ Yes, with WAN interface IP | Use each edge's private WAN IP; the shared public IP would hairpin. |
Making the unsupported cases work
- Put the routable site as the hub. If only one site is behind NAT, make the routable site the hub and the NAT'd site a spoke — that is the supported case (first row).
- Port-forward / DNAT. Expose the NAT'd edge's tunnel listen port on the NAT device,
then set that edge's endpoint to Manual using the public
IP:PORTof the forward. Its peers now dial a reachable address. - Direct NAT-to-NAT. Two edges both behind NAT talking directly, with no port-forward, is not supported today (no hole-punching or relay).
Quick decision guide
| Your situation | Pick |
|---|---|
| Not sure / dynamic IP / normal internet edge | Auto |
| Two edges on the same LAN or a private circuit | WAN interface IP |
| Edge has a stable public IP and you want to pin it | STUN Public |
| Edge is behind NAT with a port-forward | Manual (enter the public IP:PORT) |
| The hub is behind NAT | Re-home the hub to a routable site, or Manual to a port-forward |
Related
- Adding Members — where you choose the endpoint source when adding an edge.
- Edge Peering Overview — topology types and how links are formed.
The App VPN server endpoint (set on the edge's WireGuard / App VPN server config, not on the device group) offers the same four sources and follows the same private-IP caveat.