**********************************

There are a couple of basic issues involved in connecting a machine to both the Internet (via dial up) and a LAN.

**********************************

ROUTING:

**********************************

If your LAN has no subnets that are remote to the machine connecting to the Internet, then you should have no routing difficulties. Just be sure that the "Use default gateway on remote network" option is enabled on the phonebook entry you use to connect to your ISP (Internet Service Provider) and skip this section.

The option mentioned above will cause your dial up connection to override any existing default gateway (DG) in your route table (such as your LAN's default gateway). Note, the use of this option is normal for Internet connections and the override will remain in effect only, while the dial up connection exists.

For example, before connecting to your ISP, your route table (route print) might look something like:

For the sake of simplicity, I'll remove the route entries that don't apply to this discussion (loop back test, announce, and multi-cast). The simplified table includes only your DG (1st line), the route to your local subnet (2nd line) and the loop back route for this adapter (3rd line).

After connecting to your ISP, your table might look like (simplified):

As you can see, the metric value of the original DG has been changed to 2. The metric value of a route indicates how many hops (router to router) are required for the route.

In general, when the routing subsystem is trying to determine the best route for a packet, it looks first for the most specific route (the one with the longest/largest subnet mask), then for the shortest route. Since all DG's have the same mask (0.0.0.0), then one with the lowest metric value will be used.

If you need to retain connectivity to remote LAN subnets, while connected to your ISP, you will have to add static routes to compensate for these changes. For example, if the remote LAN subnet: 192.168.100.0 (mask 255.255.255.0) is available via your LAN's DG (192.168.200.1), you would use the following command:

route add 192.168.100.0 mask 255.255.255.0 192.168.200.1

Your route table would now look something like:

Because the new route is more specific than the DG, it will be used in preference to the DG. This should provide connectivity to the 192.168.100.0 subnet, while you are connected to the Internet.

You would have to a add similar route for each remote LAN subnet. You might be able to simplify this by using a shorter mask to 'supernet' your subnets. For example, using a mask of 255.255.0.0, instead of 255.255.255.0 in the example above would have handled the routing for all subnets of 192.168.0.0 (with the exception of your local subnet, since it already has a more specific route).

Note, under NT you can make static routes persistent (they are automatically restored at reboot), using the -p option with the route command. 95's route command doesn't allow this option. With 95 you will have to re-add the routes each time your boot (the simplest solution is a batch file in the StartUp group).

Note, the use of a routing protocol (e.g. RIP or OSPF) on both your LAN router and an NT Server that is dialing out, should eliminate the need for static routes, since the routing protocol will allow the NT Server to pick up the necessary route(s) from the LAN router.

**********************************

NAME RESOLUTION:

**********************************

As a general rule, if you don't use DNS for name resolution on your LAN, you should have no difficulties with name resolution, while connected to the Internet. Just configure your machine to use your ISP's DNS servers.

In most cases, if you do use DNS on your LAN and the DNS servers are configured to relay queries to DNS servers on the Internet, you should also have no problem. Configure your machine to use your LAN DNS servers. Note, you might have trouble reaching some of your ISP's machines, if the ISP is refusing to resolve these names for external queries.

The difficulty with having DNS resolution on the LAN is that this is the most prevalent form of resolution on the Internet and the a DNS client will only send a name query to the first active server in its list. If that server is unable to resolve the name, then client will not send the query to other DNS servers. It will either fall through to the next resolution method (e.g. NetBIOS cache, WINS) or, if there are no other methods available, name resolution will fail.

So, when you are connected to the Internet, you can use either the LAN's DNS servers or your ISP's DNS servers. This means that you can resolve the names of LAN machines or Internet machine, but not both.

The work around for this problem is to provide another method of name resolution. If WINS is implemented on your LAN, you may be able to either add static entries to the WINS database for any machines that don't register with WINS automatically (e.g. unix) or configure WINS to query the LAN's DNS servers for you. Otherwise, you will have to manually add entries to your hosts file for each LAN machine that you might want to connect to, while you are connected to your ISP. For example:

192.168.100.5 server1.mycom.com

Note, the file name is hosts, not hosts.smp (hosts.smp may be located in the same directory, but it is a sample file).

Note. The DNS client behavior was changed in NT 4.0 SP4 (KB article Q198550), but I have yet to find a detailed description of the new behavior.

**********************************