Back
Lesson 3 of 7

Control Connections and Certificates

Objective

In this lesson you will configure and verify the DTLS/TLS control connections used by SD‑WAN controllers and the certificate-based authentication that secures those control-plane sessions. This matters because the control plane carries routing, policy, and keying information (OMP) — if control connections fail or are not authenticated, the overlay cannot form and policies will not be distributed. In production, certificate-based DTLS/TLS is used to prevent rogue devices from joining a corporate SD‑WAN fabric and to ensure controllers and WAN Edge routers mutually authenticate before exchanging sensitive OMP updates.

Topology

Use the same physical layout from Lesson 1. This lesson focuses on the WAN Edge device interface names and the system IP already designated for this device.

ASCII topology (showing the WAN Edge system IP and WAN interfaces):

                             Internet / Transport
                                    |
                             +--------------+
                             |  WAN Router  |
                             |  (Provider)  |
                             +--------------+
                                    |
                               G0/0 / G0/1
                                    |
            +---------------------------------------------+
            |                WAN Edge (SD‑WAN)           |
            |  System IP: 10.0.0.1                        |
            |  Interfaces: G0/0  G0/1                     |
            +---------------------------------------------+
                                    |
                    Management / LAN (VPNn / VPN512 etc.)

Note: The only exact IP we must use from the reference material is the WAN Edge System IP 10.0.0.1 on the WAN Edge device. Interface names used in this lesson are G0/0 and G0/1 as shown in the reference.

Device Table

DeviceRoleKey Interface(s)System IP / Notes
WAN EdgeSD‑WAN Edge routerG0/0, G0/1System IP: 10.0.0.1, TLOC Color: Internet, Encap: IPSecTLOC
Controller(s)SD‑WAN Controllers (control-plane)—Controllers provide DTLS/TLS endpoints for OMP (addresses configured out-of-band in production)

Quick Recap

  • In previous lessons you prepared the WAN Edge basics and learned about TLOCs and VPN separation (VPN0 for transports, VPN512 for management, VPNn for service).
  • This lesson concentrates on the control plane: how the WAN Edge establishes authenticated DTLS/TLS connections to Controllers and how certificates are used to validate identities.
  • We will use the WAN Edge System IP 10.0.0.1 and physical interfaces G0/0 and G0/1 (used for transports) as the anchor for our configuration examples and verifications.

Key Concepts (theory + practical implications)

  • Control Connections (DTLS/TLS)

    • Theory: SD‑WAN control connections use authenticated DTLS (UDP) or TLS (TCP) tunnels between WAN Edge routers and Controllers. These tunnels carry OMP routes, TLOCs, keys, and policy.
    • Practical: When a WAN Edge comes up, it establishes a DTLS/TLS control session to a Controller; this must authenticate before OMP advertisements are accepted.

  • Certificates and Authentication

    • Theory: Certificate-based authentication uses PKI — controllers and WAN Edge routers present certificates signed by a trust anchor. The handshake validates identity and then derives session keys for AES256‑GCM control-plane encryption.
    • Practical: In production, devices typically use trusted CA-signed certificates (or enterprise CA) rather than self-signed certs to prevent man-in-the-middle or rogue registration.

  • System IP vs. Underlay IP

    • Theory: The System IP (10.0.0.1) is the identifier used inside the SD‑WAN fabric for OMP and TLOC mapping; it is not necessarily the physical interface IP.
    • Practical: The System IP is advertised to Controllers and peers as part of TLOC state. In NAT scenarios, external public address is validated by a validator service so the control-plane can still form.

  • Control-plane Behavior & OMP

    • Theory: After DTLS/TLS is established, the Controllers and Edge exchange OMP updates: reachability (subnets), TLOCs, keys, and policy. OMP runs over the authenticated control channel.
    • Practical: If the DTLS/TLS session uses DTLS (UDP), NAT traversal and proper port handling are required; if TLS (TCP) is used, the connection is more firewall-friendly but less efficient for rapid key updates.

Tip: Think of the certificate trust relationship like a passport check: the Controller checks the WAN Edge's certificate against a trust anchor before handing over the grant (OMP updates). Without that check, anyone could claim to be a network element.

Step-by-step configuration

Note: Each step contains the exact commands to enter configuration modes, an explanation of what the commands do and why they matter, and verification commands with expected outputs. All commands presented reference the System IP 10.0.0.1 and interface names G0/0 or G0/1 as required by the lab reference.

