Pages

Tuesday, 29 March 2016

Connecting a LAN to the Internet



eXTReMe
Keywords: IPRoute, ISPA, ISDN, proxy server, sharing a connection to the Internet, modem sharing, IP Masquerading, Network Address Translation, software router, DOS
This page contains some background information on how you can connect a LAN (running Ethernet, for instance) to the Internet, using a standard (personal) account. The connection to the Internet can be an analog modem, ISDN or even a cable or ADSL modem.
Most of this information is severely outdated. Nowadays it's more cost effective to buy an inexpensive hardware based firewall/router such as those from Linksys or Draytek. This webpage mainly covers IPRoute, a DOS software router. This program does not seem to be sold anymore. Alternatives are mentioned below. Linux based solutions such as Astaro are probably a much better solution nowadays. Plus, they are free! People also use the Internet Connection Sharing option included with recent versions of Windows.



IPRoute is a DOS software router for TCP/IP.  ISPA is an emulator which lets an ISDN card appear like an Ethernet card to DOS. The focus of this webpage will be mainly on using IPRoute with ISDN plug-in cards through the ISPA driver. The software also works with analog modems, ISDN modems and cable modems (in that case, just skip the parts where ISPA is mentioned because ISPA is only needed when you use an ISDN plug-in card).
The latest version for registered users of IPRoute is now V1.10.

Index

Back to my ISDN page
Back to my homepage


Introduction

A (personal) Internet account isn't that expensive anymore. Let's say you have a whole (Ethernet) network of computers at home. One for yourself, one for the kids, one on the toilet, you get the idea... Preferably, you want to access the Internet from each of those machines. One machine, which has the modem, will be the "middle-man" for the other machines. You want all connected machines to share the link to the Internet. If you have a couple of "workstations", a 28K8 modem will probably not be enough. ISDN may be a good option in that case. If you use a "proxy" or a feature called "IP Masquerading", you will be able use a standard (read: inexpensive) personal account to connect the LAN to your Internet Service Provider (ISP). All this is explained in the following.
Back to top


Examples of application

Here are some examples of connecting a LAN to the Internet. I already mentioned the "homebrew" LAN. In most cases people use a coax Ethernet cable so they can do without a "hub" (central interconnection device). Another application is a school which has a couple of computers and wants to connect to the Internet at low cost. Or you can think of a small office. I myself used IPRoute in combination with ISPA (described later on) to connect the LAN of a user group to the Internet during meetings (HCC Amsterdam).
Back to top


IP addresses

But first, a little bit of theory. Every computer connected to the Internet must have a unique "licence plate", called an IP address. Unfortunately there is only a limited number of IP addresses available. As with any scarce goods, if you need more IP addresses you will have to pay!
Internet developers have devised workarounds which help to limit the number of needed IP addresses. For instance, an ISP has a certain number of customers but they can't possibly be all logged in at exactly the same moment. So the ISP buys a smaller block of IP addresses. When you call in to your ISP, you receive one of the IP addresses out of this block from your ISP during the connection setup negotiation process. So you don't know your IP address in advance. This is called a dynamic IP address.
However, some ISPs also offer fixed addresses, i.e. every time you dial-in you get the same IP address. This is of course advantageous if you are connected to the net for long periods (e.g. if you have an ADSL or cable modem) or if you want to run servers. The problem is that most ISPs charge extra for static IP address if they are used for dial-up connections.
Back to top


Different approaches to sharing a connection

So you want to connect your LAN to the Internet. This means that there is one machine which has the link to the Internet (modem, ISDN card). Let's call that one the gateway computer, for simplicity. The gateway computer receives packets from the other machines (let's call those the workstation computers) and then passes them to your ISP. And vice versa.
There are several options that can be used to connect a LAN to the Internet. Invariably, they all work with one machine forwarding the packets it receives from the other machines to the Internet. 
  • Serial port sharing
  • Routing
  • Proxy servers
  • IP Masquerading
