> ## Content Index > Fetch the complete content index at: https://www.pinglabz.com/llms.txt > Use this file to discover other available public pages before exploring further. # VPN 0, VPN 512 and Service VPNs: SD-WAN Segmentation Explained - URL: https://www.pinglabz.com/sd-wan-vpn-0-vpn-512/ - Published: 2026-11-05T15:58:12.000Z - Updated: 2026-11-05T15:58:12.000Z - Description: In Cisco SD-WAN a VPN is a VRF, not a tunnel. VPN 0 is transport, VPN 512 is management and the rest carry users. In my home lab I also found a management port in the wrong VPN, leaking into OMP. - Author: Jaime - Tags: SD-WAN, Cisco Ask someone new to Cisco SD-WAN what a "VPN" is and they'll describe an encrypted tunnel. Then they open the config and see `vpn 0`, `vpn 512` and `vrf forwarding 10`, and none of those are tunnels. In Cisco SD-WAN a VPN is a routing table. It's VRF-lite with a new name and a few reserved numbers. This post explains the three kinds and shows them on real routers. Then it shows a mistake I found in my own lab: a management port in the wrong VPN, leaking into the overlay. I built the overlay in my home lab on Cisco Catalyst SD-WAN 20.18.2.1, with C8000v routers on IOS XE 17.18.02. This is part of the [Cisco SD-WAN series](https://www.pinglabz.com/cisco-sd-wan/). The previous part, [TLOCs Explained](https://www.pinglabz.com/sd-wan-tloc/), covered the transport side. If SD-WAN itself is new, read [What is SD-WAN?](https://www.pinglabz.com/what-is-sd-wan/) first, then the [components post](https://www.pinglabz.com/cisco-sd-wan-components/). For the old names of SD-WAN Manager (formerly vManage) and the other boxes, see the [name map](https://www.pinglabz.com/vmanage-vsmart-vbond-names/). ## The problem: three kinds of traffic, one router A branch router carries three very different things: - Underlay traffic: the tunnels themselves, DTLS to the controllers, routes to the ISP. - User traffic: the LANs you're actually connecting. - Management traffic: you SSHing in when things break. If they share one routing table, a default route for the ISP also becomes the default route for users, and a management subnet becomes reachable from every branch. You want separate tables. ## The idea: one building, separate floors Think of an office building. The ground floor is the loading dock, where the trucks come and go. The upper floors are tenants, each with its own locked door. The basement is the maintenance room, with its own key, and it isn't on the tenant directory. | Floor | SD-WAN name | Number | What lives there | | ---------------- | -------------- | ---------------------- | --------------------------------------------------- | | Loading dock | Transport VPN | VPN 0 | WAN interfaces, TLOCs, the default route to the ISP | | Tenant floors | Service VPNs | 1 to 511, 513 to 65530 | User LANs, carried across the overlay | | Maintenance room | Management VPN | VPN 512 | Out-of-band management, local only | Those numbers come straight from Cisco's VPN guide. Two lines in it matter most: - VPN 512 "is converted to VRF Mgmt-Intf" on IOS XE devices. - "VPN 512 is local to the device and not advertised in the overlay." ## The parts: VPNs are VRFs On IOS XE edges, Cisco uses VRFs in place of VPNs. A service VPN is a normal `vrf definition`, and VPN 0 is the global table. Here is the service side of edge1: ``` edge1#show running-config interface GigabitEthernet4 interface GigabitEthernet4 vrf forwarding 10 ip address 192.168.10.1 255.255.255.0 ``` ``` edge1#show vrf Name Default RD Protocols Interfaces 10 1:10 ipv4 Gi4 513 ipv4,ipv6 Gi1 65528 ipv4 Lo65528 65529 ipv4 Lo65529 ``` (Spacing trimmed.) VRF 10 is VPN 10, the user LAN. Hold on to VRF 513 for later. I didn't configure 65528 or 65529\. They hold internal loopbacks, and I left them alone. VPN 0 is the global table, where the WAN interfaces and their defaults live: ``` edge1#show running-config | section ip route ip route 0.0.0.0 0.0.0.0 10.10.1.1 ip route 0.0.0.0 0.0.0.0 10.20.1.1 ip route vrf 513 0.0.0.0 0.0.0.0 10.0.0.2 ``` The first two are the transport defaults, one per WAN link. They never show up in VRF 10\. A user in VPN 10 can't follow them to the Internet unless you add a feature for that. The Controller (formerly vSmart) runs the older Viptela CLI, which still says `vpn`: ``` controller# show running-config vpn 0 vpn 0 interface eth1 ip address 172.16.20.20/24 tunnel-interface ... ip route 0.0.0.0/0 172.16.20.1 controller# show running-config vpn 512 vpn 512 interface eth0 ip address 10.0.0.15/24 no shutdown ip route 0.0.0.0/0 10.0.0.2 ``` That's the clean pattern: transport in VPN 0 with a `tunnel-interface`, management in VPN 512. ### How the overlay keeps VPNs apart: labels A service VPN reaches the other side because OMP carries the VPN with every route, plus a label. On edge1: ``` edge1#show sdwan omp routes VPN PREFIX FROM PEER LABEL STATUS TLOC IP COLOR 10 192.168.20.0/24 1.1.1.2 1004 C,I,R 10.0.0.2 mpls 1.1.1.2 1004 C,I,R 10.0.0.2 biz-internet ``` (Columns trimmed.) Label 1004 is how edge2 tagged VPN 10\. When edge1 sends a packet to h2, it puts 1004 inside the IPsec tunnel, and edge2 uses it to drop the packet into VRF 10\. Same idea as an MPLS VPN label, without MPLS in the underlay. ``` edge1#show ip route vrf 10 C 192.168.10.0/24 is directly connected, GigabitEthernet4 L 192.168.10.1/32 is directly connected, GigabitEthernet4 m 192.168.20.0/24 [251/0] via 10.0.0.2, 10:25:13, Sdwan-system-intf ``` Each new service VPN is one more VRF on each edge. Nothing in the WAN changes. The same tunnels carry every VPN, with a different label. ## The example: what I found in VPN 513 When I first looked at edge1's `show vrf`, I expected VPN 512 for management. Instead, the management port, Gi1, was in VRF 513: ``` edge1#show running-config interface GigabitEthernet1 interface GigabitEthernet1 vrf forwarding 513 ip address 10.0.0.15 255.255.255.0 ipv6 address 2001:DB8::2/64 ``` The initial bootstrap put it in VPN 513\. That number is in the service range (513 to 65530), not the management one. So the edge treats it as a user VPN, and my OMP config advertises connected and static routes at the global level, which covers every VRF: ``` edge1#show sdwan running-config sdwan omp ... address-family ipv4 advertise connected advertise static ``` The result is on the Controller. Both edges advertise their management network and the management default route into the overlay, with label 1003: ``` controller# show omp routes VPN PREFIX FROM PEER LABEL STATUS TLOC IP COLOR 513 0.0.0.0/0 10.0.0.1 1003 C,R 10.0.0.1 mpls 10.0.0.1 1003 C,R 10.0.0.1 biz-internet 10.0.0.2 1003 C,R 10.0.0.2 mpls 10.0.0.2 1003 C,R 10.0.0.2 biz-internet 513 10.0.0.0/24 10.0.0.1 1003 C,R 10.0.0.1 mpls 10.0.0.1 1003 C,R 10.0.0.1 biz-internet 10.0.0.2 1003 C,R 10.0.0.2 mpls 10.0.0.2 1003 C,R 10.0.0.2 biz-internet ``` (Columns and the system-path rows trimmed.) Two problems in one: - A management default route is now an overlay route. Any site in VPN 513 could learn it. - Both edges use the same 10.0.0.0/24 on their management port, so the same prefix arrives from two sites. Each edge's own connected and static routes beat OMP's distance of 251, so nothing broke here. In a real network that overlap would be a trap. In VPN 512 (Mgmt-Intf) none of this would happen, because Cisco keeps VPN 512 out of the overlay. In my lab it's harmless, as nothing else lives in VPN 513 and no user sits there. I'm keeping it as a lesson rather than changing the bootstrap mid-series. On a real network, put management in VPN 512, or advertise per VRF instead of globally. [![Diagram: VPNs on edge1 and what OMP carries. VPN 0 holds the WAN interfaces; VPN 10 advertises the site 100 LAN prefix (label 1004); VPN 513 advertises a default and 10.0.0.0/24 leak (label 1003); VPN 512 Mgmt-Intf stays local and is not advertised.](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/11/sd-wan-vpn-0-vpn-512.png)](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/11/sd-wan-vpn-0-vpn-512.png?ref=pinglabz.com) ## Verify VPNs on your own edges | Check | Command | | ------------------------------------------------- | ------------------------------------- | | Which VRFs exist and which interfaces are in them | show vrf | | Routes in a service VPN | show ip route vrf | | What OMP carries per VPN, with labels | show sdwan omp routes vpn | | VPN 0 defaults | show ip route (global table) | | Controller transport and management | show running-config vpn 0 and vpn 512 | ## What breaks - **Management in a service VPN.** Shown above. It gets advertised like user traffic. Use VPN 512. - **Users can't reach the Internet.** The transport defaults live in VPN 0\. A service VPN needs its own path out, such as a hub or a direct Internet access feature. - **Route only in one VPN.** VPNs don't leak into each other by default. If h1 in VPN 10 needs something in VPN 20, that takes a deliberate policy. - **No tunnel interface in VPN 0.** Cisco's guide says a device needs at least one interface in VPN 0 to take part in the overlay. Without it there are no TLOCs. - **Overlapping subnets.** Two sites can reuse a subnet in different VPNs. Reusing it inside the same VPN, as my management ports did, gives OMP two paths to the "same" network. ## Key takeaways - An SD-WAN "VPN" is a VRF. On IOS XE, service VPN 10 is `vrf forwarding 10`. - VPN 0 is transport, VPN 512 is management (Mgmt-Intf), and 1 to 511 plus 513 to 65530 are service VPNs. - OMP carries a label per VPN, so one set of tunnels serves every VPN. - VPN 512 stays local. A management port in any other VPN gets advertised. Mine was in 513, and it showed up on the Controller.