A pattern I have seen more than once in large MPLS networks: a genuinely excellent backbone paired with a critical security hole, where the hole has nothing to do with any device misbehaving. Every router is doing exactly what it was told. The problem is what it was told. (The broader audit context is in the audit case study.)
Route targets are a security boundary. Nobody treats them like one.
L3VPN segmentation works on route-target import and export. A VRF sees exactly the routes it imports, so the import list is, functionally, the access control list between entire network segments. But it does not live in the firewall policy. It lives in routing configuration, it gets edited by network engineers solving connectivity tickets, and it is reviewed by nobody who thinks in terms of attack paths.
That is how a remote-access VRF ends up importing routes from dozens of other VRFs. Not by design, and not on one bad day. One ticket at a time, over years: a contractor needs to reach one app, an integration needs one server, someone debugging at 2 a.m. imports the whole VRF instead of one prefix and never comes back to clean it up. Each change was locally reasonable. The sum is a VPN segment with a route to far more than remote users ever needed: potentially finance, legal, executive, and server-backend segments alike.
Why the firewall never sees it
Here is the part that generalizes to any MPLS/VRF network, and it is the detail that turns a messy import list into a genuine blind spot.
The firewall sits where firewalls usually sit: on the path to the internet and between formally recognized zones, inspecting north-south traffic. But when two VRFs exchange routes directly via route targets, traffic between them resolves entirely within the fabric. A packet from a VPN client toward a finance subnet gets a label path straight from ingress to egress. It never transits the firewall because, from routing’s point of view, the firewall is simply not on the best path, or on any path. Your inspection model assumes traffic will come to the checkpoint; the routing quietly built a highway around it.
There is no alarm for this. Every BGP session is healthy, every firewall rule intact and dutifully matching the traffic that still happens to pass through it. Nothing is broken. That is precisely the problem: the design is working perfectly, and the design is wrong.
The fix is boring, which is why it does not happen
Remediation is conceptually simple and organizationally hard. In rough order of ambition: shrink imports back to a justified baseline, so the remote-access VRF reaches only what remote users demonstrably need. Then, for flows that must cross security boundaries, force the path through an inspection point (a transit VRF design that makes the firewall the only route between segments). Longer term, replace flat network-position remote access with identity-based access entirely, which is the ZTNA path.
None of that is exotic. The genuinely hard part is the operational discipline layered around it: flow baselining before you remove imports so you do not cut off something real, and treating every future route-target change as a security review, not just a connectivity change, because the import list will start regrowing the day after you prune it.
The takeaways I now carry everywhere
Segmentation you cannot see is segmentation you do not have. If you run L3VPNs, dump the import/export matrix and actually read it. The question is not “does each VRF work,” it is “what is the union of everything each VRF can reach, and would you approve that as a firewall policy?” If reading the matrix takes an afternoon, that afternoon might be the highest-value security work available to you this quarter, and it costs nothing but attention.
Know where your traffic actually flows, not where your diagram says it flows. The diagram had the firewall in the middle. The label-switched paths disagreed, and packets follow paths, not diagrams.
And the meta-lesson: judge the transport and the security model separately. A network’s backbone can deserve admiration while its import policy deserves an incident response plan. Both judgments can be true at once, and confusing them leads to either complacency or a pointless rip-and-replace.