Segmentation in SD-WAN

Objective

In this lesson you will extend SGT-based segmentation across an SD‑WAN fabric so that Security Group Tags (SGTs) assigned in the campus are preserved across the WAN and enforced at remote sites. This ensures consistent policy between SDA/Campus and SD‑WAN domains — critical in production when user groups must retain the same access controls regardless of location (for example, employees keeping access to internal SaaS from branch offices). By the end you will configure VLAN→SGT mappings at the access, enable inline SGT propagation on the WAN edges, and verify that SGTs traverse the SD‑WAN IPSec fabric and are applied at the remote destination switch.

Real-world scenario: In a multi‑site enterprise, an employee VLAN in HQ is tagged SGT=4 and IoT VLAN is SGT=5. When traffic transits the SD‑WAN to a branch, the branch firewall or access switch must see the original SGT so the same SG‑ACLs and segmentation apply without reclassification at every hop.

Quick Recap

Reference topology (from Lesson 1) — devices relevant to this lesson:

• Campus Access: Campus_VN VLANs: VLAN 120 (Employee), VLAN 180 (IoT)
• SD‑WAN Fabric: WAN Edge1 (HQ), WAN Edge2 (Branch)
• TrustSec SGT values referenced in the material: SGT=4 (Employee), SGT=5 (IoT), site-level SGTs 900/950 (site tags mentioned)
• Mechanisms referenced: IPSec VXLAN inline tagging (inline SGT propagation), SG‑ACL enforcement at destination switch

This lesson adds configuration on:

• Campus access device (map VLAN → SGT)
• WAN Edge1 and WAN Edge2 (enable inline SGT tagging across IPSec/VXLAN)
• Destination switch at branch (verify SGT received and SG‑ACL evaluated)

Note: Domain names used in certificates/policies should reference lab.nhprep.com where applicable and passwords use Lab@123.

Key Concepts

• Security Group Tag (SGT): a 16‑bit numeric tag attached to frames/packets that represents the security group of the endpoint. Think of an SGT like a label on a letter — the label travels with the packet so downstream devices enforce the same rules.
• Inline SGT propagation (IPSec VXLAN inline tagging): an SD‑WAN capability that carries SGT information inside the encrypted overlay (VXLAN/IPSec) so the remote edge can recover the SGT. Protocol-level note: the SGT value is encapsulated within the overlay encapsulation and is not visible on the public WAN — the overlay edge nodes insert and terminate the inline tag before/after IPSec encryption.
• VLAN→SGT mapping: at the access switch you assign an SGT to a VLAN or interface. In production this is how you automatically tag user traffic without requiring endpoint agents.
• SG‑ACL evaluation: when a switch or firewall receives an SGT inline, it compares the SGT against an SG‑ACL (Security Group ACL). If the SGT is carried inline, the device uses the tag instead of source IP to make policy decisions.
• Why consistent SGTs across domains matter: Consistency avoids policy fragmentation. In production, an IoT VLAN tagged as SGT=5 at HQ remains SGT=5 at branch, so the same restricted policies follow the device everywhere.

Topology (ASCII)

All interface names and device labels reflect the reference material.

                           Internet/MPLS
                               |
                       +---------------+
                       |  SD-WAN Core  |
                       +---------------+
                          |         |
                   <IPSec/VXLAN> <IPSec/VXLAN>
                          |         |
                 WAN Edge1 (HQ)   WAN Edge2 (Branch)
                      |                 |
           Campus_Access_Switch     Branch_Access_Switch
             VLAN120 (Employee)      Destination VLANs
             SGT=4 mapped            Expect SGT from HQ
             VLAN180 (IoT)           SG-ACL enforcement
             SGT=5 mapped

(Note: exact public IPs and device interface IPs are assigned per your lab topology in Lesson 1.)

Step-by-step configuration

Step 1: Configure VLANs and map SGTs on the Campus Access Switch

What we are doing: Create the employee and IoT VLANs and bind an SGT to each VLAN on the access switch so that all traffic in VLAN 120 receives SGT=4 and VLAN 180 receives SGT=5. This ensures endpoint traffic is tagged at the edge before hitting the fabric.

configure terminal
vlan 120
 name Employee
exit
vlan 180
 name IoT_Dashboard
exit

! Map VLANs to SGTs (CTS manual mapping)
cts manual
vlan 120 sgt 4
vlan 180 sgt 5
exit
end
write memory

What just happened: The VLANs were created for Employee and IoT. The cts manual stanza configures an explicit VLAN→SGT mapping so frames leaving access ports in those VLANs are associated with the configured SGTs. At the packet level, the access switch will associate the SGT with the frame in its forwarding decisions and will include that SGT if inline propagation is supported later in the path.

Real-world note: Mapping SGT per VLAN is common where endpoint posture or agent-based tagging is not available — it’s a simple way to enforce segmentation by network zone.

Verify:

show vlan brief
VLAN Name                             Status    Ports
120  Employee                         active    Gi1/0/10, Gi1/0/11
180  IoT_Dashboard                    active    Gi1/0/20, Gi1/0/21

show cts manual
Manual CTS Mappings:
VLAN  SGT
120   4
180   5

Step 2: Enable inline SGT tagging on WAN Edge1 (HQ)

What we are doing: Enable the edge function to carry SGTs inline across the IPSec/VXLAN overlay so remote edges can recover the original SGT. This is required for end‑to‑end SGT propagation across SD‑WAN.

