Connecting LANs to the Internet via Dialup

The problem

Step 1: Use private IP numbers for your LAN

The machines on your LAN must all have different IP numbers, and you must make sure these don't clash with any numbers in use on the Internet. Three blocks of IP numbers have been reserved for this purpose - see RFC 1918 (

10/8          ( -
172.16/12     ( -
192.168/16    ( -
You can be sure that none of these numbers are in use on the Internet.

Step 2: Set up a gateway host

In order to connect your LAN to the Internet you will need a gateway machine which links the two together. Its ethernet interface should be given one of the numbers from the range above; the dial-up interface (e.g. ppp) will usually get its IP number from the service provider.
                                            PPP link
   PC            PC            PC           +-------+
    |             |             |              |
                 192.168.0/24  ethernet
Set up ppp on the gateway so that it can connect to the Internet, and point the other machines' defaultroute to the gateway ( in the example above)

Step 3: Solve the connectivity problem

Of course, at this point, only the gateway machine can access the Internet, using its "real" IP number a.b.c.d, and your LAN can only access the gateway. Datagrams could go OUT but not back IN because none of the routers on the Internet will forward to these private IP numbers.

However there are two solutions you can use so that machines on the LAN can still access Internet services:

IP masquerading

IP masquerading is a feature of the Linux operating system (kernels 1.3.x and above). Recent versions of Cisco router software also have a more powerful version of this called "NAT" (Network Address Translation)

When a gateway is performing IP masquerading, all TCP and UDP datagrams which pass from your LAN to the Internet have their Source IP number changed to the gateway's IP number. Datagrams which arrive in the opposite direction have the Destination IP number changed to the original host's (private) IP number. To keep track of which datagrams are for which hosts, the gateway substitutes the source port numbers in the TCP/UDP datagrams with locally-generated ones, and builds a table which maps the 'new' source port number to the 'old' IP and source port numbers.

The result is that all your hosts appear to have full Internet connectivity, without any special changes on the hosts themselves, and yet using only the one IP number from your service provider.

To configure IP masquerading on Linux, you must compile a new kernel with IP masquerading and IP forwarding enabled - at the moment you must enable CONFIG_EXPERIMENTAL to be presented with IP masquerading - and get hold of the 'ipfwadm' program if you don't have it already (or 'ipfw' for 1.3.x kernels). After rebooting with the new kernel, enable IP masquerading like this:

    [new]  ipfwadm -F -a accept -S -m
    [old]  ipfw add m all from to
This command says that all datagrams originating from 192.168/16 addresses which pass through the gateway will be "masqueraded" to use the gateway's own IP number. Put this line in /etc/rc.d/rc.local if you want it to be enabled every time you boot up.

Because IP masquerading only affects TCP and UDP data, you should be aware that you won't be able to use 'ping' to test connectivity to the Internet (since ping datagrams are ICMP)

Also note that with 2.0.x kernels, you must 'insmod' additional modules to handle masquerading of certain protocols such as ftp and realaudio; this is because the data in the streams themselves has to be modified for masquerading to work properly.

Proxy Servers

If your gateway is not running Linux (version 1.3.x or later) or recent Cisco software, IP masquerading is not available to you. However you can still make Internet available to hosts on your LAN by installing a proxy server on the gateway.

In this case, when a host wants to contact a machine on the Internet, it instead connects to the proxy server, and asks the proxy server to make the connection on its behalf. A common "general-purpose" proxy server is called SOCKS; alternatively you can run separate proxy servers for each of the services you want to make available (http, ftp, telnet etc)

The proxy server is installed in the same way as any other server on the gateway - obtain and compile the server program (e.g. sockd) and add an entry into /etc/inetd.conf so that inetd will start it running when it is required.

With proxy servers, you must configure each of your clients to use it. This makes it more complex to set up, and will be different for different hosts. For example, Trumpet Winsock has a dialog box where you can configure the IP address of the SOCKS host, but to get a Unix box to use a proxy you may need to install new versions of telnet, ftp etc. However there is one advantage of this approach: it is possible to set up a caching proxy server for http, which can improve response times and reduce traffic from your LAN to the outside world for Web access.


If you set up dial-on-demand, users of your network can bring up the Internet link simply by starting their Internet software. The first datagram which enters the gateway for the Internet triggers the gateway to dial up. The line is dropped automatically when all users on the network have finished using it.

Dial-on-demand with IP masquerading currently works best if your service provider gives you a fixed IP number. Your users must remember that there will also be a delay of usually 30-60 seconds for the gateway to dial up to the ISP and connect.

For Linux, the package you require is called "diald" - look on a mirror of in directory system/Network/serial. For FreeBSD, the user-level 'ppp' driver has a dial-on-demand feature.


Part of the net-tools package in [sunsite]/system/Network/base
Available from The v5 server adds support for proxying of UDP and DNS, and is still compatible with Socks v4 clients.
An application-specific gateway, part of the TIS Firewall Toolkit (fwtk) available from This program can proxy http, gopher and ftp. It has some protocol-specific features, such as being able to work with non-proxy-aware web clients (just add the name of the gateway in the front of the URL), and some miscellaneous features such as stripping Javascript out of incoming html documents.

Last Updated 17 October 1996