skip to content

In a VRF-lite campus, how do you force all traffic between the corporate and guest VRFs through a firewall, and what quietly breaks that?

level: seniorimportance: must knowfreq 28%

answer

  1. the firewall is where tables meet
  2. one firewall interface per VRF
  3. each zone's default points at it
  4. a more specific leak wins
  5. both directions, same firewall

basics

~20 s

Give the firewall an interface in each VRF, keep no leaks between the zones, and point each zone VRF's routes for other zones at the firewall. A leaked more-specific route or an asymmetric return path silently bypasses or breaks it.

solid answer

~50 s

Make the firewall the **only place the VRFs meet**. It gets one interface or `802.1Q` subinterface in each zone VRF, and each zone VRF routes everything it does not hold, usually through a default route, to the firewall's address in that VRF. The firewall knows every zone's prefixes and routes between its interfaces under policy. No router leaks routes directly between `CORP` and `GUEST`. Two things quietly break it. A **leak**: a more specific route for a corporate prefix leaked into `GUEST` beats the default route by longest-prefix match, so traffic flows router to router and the firewall logs nothing. **Asymmetry**: a stateful firewall must see both directions of a session, so if the return path uses another firewall or a leak, replies are dropped. Traffic between VLANs inside one VRF never reaches the firewall, by design.

go deeper

for a junior

Recall that VRFs cannot reach each other on their own, so a firewall with a leg in each VRF becomes the only bridge between zones.

for a middle

Describe the construction: a firewall subinterface per VRF, each zone's default route pointing at it, and no direct leaks between zones on the routers.

for a senior

Diagnose the silent failures: a more specific leak winning over the default, asymmetric return paths dropped by a stateful firewall, and failover without a shared next hop.

for a principal

Weigh the hairpin's cost, one device in every inter-zone path, against having a single place for policy and logs, and decide what still deserves to bypass it.

## The pattern In a VRF-lite campus each zone (`CORP`, `GUEST`, `IOT`, `PAY`) has its own routing table on every router, so zones cannot reach each other until something connects them. To make inter-zone traffic pass a firewall, connect the zones **only through the firewall**: 1. **One firewall interface per VRF.** The firewall attaches to the campus core with one subinterface per zone, each bound on the router side to that zone's VRF: for example `10.10.255.1` in `CORP` and `10.20.255.1` in `GUEST`. 2. **Each zone routes other zones to the firewall.** Usually that is a default route in each zone VRF pointing at the firewall's address in that VRF, carried to every campus router by that VRF's routing instance. More specific routes for the other zones' prefixes work too. 3. **The firewall holds every zone's routes.** It forwards between its interfaces, applying policy, and keeps per-session state. 4. **No direct leaks between zone VRFs** on any router. Leaks to a shared-services VRF, if any, are reviewed with the same care. RFC 4364 section 1.4 describes the same idea in a provider network: different VRFs can hold different routes to the same server so that one group's traffic is steered through a firewall while another group's is not. In a campus, the routing table of each zone decides whether its traffic meets the firewall. ## What the firewall sees, and what it does not | Traffic | Path | Firewall sees it | |---|---|---| | Guest laptop to corporate server | `GUEST` default route, firewall, `CORP` | Yes | | Guest laptop to the internet | `GUEST` default route, firewall, internet edge | Yes | | Corporate floor 2 VLAN to floor 5 VLAN | Routed inside `CORP` by campus routers | No | | Two guests in one VLAN | Switched at Layer 2 | No | That is **macro-segmentation**: the firewall separates zones, not hosts within a zone. Finer control inside a zone is a different tool. ## What quietly breaks it - **A leak with a longer prefix.** Someone leaks `10.10.8.0/24` from `CORP` into `GUEST` on one router to fix a printing problem. Longest-prefix match prefers the /24 over the default route, so guest traffic to that subnet goes router to router. Connections work, and the firewall logs nothing, which is the dangerous part. - **Asymmetric paths.** A **stateful** firewall creates session state from the first packet it sees and expects the replies. If `GUEST`'s default points at firewall A while `CORP`'s points at firewall B, and the two share no state, a guest's TCP SYN passes through A, the server's SYN-ACK arrives at B, and B drops it as a packet that belongs to no session it knows. - **A redundant pair with no shared gateway.** A firewall pair needs one stable next-hop address per VRF that moves with the active unit, typically through a gateway-redundancy protocol; if each zone points at a unit's own address, failover breaks every zone's route. - **An interface in the wrong VRF.** One gateway or subinterface bound to the wrong VRF puts that subnet's hosts, or that link's routes, into another zone's table, with no firewall in between. - **Overlapping prefixes.** If two zones reuse the same space and the firewall routes all zones in one table, it cannot reach both; one side needs translation or unique addresses. ## Cost and capacity Every inter-zone packet now hairpins through one device. That buys a single place to write and log policy, at the price of throughput and latency on that device and a dependency of every zone on the firewall pair. How large that firewall must be, and whether this is the right place for a chokepoint at all, are security-design questions; the routing job here is to make sure the path cannot be skipped. ## How to check the design holds - In each zone VRF on every router, the only routes to other zones' prefixes should point at the firewall. - A traceroute from a guest host to a corporate host should show the firewall's guest-side address as a hop. - Firewall logs should show sessions in both directions for each inter-zone flow; one-way session records point to asymmetry. The interview answer is the construction (firewall interface per VRF, routes pointing to it, no leaks) and the two silent failures: a more specific leak that bypasses the firewall, and asymmetric return paths that a stateful firewall drops.

  • Why does a leaked /24 bypass the firewall even though the guest VRF still has its default route to the firewall?
    Because the router picks the longest matching prefix in the table. A destination inside `10.10.8.0/24` matches both the leaked /24 and the /0 default, and the /24 wins. The default route only carries traffic for which nothing more specific exists, so any leaked prefix is carved out of the firewall's path.
  • Can the firewall be transparent at Layer 2 instead of routing between VRFs?
    Yes: a bridging firewall can sit inside one VLAN path, with each zone's gateway on the far side of it. The routing design is then simpler, but each VRF still needs its traffic steered across that bridged segment, and the firewall must still see both directions of every session it filters.

saying these in an interview costs you the question

  • Traffic between VLANs inside one VRF also crosses the inter-zone firewall.
  • A default route to the firewall wins over any more specific leaked route.
  • A stateful firewall copes fine when replies return through a different firewall.
  • If the firewall logs nothing, no inter-zone traffic is flowing.
  • Static routes always beat dynamic ones regardless of prefix length.