I will discuss each of them in the next paragraphs. Tony Rall of IBM Almaden has also written an excellent article on this, with special attention to OS/2.
Back to top

    Serial port sharing

    Serial port sharing is mostly used by businesses.

    As you probably know, you can share disk drives and printers with several operating systems such as Windows for Workgroups, Windows 95/98/ME/NT/2K and Warp Connect / Warp 4. But in some cases you can even share a serial port. A modem can then be attached to this shared serial port. However, only Warp Connect and Warp 4 support serial port sharing out of the box. OS/2 2.x and Warp non-Connect support it if you install the free OS/2 LAN Manager client by Microsoft. A special version of Windows, called Small Business Server (SBS), also contains a modem server. Special Windows client software is included with SBS. IBM now also has a Small Business Suite for Windows, competing with Microsoft's SBS. As you can see from the specifications, IBM's SBS also has a modem pool server, which probably means that it too comes with its own proprietary modem clients.Client software which is readily available for your Windows machine(s) is offered by (in alphabetical order):

    I am not sure if SBS (from either Microsoft or IBM) is compatible with these clients. Serial port sharing over NetBIOS/SMB/CIFS has not been standardised nor documented, as far as I know.
    In most business setups, a special modem server is used. This is a hardware device which has multiple serial ports equipped with modems. Workstation computers which connect to this server then get a virtual serial port, say COM6. The disadvantage is that only one user can gain access to a modem at the same time, if he uses it or not. He has to release the remote modem out of the goodness of his heart, once he's finished. The advantage is that the user has the full bandwidth of the modem at his disposal. Plus, it is not limited to IP or IPX traffic but you can also use it with fax software, connect to BBSes etc.
    Back to top


    Routing

    This is what most businesses use. They get a block of static IP addresses from their ISP and give each of their machines an IP address. In most cases, what I call the "gateway computer" is in fact a router, a special hardware device which forwards the packets. Many operatings systems (e.g. Unix, Windows NT/2K, OS/2 etc.) can route IP packets too. *) The disadvantage of routing that it is more expensive because you will have to 'buy' static IP addresses from your ISP. Not only that, the ISP will have to define a "route" to your own little subnet on their systems. That means they'll have to do some work and thus they want to be paid for it. It also means that intervention by your ISP is required, i.e. you can't do it all on your own. This is in contrast with the next two strategies.*) Nathan Goyette pointed out to me that Windows 9x can be tweaked to support routing through some registry editting, although this is an undocumented feature.
    Back to top


    Proxy servers

    Routing works great for businesses which are connected to the Internet 24 hours a day. But what if you're not, and you still want to hook up a whole LAN to the Internet once in a while? One solution would be if somehow a workstation computer could ask the gateway computer to send and receive data on it's behalf. The software which does the trick is called a proxy server. A well known example is WinGate. As far as the operating system is concerned, the proxy server is a normal TCP/IP application. A workstation computer sends a request to the gateway asking it to send data to the Internet. The data is sent using the gateway's IP address, and any response comes back the same way. Any number of computers on your LAN can use the connection in this way at the same time, as long as the data for separate requests is kept separate. The gateway computer can be a 'normal' PC with a standard Internet connection. There are several different way to do proxying: using the SOCKS protocol, socket relays and application proxies.The SOCKS protocol is defined by an official standard. TCP/IP applications have got to support SOCKS (in other words: must be SOCKSified) in order to connect to a SOCKS proxy server. Some do, but many of them do not. Some operatings systems, such as Warp 4, have special support in their TCP/IP stack so that non-SOCKS aware programs can be used with SOCKS servers.
    With socket relay (also known as "port mapping"), the proxy server mirrors ports from the remote machine on the Internet and makes them available as though it was providing the services. In this case, when a workstation on the internal network connects to for instance the SMTP port on the proxy server, the proxy server opens a matching socket on the connection to the Internet and then just ferries data between the two connections. Unlike SOCKS, a socket relay does not require any special support on behalf of the client program, so it can be used with most applications. The disadvantage of socket relays is that not all protocols can be handled. For instance, using the FTP protocol in non-passive mode is very problematical, and is not normally possible with a socket relay system.
    An application proxy is a special TCP/IP program that knows about a particular application protocol, and will accept requests using this protocol. A common example of this is the HTTP proxy provided by many internet server providers. This program accepts HTTP requests from clients using the HTTP protocol and converts them to requests to other HTTP servers. The resultant data is then copied back to the client computer. This approach has the advantage of allowing the proxy server to make use of its special knowledge about the application protocol in order to make the request more efficient. For example, most HTTP proxies will cache requests and can respond without requiring any further network access if the requested page is already in the cache.
    Back to top


    IP Masquerading (NAT)

    Some operating systems, most notably Linux, have the capability to perform IP routing with the addition of changing the IP address in the packets on the fly, i.e. as the data is passed through from the LAN to the Internet. When there is a mapping of multiple addresses on an internal LAN to one particular IP address of the gateway, this is called IP Masquerading. When the mapping is a bit broader (any IP address to any other IP address) the feature is called  Network Address Translation (NAT). NAT is a superset of IP Masquerading and is often used in firewalls for security reasons. Note that ISPA also has a feature called NAT (used for a different purpose).NAT is normally a feature of the TCP/IP stack. Many older TCP/IP stacks (Warp, Windows 95 etc.) don't support NAT, whereas newer operating systems (Linux, Windows 98SE and higher) do support it. The shareware DOS application IPRoute is another example. It comes with its own custom TCP/IP stack supporting NAT.
    Let's say in the following example that you use IPRoute for NAT. IPRoute changes the addresses in the packets it receives from the workstation machines into the address it is using itself. For example, 2 workstation machines can each run a webbrowser. IPRoute changes the addresses so the ISP thinks both webbrowsers are running on one and the same machine! There's nothing strange with that, it has always been possible to run multiple webbrowsers on one machine.
    Running servers (say, webservers) on multiple workstation machines is a bit less transparent. Most servers listen to a "well-known" port number. For a webserver this is port 80. But only 1 server can listen to a port at the same time. That means that the gateway machine can remap a port to only one workstation machine. So, if you want to run more than one webserver on your internal network which must all be reachable from the outside, there is a problem. Fortunately, there is also a solution. Let's say you have webservers on each port 80 of the workstation machines 192.168.0.2, 192.168.0.3 and 192.168.0.4. You can remap port 80 on the gateway machine to port 80 on 192.168.0.2, port 81 to port 80 on 192.168.0.3 and port 82 to port 80 on 192.168.0.4. People on the outside will have to specify URLs with "non-standard" ports for the last two workstation machines, say http://www.example.com:81/ and http://www.example.com:82/
    It works but it isn't very elegant...
Back to top


Routing vs proxy servers vs IP Masquerading

One of the major problems with using the SOCKS protocol is that it requires that clients be able to perform name lookups for external addresses, usually via DNS. This means that as well as implementing a SOCKs server, the proxy server must also provide a full DNS service to it's clients. Additionally, some protocols do not lend themselves to transport via SOCKs. The FTP protocol, in non-passive mode, can be particularly difficult. It is also possible to use a socket relay server without access to a DNS server, but this is not always the case.
If you have several workstation machines who all hit the same webpage at the same time, a caching proxy server may be provide better performance than a system with IP Masquerading. That is because the webpages can be served from the cache (local harddisk) instead of getting each of them over the modem/ ISDN link. On the other hand, a caching proxy may require a more powerful machine with a big harddisk, i.e. you will probably not get away with a lowly 286, as you can with IPRoute...

Back to top


Specific products (IPRoute, WinGate etc.)

