Stateful Firewall Bypass in an EVPN Tenant VRF
A service provider runs 30 tenant VRFs on a 12-leaf EVPN-VXLAN fabric. Each tenant has a unique VRF and route target. A central firewall cluster sits in VRF FW, connected to leaf-01 and leaf-02 with two 40G links. Tenant-to-tenant traffic must be inspected. Tenant A (VRF-A) and Tenant B (VRF-B) each have a static default route pointing to the firewall's inside interface, and the firewall has routes back to 10.10.0.0/16 for A and 10.20.0.0/16 for B. After tenant C is added, A-to-B traffic begins reaching B directly through the fabric; the firewall sees only one direction and drops the return traffic. The EVPN Type-5 routes for 10.10.0.0/16 and 10.20.0.0/16 are present in all VRFs. No firewall filter is configured on the leafs. The new tenant was deployed by copying a shared route-target policy from an existing tenant.
1. How did Tenant C's addition expose the routing asymmetry, and what would you check to prove it?
Read the worked answer
The symptom points to route-target import, not a firewall bug. If VRF-A installs 10.20.0.0/16 as an EVPN Type-5 route with a next hop of leaf-04 instead of the firewall, A can route directly to B and bypass the firewall. The new tenant deployment likely copied a shared vrf-import policy that matches a route target also exported by VRF-B, or added a wildcard community match that A and B both use. Adding C did not create the leak by itself; it changed the shared policy or added a target that A and B already import. Check show configuration routing-instances VRF-A vrf-import and vrf-target, then show route table VRF-A.inet.0 10.20.0.0/16 extensive and look at the protocol, next hop, and route-target community. Compare with VRF-B's export target. Also check show evpn instance for the VRF and the route-target values. If the route is EVPN and the next hop is a remote VTEP, the fabric is leaking; if the next hop is the firewall, the firewall path is intact.
2. Design the correct symmetric path through the firewall for A-to-B and B-to-A traffic.
Read the worked answer
Make the firewall the only place where tenant routes meet. Each tenant VRF should export a unique route target, for example target:65000:1001 for A and target:65000:1002 for B, and import only the firewall's default or service target, for example target:65000:9999. VRF-FW imports all tenant targets and has the firewall as its next hop. Do not import B's prefix into A or A's into B. For return traffic, the firewall must have a distinct interface or VRF context for each tenant so it can route back into the correct VRF; an EVPN Type-5 route with a shared next hop is not enough if the firewall cannot distinguish the tenant. Use symmetric IRB with the anycast gateway and verify that the forward and return next hops both point to the firewall. Test with show route table VRF-A.inet.0, show route table VRF-B.inet.0, and firewall session tables for both directions. If the firewall is stateful, asymmetric routing will always fail, so the design must enforce both directions through the same firewall pair.
3. What import policy would you add to prevent future leaks, and how would you test it without an outage?
Read the worked answer
Add a deny-by-default import policy: permit only the specific service route target, and reject all other EVPN communities. Remove wildcard matches and copied policies. Use test policy with the actual route-target community before committing, then commit confirmed 10 and verify that VRF-A still has its default via the firewall and does not have B's prefix. Use show route ... hidden to see rejected routes, and check the firewall session table for A-to-B and B-to-A. As defense in depth, apply a firewall filter on the tenant IRB that permits only the firewall next hop for inter-tenant destinations, but do not rely on the filter as the primary control. After the change, run a traceroute from A to B and confirm the path goes through the firewall, then repeat in the reverse direction. Document the route-target allocation so the next tenant cannot reuse a shared policy.