Anycast Gateway and Silent Host Detection
A retail company runs an EVPN-VXLAN fabric with distributed anycast gateways. Each leaf has the same gateway IP and MAC for VLAN 100 (point-of-sale) and VLAN 200 (guest Wi-Fi). The security team reports that a compromised POS host on VLAN 100 is scanning the guest subnet on VLAN 200. The fabric uses a stateful firewall service node inserted as a VXLAN endpoint. Operators see asymmetric flows: return traffic for some sessions exits a different leaf than the ingress leaf, and the firewall drops the return packets. The team wants to know whether to move the firewall to a centralized service leaf, add a routing policy, or change the anycast gateway design.
1. Why does the anycast gateway design produce asymmetric return paths through the stateful firewall, and what are the options to make the firewall see both directions?
Read the worked answer
With distributed anycast gateways, each leaf is a first-hop router for the same VLAN. A POS host's traffic can be routed by leaf-A, while the return traffic from the guest subnet is routed by leaf-B if the destination host's leaf is different. A stateful firewall placed on a VXLAN service node sees only one direction if the fabric's ECMP hashing or the service-node insertion is not symmetric. The firewall then drops the return because it has no state for that flow.
Options:
- Centralize the service node: steer both directions of the inter-VLAN flow through the same firewall pair (service leaf or service chaining with symmetric insertion). This is the most reliable fix for stateful inspection.
- Symmetric service chaining: use policy-based routing or EVPN service insertion that pins a flow to the same firewall instance in both directions (for example, hash on the 5-tuple consistently and ensure the return path is steered to the same node).
- Move the policy to the gateway: if the requirement is segmentation rather than stateful inspection, enforce ACLs/VRF segmentation at the anycast gateway and avoid stateful inspection for that flow.
The design change depends on whether the requirement is stateful inspection (centralize or symmetrize) or segmentation (gateway policy).
2. The compromise is on VLAN 100 and the target is VLAN 200. What segmentation approach would you recommend, and why might it be preferable to relying solely on the firewall?
Read the worked answer
Recommend VRF-based segmentation with a dedicated VRF for POS and a separate VRF for guest, with controlled leaking only where business requires it. On Arista EOS this is implemented with VRF-lite or EVPN VRFs, and inter-VRF traffic is forced through an explicit policy point.
Why preferable to firewall-only:
- Defense in depth: segmentation at the gateway and VRF level blocks east-west traffic even if the firewall is misconfigured or bypassed.
- Blast radius: a compromised POS host cannot reach the guest subnet at L3 without crossing the VRF boundary.
- Performance: not all traffic needs stateful inspection; segmentation handles the bulk cheaply.
The firewall remains for stateful inspection of permitted flows, but it should not be the only control. The judgement is to combine VRF segmentation with a centralized or symmetrized firewall for the flows that must be inspected.
3. The firewall vendor proposes adding a static route on each leaf to force return traffic to the firewall. Evaluate the risk.
Read the worked answer
Risky. A static route on each leaf to force return traffic to the firewall can work only if every leaf has a consistent view and the firewall is reachable symmetrically. In an anycast gateway fabric, static routes fight with EVPN-learned routes and can create black holes or loops if the firewall fails or if the route is more specific than the EVPN route. It also does not scale: 96 leaves each needing a static route is an operational burden and a drift risk.
A better approach is to use EVPN service insertion or a centralized service leaf with symmetric steering, and to keep the anycast gateway design intact. If a static route is used at all, it should be a last-resort workaround scoped to a maintenance window, with a documented rollback, not a permanent design. The judgement is to reject per-leaf static routes as a permanent fix and require a control-plane-based steering mechanism.