This is an intriguing problem, and one that applies to what my network is moving into. > First, we're bringing in 2 additional T's and want to use BGP to > provide for some measure of failover to an Class C portable IP block > we own. My question regarding this is, what do I need to do on my > Linux firewall/NAT box so that it knows how to send outbound packets? I can't tell you much about BGP, but I've heard horror stories about the excessive bandwidth needed just to send/receive the updates. One alternative to BGP would be WAN (for outbound) and DNS (for inbound) load balancing. This works if you have a large series of small IP sessions. This alternative wouldn't be appropriate if you have a few VERY large sessions to manage, like high-bandwidth IPSec tunnels. That's your judgment call. > Second, we currently have two seperate DMZ networks, one for corporate > Internet servers, and one for client-accessible Internet servers. > Currently, both these networks, and our internal LAN, (and all of our > IPSec-connected remote offices) are all subnets in the 10.* range, and > NATted to the outside. I'm using Shorewall on RH9 (Linux 2.4) to > handle the firewalling and SNAT/DNAT for the DMZs and NAT for the > LAN, and FreeS/WAN for the IPSec WAN. Sounds fine. I'm not sure how robust the shorewall framework is for complex networks, but if it works for you, all the better. > What I would _like_ to do is build an "invisible" firewall between the > routers provided with each of the three T-1 lines (yes, each T has > it's own Cisco 2600-series router). Ideally, two, in some sort of > fail-over configuration. I want to split the firewalling from the > routing primarily to remove the chance of breaking one when working > on the other, but this is not a set-in-stone requirement. I think you're on the right track. Just one point, you would have a hub/switch between each T1 and the firewall. This could be a one or two L3 switches, or you could just have a single switch/hub for each T1. I wouldn't have each T1 visible to each-other. I have inherent fears of people finding a vulnerability/DOS situation bouncing packets from one 1600 to another. That may not be based on reality, but it helps me sleep having all end points terminate at a firewall. > Would it be better to forgo the edge firewall, and simply put > firewalls on each network that connects to the Internet or another > internal network? I'd have a single edge firewall that does internet filtering and all the NATing a router that does the route selection (assuming you're not using BGP) a firewall inside the router to handle inter-LAN filtering (if the IPSec drops in as a LAN subnet, I'd place it on the interior firewall) All of this could obviously be consolidated into one or two machines. The load and risk of configuration may increase having them on the same machine, but it is cheaper if it's a concern. > If so, should the NAT for the LAN be handled by the LAN's firewall, > or the router? Described above > Since we really need to be able to connect from any network to any > network internally, would I put the IPSec links in the Linux router? Described above > Am I making this all too complex? Should I just combine the firewall > & router into a single box, build a fail-over twin for it, and have > it run the IPSec links, the proxy-arp for psuedo-bridging to the > DMZs, the NAT for the LAN->Internet communications and all the > internal routing? Failover is pretty much a requirement stepping beyond what we have here. You'll run into problems with making both active. Since you look like you'd go failover because of excessive workload, I'd follow my original suggestion above. For redundancy, you should definitely pair up each component eventually. Choose the ones with the highest failure rate to work with first. > And where the hell does BGP for the T-1s fit into this mess? Like I said, for a T1, you may run into problems. I can't say for sure one way or another. _______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