This list is in no particular order.
  • IPRoute: DOS software which sports a TCP/IP stack with routing and IP Masquerading.
  • Due to licencing restrictions, the shareware version of IPRoute cannot be distributed from www.mischler.com anymore. You can still download it from this location though.
  • Windows 98 SE and higher come with "Internet Connection Sharing". In fact, Microsoft has bought Nevod and merged its NAT1000 product into Windows.
  • Commercial version of IPRoute/Secure, extended with firewall, accounting and Dynamic DNS support etc. etc.
  • FreeSco: a 1-floppy based version of Linux supporting IP Masquerading, dial-up server, print server etc.
  • Linux Router: a (discontinued) micro-distribution of Linux.
  • Share The Net: (also discontinued) a 1-floppy based version of Linux supporting IP Masquerading.
  • NAT32: Windows9x/NT/2K software with NAT. Excellent software, and the price is right. I use it myself. Configuration is partly through text files (Unix/Linux style) so it's certainly not something for everyone.
  • ISDNPM: OS/2 Dialer (replacement for IBM's "Dial Other Internet Providers") for internal ISDN cards (CAPI driver needed), which also supports IP Masquerading.
  • InJoy: OS/2 Dialer (replacement for IBM's "Dial Other Internet Providers") which also supports IP Masquerading.
  • Vicom: has software routers with and without IP Masquerading for the Mac.
  • IPNetRouter by Sustainable Networks is a configuration program for Open Transport (Mac) which you can use to configure network routing. Also supports NAT / IP Masqueradiing.
  • Webservers for OS/2 , including CERN HTTPD with proxy support (freeware).
  • Very small, but easy to use proxy server for OS/2: Tproxy.
  • IGATE, proxy server for OS/2, Windows 95 and Windows NT.
  • Freeware SOCKS5 (powerful) proxy server for OS/2, made by Philippe Gillain of IBM Belgium: SOCKD. You need to use SOCKS enabled software to be able to use it. But also your TCP/IP stack can be SOCKSified. For instance, Warp 4 (and Warp Connect, with an update) can be SOCKS4 clients. You need to specify the SOCKS server in the TCP/IP configuration settings. For Windows clients you need to download a SOCKS client. Ethan Hall-Beyer has written an excellent article in OS/2 E-Zine on how you can set up a Socks client.
  • WinGate: proxy server for Windows95/NT.
  • Winroute: IP Router, Network Address Translator, Packet Layer Firewall, Cache-Proxy Server (http, ftp, gopher), Mail Server, Scheduler for events such as dial-up connection and disconnection, internet mail processing etc. For Windows95/NT.
  • Sygate: Network Address Translator for Windows 95.
  • Nevod NAT1000: Network Address Translator for Windows 95/NT. (Nevod has been bought by Microsoft, NAT1000 product withdrawn from market. Incorporated into Windows 98SE and higher).
  • Open Sesame: proxy server for Windows95/NT.
  • Spaghetti: proxy server for Windows95/NT.
  • OpenH323: an Open Source proxy for NetMeeting and other H.323 based applications. (Commercial predecessors of OpenH323 were FireDoor and Phonepatch).
  • Netproxy: proxy server for Windows95/NT.
  • IPconnect: for Windows95/NT. Proxy? NAT?
  • WebEtc: proxy server and firewall for Windows95/NT.
  • FireSock: proxy/NAT? For Windows. By the makers of the Trumpet Winsock software.
See also TUCOWS for lots of other Win32 proxy servers.
Most Webservers as Apache, Netscape, Microsoft IIS or IBM ICS also provide (caching) proxy services.
Back to top


Understanding NAT

Both IPRoute and ISPA use the word 'NAT' (Network Address Translation) for more or less different purposes. I will try to explain the differences.
In ISPA, NAT is used for handling the dynamic IP address you get from your ISP. And it works like this. When ISPA gets the dynamic IP address from the ISP, there is no mechanism which allows the application running on top of ISPA (IPRoute, NCSA Telnet, etc.) to get that IP address! So ISPA uses a trick. In both the application and ISPA you specify the same dummy IP address (I use 145.220.128.13, but anything is allowed). You need to specify these in advance! This allows both to communicate with each other. Now, when ISPA dials out and receives the real dynamic IP address, it changes the address in that packet on the fly to the dummy IP address. This way, ISPA uses a dynamic IP address it gets from the ISP, while the application (IPRoute) thinks it has a static IP address!
IPRoute also has a NAT, but it's used for a different purpose. It allows multiple machines connected to a LAN access the Internet through only 1 IP address. This is what I earlier called IP Masquerading.
Back to top


Setting up IPRoute + ISPA

Here is a typical setup for IPRoute and ISPA, acting as an Internet router for the workstations.
           your gateway                           your workstations
 +----------------------------+
 |   IPRoute  (192.168.0.1)   |
 |       $50 shareware        |
 |   running DOS, 286+, 1 Mb+ |     
 +----------------------------+
        |                |
 +-------------+     +-----------------+                 +-------------+
 |  ISPA shim  |     | packet driver   |                 |  OS/2 Warp  |
 |  shareware  |     | e.g. for NE2000 |                 |(192.168.0.3)|
 |     $30     |     |   (freeware)    |                 +-------------+
 +-------------+     +-----------------+                     ||
        |                     |                              ||  and others 
 +----------------+  +-----------------+     +-------------+ ||  running Linux,
 | CAPI driver    |  |  network card   |     | Windows 9x  | ||  NT, Mac, etc.:
 | (supplied with |  |  (e.g. NE2000)  |     |(192.168.0.2)| ||  192.168.0.4,
 |  ISDN card)    |  +-----------------+     +-------------+ ||  192.168.0.5,
 +----------------+           ||              ||             ||  etc.
        |                #===============================================#
 +-------------+            Ethernet cable (coax or UTP with hub/switch)
 | ISDN card   |
 +-------------+
        |
   NT1 connector                                |
        |                                       |  The workstations think they
 ***********************************            |  are connected directly to
 * The Internet (through your ISP) *        <---+  the Internet...
 ***********************************
As you can see, I use the "dummy" Class C subnet 192.168.0.x for the local network with the workstations. This is a "private" block of addresses, especially reserved for exactly these kind of setups. These addresses are not intended to be used on the Internet (the IP Masquerading of IPRoute makes sure of that). See also RFC1918.
Here are the configuration scripts I am using for such a setup. Hopefully they are a good enough example. Of course you have to remove the comments at the right hand side of ISP.BAT. By the way, ISP stands for Internet Service Provider in the following.
ISP.BAT (located in root directory)
@echo off
\network\ne2000 0x61 10 0x300  <- Load packet driver for Ethernet card (in
cd \online-i                      this case an NE2000 on IRQ 10, port 300)
call starts0.bat               <- Load the CAPI driver for your ISDN card
cd \network\ispa                  (in this case a Teles S0/16.3)
ispap ? 0x60 isp.ini           <- If/when you have registered ISPA,
cd \network\iproute               replace '?' with your registration key!
ipr isp.ipr                       (with '?' it will only work for 15 minutes).
ISP.INI (located in \NETWORK\ISPA)
# call with ISPAP.EXE
#
# global options:
#-u                             # Uncomment if you want only one active channel 
-w                              # DOS activity display: on
-d                              # Disconnect on release: on
-m 145.220.128.13               # Dummy IP address for comm. with IPRoute
#
# because no IP-address is specified all packets (unicast and
# broadcast) are forwarded to the peer.
#
# for all other options the defaults are used
#
# REPLACE isphonenumber, myloginid, mypassword WITH YOUR INTERNET ACCOUNT INFO!
# Add -c for CHAP authorization, otherwise PAP is used.
# -p means: synchronous PPP over HDLC (which seems to be the 
#           most used protocol)
0.0.0.0  ispphonenumber -p -n myloginid,mypassword -o -r -t 240
ISP.IPR (located in \NETWORK\IPROUTE)
set log file out.txt
set log raw on
set log monitor on

; ISPA packet driver on 0x60. Use the dummy IP address for comm. with ISPA.
packet isdn0 0x60 145.220.128.13/24
; Route all packets to remote side of ISDN line (your ISP). The IP address
; used here doesn't seem to matter. You might just as well leave it this way.
route * isdn0 145.220.128.1

; Allow the following incoming connections
nat isdn0 tcp 192.168.0.2:80   145.220.128.13:80
nat isdn0 tcp 192.168.0.2:1376 145.220.128.13:1376
nat isdn0 tcp 192.168.0.2:21   145.220.128.13:21
nat isdn0 tcp 192.168.0.2:20   145.220.128.13:20
nat isdn0 udp 192.168.0.2:2213 145.220.128.13:2213

; Allow all outgoing connections
nat isdn0 *   *                145.220.128.13
;   Configure ethernet interface on network 192.168.0.0/2
packet en0 0x61 192.168.0.1/24
;   Broadcast RIP routes on the ethernet
;   Start a command interpreter on the console
command
exit
You can get packet drivers for Ethernet cards from this site. If your Ethernet card does not have a DOS packet driver, but only an ODI driver, you can download a shim ("interface") from Dan Lanciani's site.
Don't be alarmed if the software router stops running after about 15 minutes. That's ISPA's shareware limitation if you haven't registered it yet.
In ISP.IPR, you find several nat isdn0 lines. With this I tell IPRoute to route incoming sessions of port types 80 (WWW), 1376 (OS/2 Person-2-Person), 2213 (Kali games), and 20/21 (FTP) etc. to one particular machine (mine :-). However, Dave Mischler told me that you can route all incoming sessions (any port) to one machine (in my case 192.168.0.2) if you use the following line instead of the 5 tcp/udp NAT lines:
nat isdn0 * 192.168.0.2 145.220.128.13
So what I am doing is a bit of a hassle.
When you start the ISP.BAT batch file, make sure that both IPRoute and ISPA start with no warning messages. The first test is to ping a workstation machine on the Ethernet network using the PING command at the console prompt of IPRoute, for instance: PING 192.168.0.2 If the ping test fails, verify that the packet driver is installed correctly (IRQ, DMA, I/O port) and that IPRoute is able to see the packet driver for your Ethernet card.
Now ping a machine which is not located on your Ethernet LAN, a machine on the Internet, for instance PING 165.113.58.253 or use the IP address of the Domain Name Server your ISP told you to use. The modem/ISDN card will dial and establish a connection with your ISP.
On every workstation machine, you will have to specify the IP number of the Domain Name Server (DNS) of your ISP. If you have multiple IPSs, you can specify more DNSes. I'd love to have IPRoute perform some kind of DNS proxy service (so you can specify 192.168.0.1 as the DNS, which makes the workstation machines almost completely independent of the ISP used) but Dave says it's difficult to do (NAT32 supports it though). There might be a way to get around this and that is by installing your own DNS or DHCP server.
I haven't quite figured out how to use both ISDN B-channels at the same time, to get a bandwidth of 128 Kbps. However, I found the ADC Kentrox Pacesetter FAQ to be very informative on this subject.
Back to top


Notes on IPRoute

  • IPRoute does not seem to be sold anymore. The information below may be outdated.
  • I live in Europe and paid the $50 using an International Money Order (the Postbank, to be exact). Worked liked a charm. The advantage for Dave is that he didn't have to pay his bank any fees. For more information on this, download IPRoute and check the README.1ST. This is what Dave had to say about this:
  • To register, send a check or money order for $50 US by postal mail to:
    
    David F. Mischler
    245 McNair Road
    Buffalo, NY 14221
    USA
    
    For electronic fund transfers please use the following information:
    
    Bank Name:      Marine Midland Bank
    Branch:         Williamsville Office
    Address:        5556 Main Street
                    Williamsville, NY 14221
                    USA
    
    ABA Number:     021 001 088
    
    Account Name:   David F. Mischler
    Account Number: 716-69843-9
    
    Please ask that all fees associated with the transfer are paid in
    advance. I have received several partial payments due to deducted fees.
  • Do not use addresses which end with .0 or .255 for either the gateway machine or the workstation machines (example: 192.168.0.255) because these are reserved for administrative use. I use an address which ends in .1 for my IPRouter machine (192.168.0.1).
  • A user reported that when Windows 95 starts up it does some broadcasts which force IPRoute to dial out, possibly due to DNS or SMB traffic.
  • If you have an ISDN adapter which connects to your serial port (an ISDN TA) then you can do without ISPA. That's because as far as IPRoute is concerned it is hooked up to a normal modem which is controlled using AT command. In that case IPRoute's PPP implementation is used and not ISPA's. ISDN TA's such as the Motorola BitSurfr Pro and the ZyXel Omni TA128 are easier to use and operating system independent because they don't use any special drivers. However, they are also more expensive than ISDN plug-in cards for the ISA bus. TA's are more popular in the US than in Europe. The disadvantage is that you also need a high speed serial port such as the 16550 (not always available in old PCs) or even a Hayes ESP.
  • Another advantage is that all the administrative stuff, such as the PPP packetizing, the serial port handling (which costs interrupts!), the ISDN protocol handling (most people use a inexpensive passive ISDN card where the PC processor does all the work) etc. are done on the dedicated IPRoute machine. This means that this machine "offloads" lots of work from your main machine(s), so more processor speed remains for those machine(s) (games!). You could say that with a dedicated IPRoute machine you have a multiprocessor system :-). Daryl Banttari claims that the speed of Kali has gone up! 
  • I get many NAT translation error messages on the console. Perhaps the ISP's router is screwing up. They don't seem to have any effect though so I just ignore them. I don't even think this is a problem.
  • IPRoute completely takes over the DOS machine. You can't do much else with it, except use IPRoute's command interpreter. You can for instance use the command PING to test if a system can be reachable. You must use the numerical IP address, for instance 198.105.232.1 and not the symbolical name, e.g ftp.microsoft.com. Another interesting command is SHOW INT ISDN0 and SHOW INT EN0 (ISDN0 and EN0 are the defined interfaces, if you used my configuration files). These will give some statistics on these interfaces. ISPA also has an option -l x which shows statistics in intervals of x seconds.
  • You might not like the idea that a machine with IPRoute is not available for any other tasks, especially if that machine is fairly powerful (more than say a 486). If it's a 286, I'm sure you wouldn't give a fuzz. It is possible to run IPRoute in a DOS box under Windows 9x. Several people are running such a setup. I am not quite sure how it affects performance but I assume it's OK. I have also run ISPA and IPRoute on an OS/2 machine, it works, but I can't tell if it's slower. The network card is accessed through a packet driver so it isn't available to OS/2 for other applications at the same time.
  • Another advantage of using NAT (even for big companies) is that if you use dummy addresses such as 192.168.0.x you don't have to change all the addresses of the workstation machines when you switch to another ISP. Of course other settings (such as the DNS/mail/news/web/ftp servers) still have to be changed.
  • My user group happens to have more than one ISP. So if there is a problem with one ISP (bad connection, no more B-channels free, completely down, or thinks we forgot to pay the bill (happened one time and it was completely their fault)), we can switch to the other ISP. The "trick" is to specify both Domain Name Servers when you configure your Windows 95, OS/2, Linux etc. workstation machines. So if you switch ISP, there will be almost no disruption.
  • Once you get IPRoute up and running, you can even strip the system of "unneeded" hardware. Eric Johansson writes about this on his homepage:
    • The video and keyboard are really only required to get the router working. Once the system is running cleanly, if your bios permits, you can remove the keyboard and video to run the system in an embedded system mode.  Shopping in the used/surplus equipment market should give you one of these systems for well under $300.  Most companies using computers probably have one of these machines lying in a closet somewhere. A hard drive is actually a detriment to a router system because it increases the chances of the router failing because of heat or a hardware problem. The only time to use a hard drive in a router is when logging data locally is important and you expect a lot of data.
  • One thing you don't want is that IPRoute opens the connection for no apparent reason. Especially with ISDN this is very dangerous because the connection is made within a couple of seconds and generally you don't hear the modem (or whatever) dialling. You wouldn't be the first with a huge phone bill! For starters, Windows has a bad habit of querying the DNS when the TCP/IP entry has been added to the Network configuration setup. A solution would be to disable the binding of "Microsoft Client" to TCP/IP on each and every Windows 95 machine. But this is error prone, once you forget just a single machine, you're in trouble. An easier solution would be to block these particular DNS requests in IPRoute:
  • filter sl0 drop out udp *:137 *:53
    filter sl0 permit out * * *
    filter en0 permit in * * *
    See also the IPRoute script I use with modems. This has the disadvantage that you cannot do name lookups of SMB/CIFS servers located on the Internet. There are actually very few of these (they are considered a security risk), so that may not be much of a problem. Probably the best solution would be to run your own (caching) DNS on your LAN. Only genuine DNS requests will cause IPRoute to dial out then.A problem with Warp Connect and Warp 4 is that Sendmail also causes IPRoute to dial out once in a while. You can fix this by killing the Sendmail process and use another mailer (Netscape Mail, Postroad etc.), or remove Sendmail completely from the startup .CMD file. I don't know if installing your own DNS helps in this case.
Back to top


IPRoute tricks

  • IPRoute can be run in a DOS box under Windows 95. In this case a dedicated DOS machine for running IPRoute is not needed. The trick is to use the NDIS3PKT "shim". This is a driver which makes the Windows 95 driver for your network card also available as a packet driver interface. IPRoute can only deal with packet drivers. You could run a DOS packet driver in a Win95 DOS box, but then it completely takes over the network card. With NDIS3PKT the network card is available for other tasks as well. Tom Hayes invented this trick. He writes:
  • The only pitfall we've come across so far is that the dos box must have focus in order to dial out again after the connection has been dropped due to idleness. I wrote a small Visual C++ program to periodically give the IPRoute dos box focus. This avoids the dial out problem altogether.
    At the same time, you could install a DNS and/or DHCP server on that Windows 95 machine running IPRoute.
  • Another trick by Tom: if the IPRoute machine is located on a site, and you are elsewhere, you can remotely access the IPRoute machine using FTP and/or Telnet. Quite handy if you need to tinker with the IPRoute scripts or configuration.
  • nat sl0 tcp 192.168.0.1:21 145.220.128.13:2021
    nat sl0 tcp 192.168.0.1:23 145.220.128.13:2023
    145.220.128.13 is the "dummy" IP address mentioned above. If your ISP has given you a static IP address, use that one instead. The ports 2021 and 2023 are the "secret" ports you FTP and Telnet into. You may alter these of course. Most telnet and ftp clients allow you to specify these non-standard (custom) ports. But be warned, use logon scripts with usernames and passwords or else anyone can have access. Also note that FTP and Telnet transmit passwords in clear text. That does not mean that any bozo can read them, but sysadmins of your ISP and Internet long distance carriers might...
  • It might be an idea to download PLIP (not successfully tested by me). This is a DOS packet driver for a network connection using the parallel port. You use a "LapLink" style cable to connect another machine to it, for instance, one which does not have a regular network card. But you could also use it as an "administrator port", which you use to configure the IPRoute machine should you have stripped it of non-essential parts such as a keyboard, a monitor etc. (Of course, you could FTP and Telnet to the IPRoute machine over the network, but these protocols transmit their passwords in clear text so anyone with a network sniffer could grab your passwords. With a machine connected to the IPRouter's parallel port, there's no such chance).
  • Other (faster) cables can also be used but these require faster parallel ports, EPP or ECP. Download PARA14.ZIP for an excellent tool which allows you to determine what parallel port you have (believe me, this one is better than CheckIt or MSD). The docs also discuss the standards which exist for parallel ports.
  • The below does not seem to work! It hangs Windows 95 after a while!
  • It should be possible to hook up a DOS machine via the parallel port to a Windows 95 machine which has a connection to the Internet or whatever. Run PLIP.COM and WINPKT.COM from the AUTOEXEC.BAT, use NDIS3PKT so that IPRoute has access to the network card, run IPRoute in a Windows 95 DOS box. Create config file for IPRoute with entries for both packet drivers and let it route from the parallel port to the network card.
    PLIP + PDETHER + ODIHLP does not seem to work! PIPX + ODIHLP might work, but it has a time limit and a nag screen and you'll have to pay to get rid of these.
Back to top


Notes on ISPA

  • I live in Europe and paid the DEM 70 (EUR 35) using a bank transfer from the the Dutch Postbank to Herbert's account at the Postbank München (not related to the Dutch one!). Worked liked a charm. The advantage was that for both of us we didn't have to pay provisions to our banks.
  • In most cases, you will want the IPRoute machine to dial out when there is traffic from one of the connected workstation machines (demand dialing), and that it disconnects if there hasn't been traffic for a specified amount of time. The dialing out is standard in ISPA but the automatic hanging up has to specifically configured with the "max-idle" option -m xxx where xxx is a time in seconds. With ISDN it costs money to set up a connection so you don't want to specify "max-idle" too low because it will keep disconnecting and reconnecting (which costs money). But you also don't want to specify "max-idle" too high because then it will keep the connection open (which costs money) while there is in fact no traffic. For the Netherlands I'd recommend a "max-idle" time in the range of 180 and 240 seconds.
  • You don't hear a dial tone with ISDN, and there are no status lights. So, especially if you don't specify a "max-idle" setting, watch out that the line ISDN doesn't open all time! Otherwise you'll be confronted with an unpleasant surprise next time the phone bill comes in...
  • If your ISP uses a Cisco router, it may occur that it sends RIP packets in intervals of 10 seconds. The ISP wants to 'help' you by sending these "keep alive packets" and keep the connection up if you are sending no traffic. Nice if you live in the US where local calls are free, not nice if you live in Europe where many ISPs are in hands of the old national phone companies... ISPA's option -r makes sure that these keep alive packets are ignored. That is, they do not count as "real" traffic so they won't keep open the connection if there is no traffic.
  • With the -m xxx option ISPA can fire up the second 64 Kbps B-channel if the workload generated by the workstation machines is higher than 6000 bytes per seconds for more than xxx seconds in a row. The problem (at least in the Netherlands; in the US it's not much of a problem) is that not every ISP don't supports it. And if they support it, but they want to be paid extra.
  • ISPA supports many ISDN protocols. I found the documentation a bit confusing though. Let's say your ISP says they support PPP. You need to get more information than that because ISPA supports several variants. It has the following options to choose from (odd protocols have not been included):
    • -p sync PPP over HDLC (the normal case, used by Windows as well).
    • -l2 async PPP over X.75
    • -e2 async PPP over X.75/T.70NL
    • -b async PPP over V.110
    You can choose only one option of these, they are mutually exclusive. For each of the options you can/must use -n to specify the PPP options such as login ID and password, and also -c if you need CHAP instead of PAP (the default) for PPP authorization. Sync PPP over HDLC is by far the most popular protocol. It's also the default for most Windows systems, so try -p first.
  • Always use the latest versions of the ISDN CAPI drivers, ISPA and IPRoute. I have tested ISPA sucessfully with the following ISDN cards:
    • AVM B1: tested with both the CAPI 1.1 driver and the CAPI 2.0 driver (using CIPA, the CAPI 2.0 counterpart of ISPA)
    • Teles S0/16.3: comes only with a CAPI 1.1 driver, so only ISPA will work and not CIPA. 
    • Cisco 200: I had many problems with this card and the CAPI 2.0 driver that came with it. A machine with the Cisco + the CAPI 2.0 driver + CIPA + IPRoute crashes unpredictably, sometimes after 2 hours, sometimes after 2 minutes. After a lot of experimentation and scrupulously ruling out other causes I came to the conclusion that the CAPI 2.0 driver must have been buggy. The Cisco 200 is in fact an ITK ix1-micro . New drivers can be found on their website. The DOS CAPI 2.0 driver still seems to crash but I have one report from Wolfgang Bröker who writes that he had no problem with the card. He has a newer version of the card though, perhaps that's the difference.
  • There aren't that many (freeware) TCP/IP applications for DOS because there isn't really a standard for a DOS TCP/IP interface. Most DOS applications more or less come with their own built-in TCP/IP stack and access the network card driver directly. So, what if you can't get IPRoute and ISPA working and you don't know which one of the two needs some tweaking? You might want to try another DOS app than IPRoute, just for the sake of testing. I used NCSA Telnet for that purpose. You can configure a static IP address in NCSA Telnet, or let it use ISPA's BOOTP support.
  • CAPI standard site
  • CAPI 2.0 is a newer standard than CAPI 1.1. DOS and OS/2 applications (mostly communications software) generally require CAPI 1.1 while Windows drivers are often CAPI 2.0. I don't think it matters which one you have because both seem to work fine (for developers it may be a different question). However, as you can see from my buggy ITK driver story, you might probably want to register ISPA (for CAPI 1.1) instead of CIPA (for CAPI 2.0) if you want to use IPRoute.
  • There's a special version of ISPA which allows you to use 8 ISDN B-channels. Too bad that most ISPs only allow dialling in with 1 B-channel. 
  • ISPA/CIPA support the standard in bundling B-channels: Multi-link PPP. Previously it didn't work.
    (Old: I received a report from Herman Bos that it is possible to use both B-channels with the Teles card if your ISP allows you to login twice under the same accountname. I am unsure if you have to run the Teles BUNDLE command before you load ISPA. But you will have to specify -m 8,180 (2nd channel open after 8 seconds of maximum load, down after 180 seconds of low load; or change this to your likings). So far, I receive one report that this works with the Dutch provider XS4ALL. But there are some drawbacks: you'll need a static IP address (which normally costs you extra), plus you must be so lucky that the second B-channel also connects at your ISP to exactly the same ISDN router as the first B-channel! There might also be alternative ways to get ISPA/IPRoute working with both B-channels, but these may require using of proprietary bundling protocols (e.g. Teles' BUNDLE), which may or may not be supported by your ISP).
  • One of the peculiar things of ISDN is that it's difficult to figure out what's going on on the ISDN line. If you use one of Herbert Hanewinkel's Windows drivers you can use the included ISDNMON Windows program. But with IPRoute + ISPA you're dealing with DOS and DOS is essentially single-tasking. Fortunately, the Graz University of Technology, Austria, has developed a freeware ISDN monitor, but unfortunately I cannot find it anymore on their site. You load it in between ISPA and IPRoute. It shows the internals of the packets sent over the B-channel(s). I haven't tried it yet so I can't tell how much the performance impact on the system will be. The software is in German.
  • If you specify the option -w, ISPA monitors the status of the ISDN line in the top right hand corner, including the average load in Kbps received and sent in the last 8 seconds. This feature does not interfere with the IPRoute console screen.
Back to top


Alternatives for ISPA

There is a freeware "CAPI-to-packet driver" available, called PAPI. But this one has much less functionality. And it has not been updated for a couple of years), for instance it doesn't support PPP so it will probably not be much use to you if you want to dial up to an ISP. It may work if you want to hook up two LANs of your own through ISDN, because what I understand from it PAPI's main use is to send whole Ethernet packets. I haven't quite figured out how they implement security (you don't want everyone to dial in to your Ethernet, do you? :-), perhaps with ISDN's Caller Identification...
cFos (older verions also here) is a piece of software that emulates a serial modem (with AT commands and all) using the CAPI driver of your ISDN card. It might be possible to use cFos and IPRoute together, but I have no idea if it works. In that case, you will be using IPRoute's PPP implementation. With the ISPA + IPRoute combination I described earlier, ISPA's PPP implementation is used. A disadvantage of cFos might be that it is less efficient than ISPA (cFos emulates a modem, and modems work with one character at a time, while ISPA emulates a network card, and network cards work with packets), but I'm not sure. The advantage of cFos over ISPA is that cFos can be used for other communication programs too.
Back to top