Step 1: Set the System IP and TLOC color

What we are doing: We assign the device its SD‑WAN System IP (the identifier used in OMP and TLOC advertisements) and specify the TLOC attributes such as color and encapsulation. The System IP is essential for the controller to identify this WAN Edge inside the fabric.

configure terminal
 system
  system-ip 10.0.0.1
  tloc color Internet
  tloc encapsulation IPSecTLOC
 exit
exit

What just happened:

  • system-ip 10.0.0.1 configures the SD‑WAN identifier that will be advertised to controllers as the device’s System IP.
  • tloc color Internet labels this transport with the public color "Internet", which controllers and peers use to decide which TLOCs to form tunnels to.
  • tloc encapsulation IPSecTLOC sets the encapsulation type for the TLOC to IPSecTLOC (the typical encapsulation used for data-plane tunnels).

Real-world note: In multi-transport sites you will configure multiple TLOCs with different colors (e.g., MPLS vs Internet). Controllers can auto-restrict tunnels between colors based on policy.

Verify:

show system
System IP: 10.0.0.1
TLOC:
  Color: Internet
  Encap: IPSecTLOC

Step 2: Configure VPN0 and the physical WAN interface

What we are doing: Assign an IP on the WAN-facing interface (VPN0 is reserved for transports) and bring the interface up. This provides underlay connectivity the control channel needs to reach Controllers.

configure terminal
 vpn 0
  interface GigabitEthernet0/0
   ip address 10.0.0.1 255.255.255.0
   no shutdown
  exit
 exit
exit

What just happened:

  • vpn 0 places the interface in the transport VRF that isolates underlay from user LANs.
  • Setting ip address 10.0.0.1 255.255.255.0 assigns the underlay IP used by the physical interface — here we align the interface IP to the System IP for clarity (in many deployments the System IP may be different from the physical IP).
  • no shutdown ensures the interface is administratively up so control connections can egress.

Real-world note: In production the underlay interface IP will typically be provided by the ISP or DHCP; verify NAT and firewall rules allow DTLS/TLS to controller ports.

Verify:

show ip interface brief
Interface              IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0     10.0.0.1        YES manual up                    up

Step 3: Generate and install a device certificate (self-signed for lab)

What we are doing: Create a device certificate that the Controller can validate during the DTLS/TLS handshake. Certificate-based authentication ensures both ends of the control connection are validated.

configure terminal
 crypto key generate rsa label edge-key modulus 2048
 crypto pki trustpoint NHPREP-TP
  enrollment selfsigned
  subject-name CN=wan-edge.lab.nhprep.com,O=NHPREP
  revocation-check none
 exit
 crypto pki enroll NHPREP-TP
exit

What just happened:

  • crypto key generate rsa label edge-key modulus 2048 creates a 2048-bit RSA key pair stored on the device; this becomes the private/public key for the cert.
  • crypto pki trustpoint NHPREP-TP and enrollment selfsigned create a trustpoint and produce a self‑signed certificate with the specified subject name (CN and O).
  • crypto pki enroll completes the enrollment, placing the certificate into the local certificate store for use in TLS/DTLS handshakes.

Real-world note: Use an enterprise CA or manufacturer-signed certificates in production. Self-signed certificates are acceptable for lab and testing only.

Verify:

show crypto pki certificates
Trustpoint: NHPREP-TP
  Certificate:
    Subject: CN=wan-edge.lab.nhprep.com,O=NHPREP
    Validity:
      Not Before: Jan 01 00:00:00 2025 GMT
      Not After : Jan 01 00:00:00 2026 GMT
    Serial Number: 00:01
    Key Usage: Digital Signature, Key Encipherment

Step 4: Enable DTLS/TLS control and point to controllers (control connection profile)

What we are doing: Configure the device to use DTLS/TLS for control-plane connections and bind it to the certificate we created. This tells the WAN Edge to present its certificate during TLS handshakes and to accept controller certificates validated by the trustpoint.

configure terminal
 control-connection
  transport dtls tls
  trustpoint NHPREP-TP
 exit
exit

What just happened:

  • transport dtls tls instructs the device to negotiate DTLS first and fall back to TLS if necessary, following common SD‑WAN behavior for control plane reliability and NAT traversal.
  • trustpoint NHPREP-TP binds the certificate/trustpoint we created earlier to the control-plane TLS profile so the certificate is used for handshake and validation.

