Kevin,
It's hard to be specific w/o more specifics on your side (gateway addresses,
server addresses, etc.), so I will only be able to speak in broad terms most
of the time, and use my own examples to illustrate.
As an aside, whether XP is the best choice for routing is debatable, or
whether W2K or W2K3 would be better, or even a hardware router. I suppose
you can simply select the two networks and "bridge" them, trivial using XP.
And I suppose use ICS to manage authorization, firewall, etc. How well all
this really works, how efficient, I leave that up to you. It seems it
should work. In the long run, however, W2K or W2K3 may be a better choice.
My own inclination, esp. if this is for business purposes, is to use
hardware. Better protection, easier to manage, no PC dependencies, etc.
But let's just assume it's OK to use XP for now.
As far at the clients, the PCs on subnet #2 (192.168.0.x) need to know two
things, a) the IP address of the server machine containing the file and b)
how to find it. By default, they only know their own subnet. So you need
to use "route" commands to *tell* these clients how to find the server.
Let's assume the server is on subnet #1 as 192.168.1.100. Let's also assume
the XP router is 192.168.0.10 on subnet #2 (the other being 192.168.1.10 on
subnet #1, not very relevant, but just to be complete). An appropriate
"route" command to add to clients on subnet #2 would be:
route add 192.168.1.100 mask 255.255.255.0 192.168.0.10
(this reads, to find the address 192.168.1.100 (the server on subnet #1),
send the request over to the machine w/ IP address 192.168.0.10 (our
router), it'll know what to do from there). And it will, as long as the XP
router is configured forward requests from the 192.168.0.x subnet to the
192.168.1.x subnet (which you have "bridged").
It may also be possible to use the Gateway IP instead of "route add"
commands on those same clients. The problem in doing this, however, is
*any* unknown request gets sent to Gateway IP address, it's a "catch all"
when no other possible route is known. This may or may not present a
problem. It can lead to lots of unnecessary traffic hitting the router. By
using the "route add" command, either the request is local or to the file
server, that's it. All other requests fail IMMEDIATELY because no default
exists. Again, that's up to you, either way should work.
Btw, if you do use the Default Gateway IP instead of "route add", it will
make it very difficult (if not impossible) for those clients on subnet #2 to
access the Internet gateway unless the XP router itself re-routes to the
Internet gateway via its own Default Gateway IP. IOW, now the router
forwards the unknown address (an Internet address) it receives on subnet #2,
over to the Internet gateway on subnet #1. But as long as the XP router
does NOT have such a default gateway specified, those clients on subnet #2
can't reach the Internet. This is a good and bad situation. Good in the
sense that clients on subnet #2 can be prevented from accessing the
Internet. Bad in the sense that the XP router *also* can't access the
Internet (so maintenance of that router will be problematic).
But even so, clients can still muck w/ their routing table and FORCE their
way thru. For example, some client on subnet #2 could be reconfigure as
follows (assumes the Internet gateway in on subnet #1 as 192.168.1.20):
route add 0.0.0.0 mask 0.0.0.0 192.168.1.20 metric 20
route add 192.168.1.20 mask 255.255.255.0 192.168.0.10
(this reads, ANY other address you don't know where to send, send it to
192.168.1.20 (the Internet gateway), you can find that Internet gateway by
sending this request to the address 192.168.0.10 (our router), it'll know
what to do w/ it from there). I also added the metric 20 to make sure it
was chosen as last resort. That client has just circumvented your *wall* by
merely altering the routing table! Whether this is or is not a concern is
your call, perhaps internal access *to* the Internet is not the real issue,
only outside access to the internal network. You could prevent the
circumvention I just described through *outbound* firewall rules of course.
This is why I get a little concerned about NOT using hardware for this job,
it isn't even the routing so much. The real concern is protecting the
subnets, preventing access OUT TO and/or IN FROM the Internet, firewalls,
etc. As long as you know what you're doing and cover all the bases, you can
get away w/ a software solution. But I do get concerned about dropping back
to XP, ICS, etc., I'm just not sure these are up to snuff for a business
solution.
Anyway...
Note, the route commands as I have illustrated so far are only temporary, it
will not remain in the routing table after reboot. Once you are sure this
works, you can make it permanent w/ the -p argument:
route -p add 192.168.1.100 mask 255.255.255.0 192.168.0.10
Of course, trying to maintain many clients in this fashion is tedious and a
maintenance headache. You may want to consider using the RIP or OSPF
protocols to "broadcast" routing information to listening clients. This is
where W2K or W2K3 might be a better choice, these protocols are probably
already supported as a service. Or again, a hardware router. I doubt XP
supports this out-of-the-box. But for illustration purposes, or small # of
clients, or very static environment, adding routes manually may be Ok.
HTH
Jim
