Dynamic routing through firewall

Wed Nov 20 21:21:45 UTC 2013

Request for feedback...

We have a need for an external partner to dynamically advertise their network to us in two separate data centers. The hitch is that, touching external partners, our edge routers for B2B partners reside in DMZs.

Now, to ensure failover from one data center to another when there is a link/device problem, we need to pass dynamic routing updates through each DMZ firewall to core routing at each data center. (yes, the data centers are in sync via backbone routing)

We have multiple B2B peers, so we have multiple VRFs on the edge routers that all need to talk to our core routing, but not necessarily with each other... so we are on the hook for both the routing of these tenants as well as the security inspection.

The 4 common options we've considered:

1.       Routing through the firewall across a tunnel: Pro - relatively simple, Con - occasional MTU issues and the firewalls may not be able to disassemble/reassemble the tunnel packets for policy inpsection.

2.       Transparent firewalling: Pro - extremely easy, Con - some vendors cannot support stateful failover in HA pairs, some won't do stateful at all, so you need to open up rules bidirectional (i.e. reply ports GT 1024), plus all the whizbang IDS/IPS goes out the window along with NAT and other stuff, so it will be a very point solution

3.       BGP on the firewall: Pro - moderately easy unless the policies get very sophisticated, and firewalls automatically learn where prefixes are automatically; Con - it's BGP on the firewall... neither the network or the security teams are thrilled about it, support calls tend to loop in both teams, a security guy can cause a lot of problems with human error, we've seen some firewalls with memory leak vulnerabilities and experienced issues in the past

4.       BGP through the firewall (multihop): Pro - easy to configure, doesn't require routing on the firewall; Con - for every prefix our upstream edge router advertises to our core, we will need statics in the firewall to make sure that it knows where to forward. We can do a default pointing to the edge router with some large summaries pointing back inside (or wherever), but you get the point - the more prefixes that aren't covered by the default, the less scalable it becomes

5.       Firewall on a stick: This is untested, but the idea was floated that we could peer the edge router with our core router, but have Policy-routes on every customer VRF setting the next-hop as the firewall. The firewall will apply policy, and (like option 4) use statics to forward to the core. Reverse path traffic would pretty much do the same from Core-to firewall-to edge. It sounds ugly, and we haven't tested it, but we didn't want to toss it.

A lot of you work in multi-tenant environments, and some of you are responsible for the security between tenants. I'd like to hear alternatives, if you know of any.
And if you use one of the options I mentioned, please say why you chose it and how it works.
Finally, if you tried one of the options and it was terrible, please explain.

Thanks in advance!

CWB

________________________________
This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.