Real-world note: DTLS offers lower latency and better suitability for NATted UDP scenarios; TLS over TCP is often used where firewall traversal is constrained.

Verify:

show control-connection
Control Transport: dtls/tls
Trustpoint: NHPREP-TP
Status: enabled

Step 5: Verify control-plane session establishment and OMP advertisements

What we are doing: Check that a control connection to the Controller has been established, and that OMP routes/TLOCs are being exchanged. This confirms the certificate-based authentication succeeded and OMP is operational.

show omp connections
Control Connections:
  Peer Controller: controller-01
  Connection Type: DTLS
  Local System IP: 10.0.0.1
  State: Established
  Authenticated: yes
  Certificate Subject: CN=wan-edge.lab.nhprep.com,O=NHPREP

What just happened:

  • The show omp connections output shows an established DTLS control session to a controller with the local System IP 10.0.0.1.
  • Authenticated: yes indicates the certificate handshake completed and the controller validated the device certificate and vice versa.
  • Once this is established, OMP updates (routes, TLOC publishing, policies) will be exchanged and the WAN Edge will advertise its attached subnets and TLOCs.

Real-world note: If the connection fails to authenticate, check certificate trust anchors on the controller side and ensure time/date on both endpoints is correct (cert validity).

Verify:

show omp routes
OMP Routes:
  Network: 10.100.0.0/24
  Origin: Connected
  Next-hop: TLOC 10.0.0.1 color Internet
  Hostname: wan-edge.lab.nhprep.com

Verification Checklist

  • Check 1: System IP and TLOC attributes are configured and visible
    How to verify: show system — expect System IP: 10.0.0.1 and Color: Internet.

  • Check 2: VPN0 interface is up with correct IP (underlay)
    How to verify: show ip interface brief — expect GigabitEthernet0/0 10.0.0.1 up up.

  • Check 3: Certificate installed and bound to control transport
    How to verify: show crypto pki certificates and show control-connection — expect certificate subject CN=wan-edge.lab.nhprep.com and control transport dtls/tls bound to NHPREP-TP.

  • Check 4: Control connection to Controller is established and authenticated; OMP routes present
    How to verify: show omp connections and show omp routes — expect Established state and OMP routes with TLOC next-hop.

Common Mistakes

SymptomCauseFix
Control connection remains in "Connecting" or "Down"Certificate not installed or mismatched trustpoint on the controllerVerify certificate on WAN Edge and ensure controller has the corresponding CA/trust anchor; reinstall certificate or use a CA-signed cert
OMP shows no routes after control establishedNo TLOC published or VPN mappings incorrectConfirm TLOC color/encapsulation and that interfaces are in VPN0; check show system and show ip interface brief
DTLS session fails through NATNAT device rewrites UDP ports or blocks DTLS trafficEnsure NAT keeps mappings for DTLS UDP ports or allow TLS fallback over TCP; confirm connectivity to controller public IP and that validator is reachable
Certificate shows "Not Valid" or "Expired"Device clock/time incorrect or certificate expiredFix device NTP/time and re-enroll or renew certificate; ensure timezone and NTP are configured before certificate operations

Key Takeaways

  • The SD‑WAN control plane uses DTLS/TLS secured channels to exchange OMP updates; certificate-based authentication is the recommended method to prevent unauthorized devices from joining the fabric.
  • The System IP (10.0.0.1) is the device identifier inside the fabric and is advertised with TLOCs; ensure it’s correctly configured and reflected in OMP.
  • Certificates must be valid, trusted by the Controller, and matched to a control transport profile (DTLS/TLS). Time synchronization (NTP) and an appropriate CA policy are prerequisites in production.
  • In production, prefer CA-signed certificates and carefully design transport colors (Internet vs MPLS) so Controllers can apply policies and prevent undesired inter‑region tunnel formation.

Important: Think of the control channel like the network’s nervous system — it must be authenticated and healthy for policies and reachability to propagate. Misconfiguration in certificates or control transport prevents the entire fabric from functioning even if the underlay is healthy.

If you want, next we can add controller-side verification examples or demonstrate a certificate renewal flow using an enterprise CA to mirror production operations.

Practice with Hands-On Labs

30 step-by-step labs for CCNA, CCNP Enterprise & Security