Course contents

Unit 13: Advanced scenariosLesson 13.4 (4 of 4 in this unit)25 of 25 in the Advanced Cisco SD-WAN course

Scenario: advanced route leaking

Sharing a service between VPNs with control policy: what is leaked and in which direction, loop and security risks, and how to verify.

Advanced · 15 min read

You'll learn to leak a narrow set of routes from one VPN to another, predict what the leak does and does not allow, and verify and roll it back safely.

Technical definition

Route leaking means copying selected routes from one VPN (a separate routing table) into another, so that the two VPNs can reach each other for those prefixes only. In Cisco SD-WAN it is normally done by a centralised control policy on the SD-WAN Controller (formerly vSmart).

DNS and authentication for staff, but not for guests

The company segments traffic into service VPNs: VPN 10 for corporate users, VPN 20 for voice, VPN 30 for guests. Each VPN is its own routing table and a host in one cannot reach a host in another. Now a new shared services network, 10.20.50.0/24, holds the DNS and authentication servers. It sits in VPN 50 behind HUB-01 (site 10). Corporate users in VPN 10 must reach it. Guests in VPN 30 must not, with one optional exception: DNS only.

This is a leaking problem. The hub has the services in VPN 50. The branches have VPN 10 and VPN 30. Nothing connects them until a policy shares routes. Site IDs, VPN numbers and prefixes are examples.

Leaking one prefix from VPN 50 into VPN 10 only
Leaking one prefix from VPN 50 into VPN 10 onlyHUB-01 advertises the shared services prefix 10.20.50.0/24 into OMP as a VPN 50 route. A control policy on the SD-WAN Controller matches that route and also exports it to VPN 10. The branch edges then have 10.20.50.0/24 in their VPN 10 table with HUB-01 as the next hop. VPN 30, the guest VPN, receives no such route, so guests cannot reach the services; an optional exception could allow DNS only.HUB-01VPN 50 services10.20.50.0/24Controller policyVPN 50 routeBranch edgesVPN 10 table gains10.20.50.0/24leak to VPN 10Branch edgesVPN 30 (guest)no such routenot leakedCheck afterwards: the OMP table in VPN 10 shows the route; the guest VPN does not. Plan the rollback first.

On small screens, swipe sideways or focus the diagram and use the arrow keys.

A leak says where packets can go, not which ports. Keep it to specific prefixes and one direction, and add the zone-based firewall where you need control by protocol.

What a leak actually does

  1. HUB-01 advertises 10.20.50.0/24 into OMP, labelled as belonging to VPN 50.
  2. A control policy on the SD-WAN Controller sees that route. Where it matches, the policy accepts it and also exports it to a list of other VPNs, here VPN 10.
  3. The Controller sends the route to the branch edges as a VPN 10 route. Their VPN 10 tables now contain 10.20.50.0/24 with the next hop being HUB-01.
  4. A VPN 10 host sends a packet to 10.20.50.5. The branch edge forwards it through the tunnel to HUB-01.
  5. HUB-01 puts the packet into VPN 50. The server answers with a destination in VPN 10 space. That reply needs a route in VPN 50 back to 10.10.0.0 prefixes. If it is missing, the conversation fails.

So the leak is one-directional. Two-way connectivity needs a second leak from VPN 10 into VPN 50, covering the branch prefixes (10.10.1.0/24, 10.10.2.0/24, 10.10.3.0/24). Leak only what is needed. Guests in VPN 30 have no leak and get no route, so their packets to 10.20.50.0/24 find no match and are dropped or follow a default route to the internet, depending on the guest design.

policy lists prefix-list SHARED-SERVICES ip-prefix 10.20.50.0/24 ! vpn-list CORP vpn 10 ! ! control-policy LEAK-SERVICES-TO-CORP sequence 10 match route prefix-list SHARED-SERVICES ! action accept export-to vpn-list CORP ! ! ! default-action accept ! !

Sketch of the shape of a leaking control policy, normally built in SD-WAN Manager. The export-to action is the part to confirm in your release, along with the match fields (some releases match the source VPN too) and where the policy is applied (which site list, which direction). Not tested on a lab. The default action decides what happens to all other routes: accept keeps them flowing.

Where to leak: three options

Where to leak: three options
Where to leak: three optionsOption; How; Gains; Costs. Leak on the Controller: Centralised control policy with an export action One policy for the whole network, easy to audit, one rollback point A mistake reaches every site in the policy's site list at once. Adds routes to every edge in scope Leak on the edge: Service-side configuration on a router, if your release supports it Local, affects one site, does not depend on the Controller Many places to configure and audit. Easy to drift. Release support is not confirmed here Firewall hairpin: Send traffic from one VPN out to a firewall and back into the other, for instance with a service chain Real inspection and logging between the VPNs. Rules by application and user group More hops, more capacity needed, extra devices and more design workOptionHowGainsCostsLeak on theControllerCentralised controlpolicy with an exportactionOne policy for the wholenetwork, easy to audit,one rollback pointA mistake reaches everysite in the policy's sitelist at once. Adds routesto every edge in scopeLeak on the edgeService-sideconfiguration on arouter, if your releasesupports itLocal, affects one site,does not depend on theControllerMany places to configureand audit. Easy to drift.Release support is notconfirmed hereFirewall hairpinSend traffic from one VPNout to a firewall andback into the other, forinstance with a servicechainReal inspection andlogging between the VPNs.Rules by application anduser groupMore hops, more capacityneeded, extra devices andmore design work

