SD‑WAN site‑to‑site connections might not work in Insight as the router configurations required for a stable tunnel are not present.
SD-WAN / Site-to-Site Connectivity Overview
PR60 and PR460 routers support SD-WAN and site-to-site connectivity, enabling secure, encrypted communication between geographically separated networks over the internet. Once the tunnel is established, devices at each site can communicate with remote networks as if they were part of a single extended LAN, without requiring complex manual VPN configurations.The site-to-site tunnel operates at Layer 3 and is designed to work across diverse internet connections, including environments where one of the sites is located behind a NAT device, such as an ISP modem or upstream firewall.
Public IP Requirement and NAT Behavior
For reliable site-to-site operation, at least one router must have a public IP address and be directly reachable from the internet. This router acts as the anchor point for tunnel establishment and maintenance. Routers that are behind NAT do not have a globally routable address and therefore cannot accept unsolicited inbound connections. They can only create outbound connections, relying on the NAT device to maintain temporary translation state. When one router has a public IP address, the router behind NAT can initiate an outbound connection to the public router, after which the encrypted tunnel remains established and traffic can flow bidirectionally.
Limitations of STUN and UDP Hole Punching
In some deployments, NAT traversal techniques such as STUN-based UDP hole punching may be attempted when both routers are behind NAT. While this can work in limited scenarios, it is not reliable and cannot be guaranteed across all ISP networks. Many NAT implementations, especially carrier-grade NAT (CGNAT), symmetric NAT, or stateful firewall-based NAT do not preserve consistent port mappings. In these cases, the external address and port learned through STUN might differ for each peer, preventing successful hole punching. As a result, tunnel establishment might fail intermittently or stop working entirely after link resets or NAT timeouts. Because of these limitations, a topology with both IP addresses behind NAT is inherently unstable for permanent site-to-site connectivity.
Why a Public IP Ensures Stability
Having a public IP address on at least one router eliminates dependency on NAT traversal mechanisms. The public router can always accept inbound tunnel connections, allowing the remote router to reconnect reliably after restarts, WAN link changes, or temporary outages. This design ensures predictable tunnel behavior, faster recovery, and long-term stability. For this reason, deployments where one site has a public IP address and the other remains behind NAT are fully supported and recommended, while configurations where both sites are behind NAT are not considered reliable for production use.