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.

Reply via email to