On small screens, swipe sideways or focus the diagram and use the arrow keys.

Read each row across: the left box names the item, the others describe it.

In practice, a narrow Controller leak for a small shared-services prefix is common, and the firewall is added where policy requires inspection. A design opinion, not a Cisco rule: if auditors or compliance ask "what is allowed between corporate and the services network", a firewall gives an answer written in rules, whereas a route leak only gives reachability.

Risks to design for

  • Segmentation is reduced. After the leak, VPN 10 can reach 10.20.50.0/24 on any port. The leak says where packets can go, not which ports. Use the zone-based firewall or a service chain for control by protocol, and keep the leak to specific prefixes rather than a whole VPN.
  • Overlapping prefixes. If VPN 10 already has a route for 10.20.50.0/24, or if the same prefix exists in two VPNs, the leaked route competes with it. Avoid overlap in a design that leaks.
  • Mutual leaking. Leaking A into B and B into A for overlapping or summarised prefixes can create loops or odd best paths, since each side re-advertises what it receives. Keep leaks specific and one-way where possible.
  • Scale. Each leaked route is an extra route on every edge in scope. A handful of prefixes is fine. Leaking whole VPNs multiplies routes and the work the Controller does.
  • Guests. A guest DNS exception means leaking only a DNS server's /32 prefix to VPN 30 and then restricting the protocol with a firewall, since a route alone allows every port.

Verify the leak

Check from the Controller outwards, one VPN at a time.

Example output written for this lesson, simplified; real output has more fields and a different layout
BR-01#show sdwan omp routes vpn 10 10.20.50.0/24
VPN  PREFIX         FROM PEER    PATH ID  LABEL  STATUS  TLOC IP      COLOR         PREF
10   10.20.50.0/24  10.255.0.11  201      1004   C,I,R   10.255.1.1   mpls          -
10   10.20.50.0/24  10.255.0.11  202      1004   C,I,R   10.255.1.1   biz-internet  -
The route is in VPN 10 and points at HUB-01 (system IP 10.255.1.1). The exact command options for filtering by VPN vary with the release. If the line is missing, the policy did not match or is not applied to BR-01's site.
Example output written for this lesson, simplified; real output has more fields and a different layout
BR-01#show ip route vrf 10 10.20.50.0
Routing Table: 10
Routing entry for 10.20.50.0/24
  Known via "omp", distance 251, metric 0, type omp
  Routing Descriptor Blocks:
  * 10.255.1.1 (default), from 10.255.1.1, 00:02:41 ago
The edge installed it from OMP. The distance 251 is the commonly seen OMP value; check yours. A VPN 30 table must not contain this prefix. Run the same command with vrf 30 to confirm: the expected answer is a not-in-table message.
  • From a VPN 10 host, ping 10.20.50.5 and run a traceroute. The first hop is the branch edge and the next goes via HUB-01.
  • From a VPN 30 host, the same ping must fail.
  • From a server in VPN 50, ping a VPN 10 host. If this fails while the forward test works, the return leak is missing.
The forward ping works but no replies arrive. Where do you look?

In VPN 50 at HUB-01: show ip route vrf 50 10.10.1.0. If the branch prefix is absent, the return leak (VPN 10 into VPN 50) is missing or does not include that prefix. Fix the policy, then retest from both sides.

Plan the rollback before the change

  1. Save the current policy (a Manager policy copy or a CLI export) so you can reapply it.
  2. Apply the leak to one test site list (for example only site 101) before the whole network.
  3. Keep the removal step written down: deactivate the policy or remove the export action, and check that the prefix is gone from VPN 10 tables.
  4. Allow time for the Controller to push the change. Do not assume an instant effect.

What to record

The list of leaked prefixes with owner and reason, direction of each leak, the sites and VPNs in scope, the firewall rules that limit them, the verification outputs before and after, and the rollback steps with the date tested. Note the release, since the policy syntax and edge-side options differ.

Test yourself on route leaking

Predict · scenario 1

10.20.50.0/24 is leaked from VPN 50 into VPN 10. VPN 10 hosts can ping the server, but the pings get no reply. What is missing?

Predict · scenario 2

A colleague proposes leaking all of VPN 10 into VPN 50 to be safe. What is the strongest objection?

Predict · scenario 3

Guests in VPN 30 may reach the DNS server at 10.20.50.53 only on port 53. Which design meets this?

Predict · scenario 4

After the leak is applied, a VPN 10 table shows 10.20.50.0/24 but VPN 30 does not. Is this correct?

FAQ

If I leak a route from VPN 50 into VPN 10, can VPN 10 hosts already talk to VPN 50?
Only one direction is ready. VPN 10 now has a route to the services, so its packets reach them. The replies need a route back to VPN 10 in the services VPN. Without it, the replies are dropped, so a two-way conversation needs both directions leaked.
Is route leaking a security feature?
No, the opposite. Segmentation keeps VPNs apart and a leak removes that separation for the prefixes involved. Treat each leak as an exception to security policy, keep it narrow, and consider a firewall between the VPNs.
Can the same be done on the WAN Edge itself?
Some releases offer route leaking between VPNs on the edge, in the service-side configuration. That is not confirmed here, so check the configuration guide for your release and model before choosing it.