Joining Multiple VRFs with a Firewall

[RobertD1]

Hello,

Are there some general guidelines to follow for joining VRFs together using a Firewall? It is possible to connect VRFs together using a Firewall by placing interfaces in each VRF and use policies to allow or deny traffic through but what happens when those interfaces are participating in dynamic routing with OSPF, in the same area, they will advertise routes from one VRF to the other which I would say is not desired. 

Is it best to use VRF aware Firewalls or modes such as  VRF Lite, or Multi Context Mode (Cisco ASA) or VDOMs (Fortigate) - some examples of virtual FW features?

Do we control the cross contaminating to other VRFs of routes by using route maps on the Firewall or in the Core Switches (VSP)? 

Customer is concerned about seeing routes leaked from other VRFs by the their Firewalls using OSPF. They want some routes to be leaked between VRFs but not the majority only a small number and they certainly don't want the VRFs to learn all routes from another VRF.

Could this be controlled better if OSPF was broken up into Areas?

Any presentation available on how to connect VRFs and control route propagation?

Thanks,
Rob

[Ludovico_Steven]

Hi; there are many possible answers. The simplest is to let the Firewall have 1 IP interface in every fabric VRF, and these can all be presented to the same Firewall ethernet interface using different q-tags. You can run a routing protocol on these, the Firewall will need to learn all the routes from all the VRFs anyway. The VSP VRFs will typically only need to learn a default route from the firewall. There are as many ways to do this on the Firewall side... using route-polices to only announce a default route, or using NSSA areas for every VSP VRF... But even if the VSP VRFs get all the "other" VRF routes, the Firewall ultimately controls what traffic is allowed across VRFs anyway, so where's the problem ?

Then there are ways to create a VRF hub/spoke arrangement on the VSP, so instead of having many IP interfaces on the Firewall, you can have just 1 IP interface on the Firewall connecting into a VSP "hub" VRF. The other VRFs act as "spokes" and cannot talk to each other, but can follow a default or other routes out to the Firewall on the hub VRF. The hub VRF does need all the spoke VRF routes, so these can be ISIS accepted into the hub VRF, and then OSPF announced to the Firewall. The spoke VRFs need a static route that punches through into the hub VRF pointing directly at the Firewall IP interface, which is ARPable in the hub VRF.
That is, if all your VRFs are on the same VSP.

If your hub VRFs are scattered over a wider fabric, and the Firewall is on a different VSP, the same can be achieved again, but with a slightly different config using 2 Firewall VRFs; a "Fw-hub" VRF for disseminating the firewall route (default route) to all the client VRFs, and to collect all Firewall destined traffic. And the other "Fw-spoke" is used to for traffic coming back from the Firewall and destined for the client VRFs. Splitting the Firewall VRF ensures that no traffic can be IP routed between the client VRFs, as they won't have the necessary routes in one case and only get return traffic in the other case. The attached deck explains it starting on slide 55.

[SamPirok]

Hi Rob, sorry for the long wait here. I've been trying to find some answers for you, but ultimately there are a lot of network factors that will go in to this, and it would be best if you could open a support case so we can collect information about your specific network topology and then walk you through the set up from there. I'm sorry I couldn't be more helpful here, but please let me know if you have any issues opening a support case on our Extreme Portal.