Dynamic routing through firewall

[Cliff Bowles <cliff.bowles () apollogrp edu>]

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.