Thanks, Matt, for the quick reply. Here's more detail that might shed some light:
I'm using Netscreen appliances as firewalls for each external network. Network "A" is already set up and running (a couple of years now). The comm line goes into the untrusted port and I do a one-for-one NAT on each address. I did it this way since my previous provider had an annoying habit of changing external address blocks and using a 1-to-1 NAT allowed me to keep the same internal addresses. There are several VPN's that run through this Netscreen and changing internal addresses/DNS/NIS would have been waaay too nightmarish.
This has worked wonderfully and keeps things fairly nicely walled-off from the outside. With only one gateway handling all forwarding (and deciding if and which VPN route to use) I never had to touch /etc/sysconfig/static-routes.
Network "B" isn't installed yet (but will be in the next few days). Here's where it gets a bit trickier. My first (and current) thought was to take the coward's way out and set some servers on one gateway (Netscreen) and some on another. The VPN's would still work through the first firewall since setting up static routes for the internally-addressed 172.24.x.y in /etc/sysconfig/static-routes works just fine. The thing is that there will be traffic from the "outside" pouring into one NIC or the other and I want to make sure that I don't get into a situation where traffic comes into one interface and tries to go back to the outside client via the other one. That tends not to work very well :-)
If I were confident that just sticking another NIC in a server, putting that on a separate (logically and physically) separate network would do the trick, that would be ideal. But looking at the /etc/sysconfig/network-scripts/ifcfg-eth? file documentation, it doesn't appear that one can designate a default gateway per NIC... it _appears_ that /etc/sysconfig/network holds the GATEWAY variable and it's strictly a one-for-all. Thus, VPN traffic (subnet "x" above) gets schlepped to the right place, but that leaves the question of what to do with the "everywhere else" case (last "default" rule). Philosophically, it seems that if a packet comes in on interface "A" it ought to have a response on interface "A"; the same with interface "B".
I just don't understand the rules well enough, to be truthful. Before I get too deep into configuration (especially now while I have time to change my mind!) I figured I'd best learn first and not have to undo later :-)
Pictorially:
A:
(internet)---/___[Netscreen "A"]---/___ 172.24.0.x <--> servers
(all outside) (NAT & VPN Routing) (all inside)
B:
(internet)---/___[Netscreen "B"]---/___ ???.???.???.x <--> servers
(all outside) (NAT) (all inside)
172.24.0.x = local internal traffic
172.24.1.x = gets routed by the Netscreen to a counterpart Netscreen via VPN tunnel
172.24.2.x = as subnet .1.x to _its_ counterpart via VPN tunnel
By the way, the Netscreens handle all the VPNing. As of now, anything that doesn't belong on the .0.x subnet gets shot to the Netscreen and IT decides where the packet goes after that. For most folks, this is plenty adequate and a totally brainless setup. (You see why I chose this method!)
It gets interesting when there are two outside gateways. The routing becomes to me sort-of like the thermos bottle conundrum..."how do it know?" Without completely duplicating the VPNs (a PIA, but do-able) or isolating the servers on separate gateways on the same subnet (ecch! confusing! One server points one way and the next one somewhere else...) how could I avail a given server to either outside network? I may be dreaming bigtime :-)
The bottom line is to get the most out of each server and each network. Making each server as available as possible maximizes my comm dollar. I'm certainly not worried about RH keeping up with the load...we're answering about 40 million requests a week and the servers stay about 95% idle. (Take THAT, Windoze!) I tested Apache with dual NameVirtualHosts and it worked like a charm. All the right things are in place. I just need to put them together "just so" to come up with a Poor Man's High Availability should one provider or the other one be interrupted. I live in Florida where vicious lightening and hurricanes aren't unusual so it pays to think ahead.
Thanks again for your quick response. I'll keep listening and reading everything I can get my hands on.
Bill
-----Original Message-----
From: Matt Drew [mailto:mdrew redhat com]
Sent: Friday, July 20, 2001 12:41 PM
To: redhat-install-list redhat com
Subject: Re: Multi-Homed Servers
On Fri, 20 Jul 2001 billfarr ages com wrote:
> Hi all,
>
> Has anyone seen a GOOD doc on setting up a server with multiple NIC's
> connected to completely disparate networks? Here's the setup:
No. This is complicated-firewall/routing land.
> I have two outside networks with regular IP addresses. Each has its own
> firewall/gateway. I'd like to set up a few servers to talk to both outside
Are the outside networks behind the firewall (firewall between them and
the internet) or is the firewall between the outside network and the
inside network?
> networks. Part of the complication is that I use NAT on both the firewalls
> to convert outside addresses to internal ones. What I need to get squared
Are you using 1-to-1 NAT or 1-to-many NAT? What are you using for the
firewalls? Is the multi-homed server masquerading?
> in my mind is how to make sure that a request that heads into NIC "A" from
> network "A" on the server gets answered back on NIC "A" and a request that
> comes into NIC "B" from network "B" gets answered back on NIC "B".
Different IP addresses (different subnets) should do the trick,
although a lot depends on the network setup. It's possible the kernel
could decide that the route is quicker to go out interface "B" -- I don't
know enough to know whether or not that's true. I don't think it can
happen without gated or routed running and receiving route advertisements
from remote routers.
> The setup isn't quite obvious from the docs I've seen so far. I've been on
> RH, LDP, and a lot of other sites, but it seems that no-one is either doing
> what I'd like to do (IF possible) or what I'm trying to cook up won't work
> that way. Maybe I'm overcomplicating it, but looking at the kernel route
> table documentation doesn't give me any explicit notion of whether or not
> just adding the NIC and setting a route would even work in this situation.
>
> Any ideas? Any suggestions would be gratefully received (even, "Stop
> wasting your time--it doesn't work that way" :-)
It's hard to tell without a bit more detail, but I would think that what
you are doing *should* be possible. The problem will likely lie with the
NATing, and whether or not that will work with the configuration you have.
As you know, the NATed packets have to go in and out of the same
interface, otherwise things get broken.
> Bill Farrell
> billfarr(at)ages(dot)com
>
--
Matt Drew
Peer Review team lead
Red Hat Consumer Services
_______________________________________________
Redhat-install-list mailing list
Redhat-install-list redhat com
https://listman.redhat.com/mailman/listinfo/redhat-install-list