|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
From: Cliff Bowles <cliff.bowles@apollogrp.edu> To: "nanog@nanog.org" <nanog@nanog.org> Date: Wed, 20 Nov 2013 14:21:45 -0700 Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org Request for feedback... We have a need for an external partner to dynamically advertise their netwo= rk 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 lin= k/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 th= at all need to talk to our core routing, but not necessarily with each othe= r... 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 sim= ple, Con - occasional MTU issues and the firewalls may not be able to disas= semble/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), pl= us all the whizbang IDS/IPS goes out the window along with NAT and other st= uff, 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 a= utomatically; 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 te= ams, a security guy can cause a lot of problems with human error, we've see= n some firewalls with memory leak vulnerabilities and experienced issues in= the past 4. BGP through the firewall (multihop): Pro - easy to configure, does= n't require routing on the firewall; Con - for every prefix our upstream ed= ge router advertises to our core, we will need statics in the firewall to m= ake sure that it knows where to forward. We can do a default pointing to th= e 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 defau= lt, the less scalable it becomes 5. Firewall on a stick: This is untested, but the idea was floated th= at we could peer the edge router with our core router, but have Policy-rout= es 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-t= o edge. It sounds ugly, and we haven't tested it, but we didn't want to tos= s it. A lot of you work in multi-tenant environments, and some of you are respons= ible for the security between tenants. I'd like to hear alternatives, if yo= u 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 explai= n. 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.
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |