Tunnels
EdgeConnect tunnels are the foundation of SD-WAN and take three primary forms:
- Overlay tunnels. SD-WAN bonded tunnels.
- Underlay tunnels. IPsec tunnels mapping to discrete transports.
- Passthrough tunnels. Third-party tunnels (IPsec) and local breakout.
Underlay tunnels are the focus of this section. Overlay tunnels only go down if all associated underlay tunnels are also down. For third-party tunnel troubleshooting, see the appropriate configuration guide for that integration.
Current Tunnel State
First, determine the current tunnel state. In Orchestrator, click Configuration, and then click Tunnels.
If there is no entry for the tunnel, Orchestrator is either pending synchronization or is configured to not build the tunnel (via Tunnel Exception, Regionalization, etc.).
Tunnels that are down in yellow have been configured this way administratively. Down-in progress overlay tunnels are not counted as down tunnels, as the appliance is in the process of bringing the tunnel up, and they are not hard down. Tunnels that are down in red are down due to an issue, and are the focus of troubleshooting here.
Possible reasons for issues with underlay tunnels include:
- Router configurations
- Firewall settings
- Carrier problems on MPLS, internet, LTE, etc.
- Appliance configurations (networking, labels, NAT)
Troubleshooting Steps
Research Tunnel History
Begin by analyzing the history of the problematic tunnel. History can be viewed from the Tunnels tab (Configuration > Tunnels) or the Alarms page for the appliance.
An administrator should assess if the tunnel has ever come up active, and if so, when it went down. Tunnels that never established point to initial deployment problems, whereas tunnels that failed after deployment point to environment or network changes.
Validate Routing and Connectivity
With history established, an administrator can validate routing and connectivity. From the same Tunnels tab, the tunnel traceroute provides quick feedback on whether there is reachability, and if not, where the tunnel is failing.
NOTE For internet-based transport, a failed traceroute or ping reachability does not mean there is no connectivity.
Ping and traceroute commands are available from the appliance UI and CLI, and can be used to further validate transport behavior.
Validate IP and Port
With routing and connectivity validated, an administrator can validate IPs and ports.
- The Remote IP:Port field is the IP address learned by Cloud Portal and the associated port specified by the Overlay Setting page.
- The Discovered IP:Port field is the IP address and port contained in the NAT Discovery (NAT-D) packet sent at the beginning of tunnel setup.
If there is a difference of only ports, then there is a PAT (Port Address Translation) occurring. If the tunnel does not establish, validate that both ends are not dynamic PATs, as you cannot connect dynamic PATs to PATs.
If there is a difference in both IPs and ports, then a CGNAT (Carrier-Grade NAT) is occurring. If the tunnel does not establish, validate that both ends are not CGNATs or PATs, as CGNATs cannot connect to other CGNATs or PATs.
If you see NONE:NONE in the Discovered field, the local EdgeConnect never received a NAT-D packet from the remote appliance. In this case, validate transport and firewall configurations between the two EdgeConnects.