configure terminal
! Enable inline SGT propagation on the WAN edge's overlay profile
sdwan
  profile wan-overlay
    inline-sgt enable
  exit
end
write memory

What just happened: The SD‑WAN overlay profile was modified to enable inline SGT propagation. From a protocol perspective, the WAN Edge will now include SGT information in the overlay encapsulation (VXLAN metadata inside the IPSec tunnel) when it terminates access frames from the campus and forwards them across the overlay.

Real-world note: Enabling inline SGT on the overlay must be done on all participating edge nodes; otherwise SGTs will not be transported end-to-end.

Verify:

show sdwan profile wan-overlay
Profile: wan-overlay
  Inline SGT: enabled
  Other settings: ...

Step 3: Enable inline SGT tagging on WAN Edge2 (Branch)

What we are doing: Mirror the overlay inline SGT setting on the branch edge so it can decode the inline SGT coming from HQ. Without this, the branch cannot recover the SGT and SG‑ACLs will be source-IP based or misapplied.

configure terminal
sdwan
  profile wan-overlay
    inline-sgt enable
  exit
end
write memory

What just happened: The branch edge overlay profile is configured identically to the HQ edge, enabling the branch to accept and decode inline SGT metadata from the overlay. When the branch edge decapsulates the overlay, it will present the original SGT to the downstream access switch or firewall for enforcement.

Real-world note: Inline SGT propagation across multiple SD‑WAN controllers requires consistent policy and overlay settings across the fabric; ensure version and profile consistency when rolling this in production.

Verify:

show sdwan profile wan-overlay
Profile: wan-overlay
  Inline SGT: enabled
  Other settings: ...

Step 4: Verify SGT is received at the Branch Destination Switch and SG‑ACL is evaluated

What we are doing: Confirm that traffic originating in VLAN 120 (SGT=4) at HQ arrives at the branch access switch with the same SGT and that any configured SG‑ACL is evaluated against that SGT.

! On Branch_Access_Switch:
show cts local
Local CTS information:
Role: end-host
Local SGTs:
 Interface    VLAN    SGT
 Gi1/0/5      120     4

show cts connections
CTS Connections:
 Source IP        Dest IP         SGT     Src Port  Dest Port  State
 10.1.1.10        10.2.2.20        4       12345     80         active

! Verify SG-ACL match counters
show access-lists SG-ACL-EMPLOYEE
Extended IP access list SG-ACL-EMPLOYEE
    permit ip any any (matches=12)  ! shows matches counted by SGT evaluation if supported

What just happened: show cts local demonstrates the device has decoded an SGT value for a local interface/packet. show cts connections shows active CTS-tagged flows with their SGTs, confirming SGT=4 propagated across the overlay. The SG‑ACL counters indicate policy evaluation using SGTs. At the packet level, the branch edge decapsulated the IPSec/VXLAN, extracted the inline SGT, and delivered packets to the access switch with the SGT metadata for SG‑ACL evaluation.

Real-world note: If SG‑ACL counters are not incrementing, check inline SGT enablement and ensure the SD‑WAN fabric has consistent MTU and overlay compatibility — encapsulation changes can sometimes drop metadata.

Verification Checklist

• Check 1: VLAN→SGT mapping present on Campus Access — show cts manual should list VLAN 120 -> SGT 4 and VLAN 180 -> SGT 5.
• Check 2: Inline SGT enabled on both WAN Edge devices — show sdwan profile wan-overlay shows Inline SGT: enabled.
• Check 3: Branch receives SGT for flows from HQ — show cts connections on branch shows SGT=4 for traffic originating from the HQ VLAN 120 hosts and SG‑ACL counters increment.

Common Mistakes

Symptom	Cause	Fix
SGT not seen at branch (SGT absent)	Inline SGT not enabled on one or more WAN edge devices	Enable inline SGT on all edges and ensure overlay profiles are pushed consistently
SG‑ACL not matching even though SGT is present	SG‑ACL syntax or application order incorrect	Verify SG‑ACL configuration and ensure it is associated with the correct VLAN/interface; check match counters with show access-lists
Traffic dropped after enabling inline SGT	MTU/encapsulation mismatch in overlay causing fragmentation or packet loss	Verify overlay MTU and path MTU; adjust as required or enable fragmentation handling
SGT values inconsistent between sites (e.g., HQ uses SGT=900, branch expects 4)	Mismatched VLAN→SGT mapping or local manual SGT overrides	Standardize VLAN→SGT mappings across sites or use central ISE/SXP mapping; verify with show cts manual

Key Takeaways

• Always map VLANs or interfaces to the correct SGT at the access layer so the endpoint’s security identity is established as close to the source as possible.
• Enable inline SGT propagation across the SD‑WAN overlay (IPSec/VXLAN) on every participating WAN edge — it is the mechanism that carries the security label securely across the fabric.
• Verify propagation using CTS/SGT show commands and inspect SG‑ACL counters to confirm enforcement — do not rely solely on ping tests because they don’t validate tag-based policy decisions.
• In production, consistency matters: keep overlay profiles, VLAN→SGT mappings, and policy names synchronized across sites so segmentation remains uniform and predictable.

Tip: Treat SGT propagation as part of a larger Zero Trust approach — SGTs provide identity-based network segmentation that, when consistent across SDA and SD‑WAN, simplifies policy and reduces attack surface in multi‑site deployments.