PCI Segmentation with a Stateful Firewall in an EVPN-VXLAN Fabric
A payment processor operates a three-tenant EVPN-VXLAN fabric: PCI (40 workloads), corporate (200), and shared services (30). PCI-to-corporate traffic must be inspected by a pair of SRX4600 firewalls, each rated 20 Gbps, in active/active mode. Intra-PCI traffic must stay within the PCI leaf pair and must not traverse the spines. Corporate-to-shared traffic can be routed without inspection. The fabric has 8 leaf pairs, 2 spines per pod, and 40G uplinks per leaf. The security team proposes a service leaf with firewall-on-a-stick and policy-based routing (PBR) from every leaf; the network team is concerned about tromboning, asymmetric routing, and firewall session state. The design must survive a single firewall or service-leaf failure without opening PCI to corporate.
1. Design the traffic path for PCI-to-corporate and intra-PCI. Where does routing happen, and what stays local?
Read the worked answer
Put the PCI VRF only on the dedicated PCI leaf pair, with the PCI subnet and anycast gateway local to those leaves. Intra-PCI routing stays in that VRF and never leaves the leaf pair, so it does not traverse the spines or the firewall. Create a separate corporate VRF on the other leaves. For PCI-to-corporate, route from the PCI VRF to a pair of service leaves that attach the SRX4600 cluster in routed mode. The service leaf owns the inter-VRF handoff: PCI traffic enters the firewall inside interface, policy is enforced, and traffic exits to the corporate VRF. Use EVPN Type-5 routes to advertise the PCI default or summary toward the service leaf and corporate return routes back. Do not stretch the PCI VLAN across all leaves, and do not use PBR on every leaf; centralizing the inter-VRF policy at the service leaf avoids tromboning and keeps firewall state deterministic.
2. Compare the service-leaf inline design with PBR from every leaf. Which do you recommend, and why?
Read the worked answer
PBR from every leaf forces each leaf to classify traffic and redirect it to the firewall, which creates per-leaf policy, asymmetric return paths, and a high risk that return traffic bypasses the stateful firewall. It also makes firewall active/active hashing difficult and increases tromboning because traffic may cross the fabric twice. The inline service-leaf design is deterministic: all inter-VRF traffic follows the same path through the service leaf and firewall cluster, so session state and policy are centralized. It uses EVPN route leaking rather than PBR, which is easier to audit. The trade-off is that the service leaf and firewall pair become a capacity and failure bottleneck, so deploy two service leaves and an SRX chassis cluster. With 40 PCI workloads and 20 Gbps firewalls, capacity is ample, but design the service leaf uplinks for the inspected traffic plus failover.
3. What happens if one SRX or one service leaf fails, and how do you keep PCI fail-closed?
Read the worked answer
Use an SRX chassis cluster with redundant interfaces and session redundancy so that a single firewall failure preserves existing sessions and the surviving node takes over. If one service leaf fails, EVPN withdraws its Type-5 routes and BFD speeds up the withdrawal; the PCI VRF should have a preferred path to the remaining service leaf, and the corporate VRF should have a return path through the same remaining service leaf. Keep the PCI VRF isolated: do not configure a direct leak from PCI to corporate as a backup. If both service leaves or both firewalls fail, remove the PCI-to-corporate routes rather than falling back to plain routing. Use route tracking and a fail-closed policy on the service leaf, and test that a firewall failure does not cause traffic to bypass inspection. Intra-PCI traffic remains local and unaffected.