Notes on IPRoute + ISPA

  • It is difficult to say how many users can be handled by a machine running IPRoute + ISPA. At one time I had 15 users hooked up in an Ethernet, with 10 users connected to the Internet (at least, that's what SHOW ARP on the IPRoute console told me). At that time people started to complain about the speed. When people start complaining I ask them to connect to the website of the service provider because when those webpages load in quickly, the lack of speed was probably caused by the Internet and not the ISDN line. I think 1 B-channel should be enough to support about 5 moderately active users, who surf the web, sometimes FTP stuff etc. The machine which is IPRoute + ISPA should not be the bottleneck, because I asked Dave Mischler the following:
  • > - What's the minimum machine needed for routing from 5-10 machines
    >   to an ISDN line?
    
    I don't know.  A 16 MHz 286 might be enough.  A 33 MHz 386 is almost
    certainly enough (unless the card and driver combincation is very bad).
  • When I had the 15 users connected to the Ethernet, a couple of machines running Windows95 could NOT ping the gateway machine (192.168.0.1). But they did show up in IPRoute's ARP table.
  • ISPA's PPP implementation is used and not IPRoute's. As far as IPRoute is concerned, it routes packets from one Ethernet driver (a real Ethernet, namely your LAN) to another (a fake Ethernet, namely the ISDN card).
  • If you want to force IPRoute + ISPA to dial out (normally they start up without making a connection), just PING a machine on the Internet using the IPRoute console. But although ISDN connections are set up very quickly (4 seconds or so), the ping times out before the connection is up. No worries, just repeat the PING command.
  • Security was not a concern to me so far, because my user group only wants to make use of the Internet connection 2 times per months for about 8 hours in total. Besides, we're not running any servers. I have not used any filters so I probably can't help you with that...
Back to top


Which applications will/won't work?

Most apps will work fine with IPRoute, without having to configure proxies. However, the workstation machines will have to have private ("dummy") addresses (e.g. 192.168.0.x). The problem is that if an application asks the machine it is running on what its IP address is, it gets the dummy address. When this address is sent to a remote side (say, for Internet telephony), that machine gets confused because the packets it sends may not get back to you because of the fake address. Certain applications transfer IP addresses or port numbers as part of their data. This requires special treatment for address translation (packets must be examined and addresses changed on the fly). So, if an apps doesn't work, this could be the problem.
Most of the applications and their settings mentioned on the Linux Masq Apps page will work for IPRoute as well. You'll need to "translate" the ipfwadm/ipchains/iptables lines into corresponding IPRoute NAT lines, of course.
If you switch over from WinGate to IPRoute, make sure that you turn off the proxy settings in your apps.
Here's a list of TCP/IP applications which are known to work with IPRoute or WinGate, or not, or I just don't know because I haven't tried. More recent information on which apps are supported by WinGate can be found on the WinGate homepage.
If you have any additions/updates to this list, please mail me!
  • Netscape/Internet Explorer (or any other Webbrowser): Works with both. For WinGate you will have to specify WinGate as the proxy server. If you use IPRoute no additional configuration is required.
  • FTP clients: work with both. For WinGate you will have to specify the host in a complicated way, with the WinGate machine as a proxy. If you use IPRoute no such hassle is required.
  • FTP servers (such as Trumpet, Penguin, NeoLogic FTPD etc.): work with IPRoute but incoming ports 20 and 21 have to be configured with NAT.
  • HTTP servers (such as GoServe and NCSA HTTPD): work with IPRoute but incoming port 80 has to be configured with NAT.
  • Telnet: works with both. For WinGate you will have to Telnet first to the WinGate machine, then you get a new Telnet prompt from which you login to your actual destination. If you use IPRoute no such hassle is required.
  • SSH client: you might need to specify -P to force the client to use a "non-privileged" port. For scp, the SSH secure copy, the equivalent switch is -L.
  • News/mail clients (such as Free Agent, UltiMail/2, Netscape Mail etc.): all these should work without problems.
  • Gopher clients: haven't tried / unknown, but should work without problems since they are the predecessors of web clients.
  • IRC: Will probably work with IPRoute, but DCC send might be problematic (haven't tried yet). IPRoute docs say that it has support for IDENTD. PMIRC (OS/2) works fine on one machine, haven't tried with more machines on the same network. mIRC is also reported to work fine. Haven't tried / unknown with WinGate.
  • PING: works with IPRoute. Doesn't work with WinGate.
  • SMB/CIFS/NBT ("Windows networking"): transfers IP address or port number in data. Makes it difficult for NAT. Unknown whether it is supported by WinGate or IPRoute.
  • Traceroute (TRACERTE.EXE): at least the Windows versions (which work differently than Unix and OS/2 versions) work with IPRoute, though I noticed it may take a couple of seconds before it can get through the IPRoute machine. I also often see some duplicate lines with '192.168.0.1 * *' or so. Traceroute doesn't work with WinGate, last time I checked. Traceroute does work with NAT32, but if you use the Linux traceroute you need to specify -I in order to use ICMP ECHO instead of UDP datagrams.
  • VDOLive: haven't tried / unknown.
  • IPhone: I haven't tried it myself with IPRoute but one user on my LAN got it to work. He's certainly not a 'power user' so I guess it was quite easy to do :-). Status with WinGate: unknown.
  • InterCom by ixWorld (OS/2). Audio (voice), video (QuickCam) and Talk (text) all work with IPRoute. You can call somebody else, but if you want to be called you must enter a NAT command in IPRoute for the port InterCom is using (haven't determined which one). I route all incoming connections to one machine which always works. Unknown with WinGate.
  • WinChat: works with IPRoute, but incoming port 2048 has to be configured with NAT. Other chat programs such as iChat and Microsoft Comic Chat: haven't tried / unknown.
  • Alphaworld (is this the same as Worlds Chat?): a guy at my users group used it while IPRoute was running, so I guess it works. With WinGate: haven't tried / unknown.
  • Shockwave: haven't tried / unknown.
  • VRML: haven't tried / unknown.
  • StreamWorks: haven't tried / unknown.
  • RealAudio: will work with WinGate 2.0+. Reported to work fine with IPRoute too. Blair Hicks wrote to me that he got Real Player V 4.01 to work by opening its Preferences, clicking on Transport and then enable the "use specific UDP Port" checkbox. On the IProute gateway he then added a TCP and UDP mapping, i.e. a NAT line, to the workstation running the RealAudio player. You should be able to get more players running on multiple workstations by incrementing the port numbers. For instance: port 7070 is mapped to and used by workstation #1, port 7071 is mapped to and used by workstation #2 etc. RealAudio 5.0 confirmed to work in a similar way by Richard Spooner.
  • Shockwave: haven't tried / unknown.
  • Talk: there seems to be no "standard" for talk so it may depend. But: haven't tried / unknown.
  • CUSeeme: haven't tried / unknown.
  • CoolTalk: haven't tried / unknown.
  • Microsoft NetMeeting / H.323: transfers IP address or port number in data. People have tried very, very hard to get this working with any proxy server or NAT product on the market. Not even Microsoft's own Proxy Server 2.0 will allow you to hook up multiple NetMeeting users through one shared TCP/IP connection! With most Internet sharing products, NetMeeting's whiteboard and the text based conversation window will work fine, but audio and video will NOT work.Open H.323 can be used as a proxy.
  • Person-2-Person (whiteboard sharing application included with OS/2 Warp BonusPak): it has been a couple of months back since I tried but I think it works with IPRoute.
  • Kali (converter which allows you to play IPX-based network games such as Duke3D, Quake and Descent over the Internet): with IPRoute only tested Kali for OS/2 so far. Seems to work but you will have to specify my_ip in KALI.CFG with the real IP address that gateway machine gets from your ISP. Kali does most of its communication on UDP ports 2213 and 6666 so you will have to NAT these on the IPRoute machine to the machine you're playing Kali on. Kali proxy (kproxy.exe, see Kali homepage) may be useful.
  • Vxtreme: transfers IP address or port number in data. Makes it difficult for NAT. Unknown whether it is supported by WinGate or IPRoute.
  • Quake (running under DOS B&W TCP/IP stack or Windows95 TCP/IP, not Kali) and other games over TCP/IP: haven't tried / unknown.
  • Set up a PPP connection with IPRoute to Unix account with SLiRP, a PPP emulator: haven't tried / unknown.
Back to top


Alternatives for IPRoute + ISPA

Of course, if you have the money you can always buy hardware such as an 3COM OfficeConnect ISDN LAN Modem, Ascend Pipeline or an ADC Kentrox Pacesetter. For instance, Bill Luttonwrites:
I have a setup that I just put together for evaluation that seems
to work pretty well for me, here is the recipe:
 - old 486/66 w/8MB & 130MB  (overkill) ($0 personal surplus)
 - a TC200-S6 460K serial card ($29 from www.byterunner.com)
 - an NE2000 LAN card ($30 from datacomm warehouse)
 - a Zyxel 2864iu external TA ($?)
 - IPRoute router software ($50 from this site)
This system does "dial on demand" and call dropping after a configuable
amount of time for my 3 PC network. The Zyxel TA does utilization sensitive
adding/dropping of the 2nd B channel.  Total time to bring up the link (call
establishment & ppp negotiation) is ~2.5 sec.  FTP downloads run at 15200+
KBytes/sec.  Ping times are about 40ms. I've only been running it for a few
days but it already compares very favorably to my ~$1000 Ascend P75. The P75
connects in ~2.0 sec and is configuable over the LAN, but doesn't do NAT.
The advantages of special hardware over IPRoute + ISPA are:
  • They can do more protocols, such as IPX (ISPA should be able to handle more protocols, but IPRoute, as the name implies, only does IP).
  • Some can do compression, e.g. using Stac or V.42bis or whatever.
  • Some can do Multi-link PPP, BACP, or "bonding" of the two ISDN B-channels, i.e. on a bit-level which is better for applications such as video and audio.
  • Some can be configured from a remote location (using Telnet, SNMP, a terminal hooked up to a serial port etc.)
If you are running OS/2, there's also InJoy. It is a replacement for the "Dial Other Internet Providers" program supplied with Warp. InJoy supports IP Masquerading, at the moment for 4 users but more than 4 are also possible (at a higher price). In combination with cFos (see paragraph above), you can also run InJoy over an ISDN line. Click here for information on that, including examples. InJoy also does Dial on Demand.
The advantage of InJoy + cFos over IPRoute + ISPA is that you don't need to sacrifice a dedicated machine. It is probably easier to configure too. The disadvantage is that it is higher in price. Also don't forget that the unregistered cFos doesn't support sync PPP over HDLC, which makes it impossible to test InJoy + cFos with most Internet providers.

from http://www.jacco2.dds.nl/isdn/ipr_ispa.html