An IP Masquerading Linux Gateway Machine for our Law Office

by,
J. William Snyder, Jr.

Although the Internet has been around since the early 1970s, it has taken until the middle of this decade for it to develop to the point to be useful to the legal profession. I first started using the Internet in 1991, and I remained active on the Internet all the way through law school. Even after I graduated from law school and secured employment with a small law firm in Wilmington, I worked out a way to access the Internet from my office. Slowly but surely, the number and quality of resources on the Internet that would be of interest and use to members of the legal profession increased as time past. By November 1996, The Internet featured a number of resources that were useful not only to myself but to the other attorneys in the office as well as our legal assistants and paralegals. In particular, the North Carolina Department of State had made its corporations database available for searching on the Web, which is extremely useful for us when we need to sue a corporation and much quicker than waiting on hold while calling the Department of State. Additionally, the availability of online phone books provided another tool for tracking down defendants who we have had difficulty locating. The availability of the NOSSCR bulletin board (now SSAS Connect) on the Web presented us with an excellent opportunity to confer with other Social Security attorneys and advocates nationwide. Now that the Web was useful to persons in our office other than myself, I proposed to our firm's managing partner that I add Internet connectivity to our office's network, and she enthusiastically endorsed my proposal.

Having decided to add Internet connectivity to our office, the next step was to decide how to accomplish the task. Our office workstations are networked together over a 10Mbit Ethernet, and our satellite office in Williamston is connected to our Ethernet over a 56 KB leased line. At the time, we were running Novell NetWare Version 3.12 on our two servers in Wilmington and Williamston. At that time, was the only person in the office who was able to access the Internet. I was able to dial into my personal ISP account from a modem that we had connected to my workstation for remote access. Two of the other attorneys in the office had working modems on their workstations, but it was not possible to set up any additional lines for modems in our office due to limitations of our phone system. Our computer consultant proposed a modem server, but one of my goals was to allow people in the office to avoid the hassle of having to bring up a dialup window and log into the ISP every time they wanted to access the Internet. Furthermore, because our ISP disallows multiple simultaneous logins under the same account, a modem server would only allow only one user at any given time to access the internet. Additionally, I wanted to provide our office with an email server as well, which we could not do easily with a modem server.

I've been an avid Linux user since 1995 when I first installed Slackware 2.0.0, so I got the idea that Linux might be the solution to our problem. I had read in the Linux Journal about a technique called IP Masquerading (Kostick, Chris, "IP Masquerading with Linux", Linux Journal 27:15 (July 1996)), which allows multiple clients on an IP network to appear to the Internet as if they are coming from the same IP address. Sometime in the past I had played with a program called Diald, which will dial up and establish a PPP link on demand and take down the link when it is not in use. In the past, I was also active in using TCP/IP over Amateur Packet Radio, which gave me a good grounding in IP networks and protocols. I downloaded and read the IP-Masquerading mini-HOWTO and decided that the it would be possible for me to set up a dedicated Linux machine that would employ IP Masquerading and Diald to give users on our network on-demand dialup access to the Internet. We had recently retired some older workstations from service, which provided me with some parts from which to put together a Linux gateway machine, notably some 30-pin SIMMs, a case, a TTL monochrome card, and a monochrome monitor. With a modest investment in some additional hardware, notably a motherboard with a faster processor than the 386s we had recently retired, a larger hard drive, and a newer I/O board, I knew I would be able to build the Linux gateway I envisioned for our office. I proposed the idea to the boss, and she approved the idea and gave me a $300 budget to buy the parts I needed.

The next stop was a computer show in December. 1996 in Raleigh, North Carolina to procure the parts needed for the project. One of the items on my shopping list was a hard drive. I originally had wanted to buy a hard drive that was around 200 MB, but none were to be found. I had to settle for an 850 MB drive, the smallest I could find. Shortly after Christmas, I commenced construction of our gateway machine. I procured one of the old 386 klunkers we had recently retired and stripped it clean. I then proceeded to install a 486DX2 motherboard, which my stepfather gave me after I upgraded his computer's motherboard, along with a EIDE I/O card with 16C550 UARTs, the 850 MB hard drive, a dual 5.25"/3.5" floppy drive I purchased at the Raleigh computer show, a TTL monochrome card so I could use one of the old monochrome monitors in the office, 8 MB of RAM (8 1x9 SIMMs from two old klunkers), and an NE2000 clone (Accton) 10baseT Ethernet card. I liberated a 28.8kb modem from one of our attorneys who was not using it for use with the gateway machine.

Once I got the machine built and running, the next task was to install Linux. I already had Linux installed on my workstation, which has a CD-ROM drive, so I decided to install via NFS using our network. I had installed Linux using both Slackware and RedHat in the past, but I chose to go with Slackware for this installation because of the control I would have over which packages would be installed. After some initial trouble with getting the boot disk to see the Ethernet card, a problem I ended up having to remedy by building a new kernel and custom boot disk, I successfully installed Linux on our gateway machine.

The next step was to apply the IP masquerading patches to the kernel and to compile a custom kernel capable of IP masquerading. At the time, each of the bumper patches that were required for use of protocols that needed some additional help to co-exist with a masquerading firewall had to be downloaded and applied separately. Fortunately, the patches are now included with the kernel source starting with the release of kernel version 2.0.30, making the job of compiling an IP masquerading- enabled kernel much easier. Currently, information on enabling IP masquerading on a Linux machine can be found on the Linux IP Masquerading Web Page I also had to download and install ipfwadm, the program used to manage the forwarding and masquerading rules for the kernel, and Diald (version 0.16.0 at the time) to dial up and take down the PPP link to our ISP. I decided that we would use the Class C 192.168.x.x block of IP addresses, which have been set aside for private IP networks, to build our local IP network. In accordance with RFC 1918, I assigned 192.168.1.1 to the gateway machine. I assigned 192.168.1.2 to my personal workstation, and I used 192.168.0.1 and 192.168.0.2 for the ends of the pseudo-SLIP interface required by Diald in order to trigger the dialup link. I followed the instructions in the IP-Masquerading mini-HOWTO to build the forwarding rules table with ipfwadm, and although I discovered that the syntax for the command as used in that earlier version of the mini-HOWTO was slightly dated, I was able to build the forwarding table successfully to allow IP frames from our local network to be masked but to not to mask frames coming from elsewhere. Other than a battle with a bug in Diald that caused it not to redial, a bug which was corrected with the 0.16.1 patch, the configuration and initial testing of the server went well.

With all of the necessary server side components installed and functioning properly, I began testing the server from the client end. I used my personal workstation under Linux to perform the initial testing with good results. The gateway dialed up the PPP link on demand and masked frames from my workstation correctly. As intended, Diald took the PPP link down after several minutes of disuse.

The next step was to install and configure TCP/IP stacks on the workstations in the office. At the time, most of our workstations were using Microsoft Windows for Workgroups 3.11 and Novell's VLM client to access our Novell 3.12 server. I initially tried Microsoft's Wolverine TCP/IP stack (both the 16 bit and 32 bit versions), but that required that we use Microsoft's Netware client to access our Novell 3.12 server since it was not possible to run the VLM client and the Microsoft's TCP/IP stack simultaneously. Unfortunately, Microsoft's Netware client resulted in incompatabilities with our mission-critical applications and unacceptable performance degredations on the workstations, so I had to find another solution. After some extensive searching, I found that Novell had an add-on TCP/IP stack for use with the VLM client. I downloaded it along with the latest VLM client and installed them on the workstations of users needing Internet access. The installation and configuration went smoothly, and the incompatability problems we had with the Microsoft TCP/IP stack did not exist with the Novell add-on stack. During this process, I assigned IP addresses to the workstations of users needing Internet access (legal staff and one of our legal assistants), and because our Novell 3.12 server did not have the NLM to do IP routing loaded, I had to connect all Internet users in the office to the same Ethernet segment, which involved moving some cable connections around on our 10BaseT hubs. I also installed Netscape Navigator 3.01 and the Eudora Lite mail client on the workstations. We also subscribe to WESTLAW, West Group's online legal research service, which we had been accessing by dialing into local access numbers. WESTLAW can also be accessed over the Internet, so I configured the WESTLAW retrieval programs on all of the machines to access WESTLAW using Windows Sockets. Now, all of the legal staff has access to WESTLAW from their workstations, whereas previously they users needing to use WESTLAW had to use the one workstation in the office with dialout capabilities.

At this time, the gateway machine was sitting in my office connected to the second 10BaseT in my office with the modem cable stretched across my desk. Once the initial tests were finished, I moved the gateway machine into our library where there was a 10BaseT cable and a phone line into our phone system. A call to our phone system consultant got the line activated for the modem, and the gateway machine was fully operational.

When I first configured the workstations, I gave them each a host file in order to avoid needing to run named on the gateway machine. However, I subsequently decided to start running named on the gateway because of an increase in the number of users needing Internet access and the commensurate increase in the number of IP addresses on the network. When I first set up named, I configured it to forward requests for addresses off of our network to our ISP's nameserver. However, by default, diald is configured to ignore inter-nameserver traffic, which prevented diald from bringing up the link when there was a query for an off-site address. I reconfigured diald not to ignore such requests when deciding whether to bring up the PPP link, but then the line was being brought up for named chatter and even when there was a request for a local address. I eventually reconfigured diald not to forward requests to our ISP's nameserver, and I configured the workstations to query the gateway machine for domain names followed by the ISP's primary and secondary nameservers. I have since figured out how to configure named and diald to forward requests for addresses not in our domain to our ISP's nameserver and also not to bring up the dialup link for needless nam ed chatter, and so now I have all the workstations send DNS inquiries only to the local named running on our gateway machine.

Since Slackware 3.0.0 came with the Apache http server, I decided to use it to build our own private website with a homepage containing links we were likely to use frequently. The first version of this page included links to, among other things, the Secretary of State's corporate database, useful for us when we need to sue a corporation and we need the name of the registered agent, Yahoo's page with links to the major Internet phone books, which are useful when we want to track down someone to serve a summons and complaint, the North Carolina Industrial Commission's home page, which has a searchable database of opinions of the full Commission, and Internet Grateful Med, a user-friendly front end to search the MEDLINE medical periodical database. I configured the http server not to respond to hits from machines not on our local network, so I was able to put our passwords to access fee-based services directly on the page. I update the page from time to time with URLs I believe are of interest to our practice, many of which are communicated to me by my colleagues in the office.

A couple of months after I got the web server up and running, I saw an article in the March 4, 1997 issue of PC Magazine on programming CGI in C (PC Tech/Power Programming - Programming CGI in C, by Zan Oliphant). I had been trying to several months to learn C and C++ in conjunction with writing a program to perform a calculation we commonly have to make in the office. The calculation we have to make is the amount of offset of an injured workers' Social Security Disability Benefits for receipt of workers' compensation benefits. When I joined our law firm, the calculation was done using a worksheet designed for the purpose. I wrote a character-based C++ program that performed this calculation, which we used for several months. However, my boss wanted the ability to make changes to the data entries and rerun the program without having to re-enter all of the data. She also suggested that I make the output more readable. The boss's suggested modifications, the availability of a local web server, and Oliphant's article inspired me to rewrite my offset calculation program to make it CGI-compliant. I found a C++ class library which made it a snap to extract data from a CGI form. In a few days I had rewritten the program to extract the variables from a CGI form, perform the calculation, and return the results of the calcuation in a readable format. By making the program CGI-based, it also added the ability for the users to make changes in the input variables simply by hitting the Back button on the web browser, making the changes, and resubmitting the form. Since installing the CGI version of my offset calculation program I have written and added other CGI programs which perform other useful calculations needed in connection with our law practice.

Over the course of 1997, I added additional functionality to our Linux server. In order to help me learn more about Novell servers and networking and also to make the private "anonymous" FTP collection I have amassed available to workstations in our office that were not IP enabled, I installed MARS_NWE, a package that emulates a Novell 3.12 server on a Linux machine. Now, from any machine on our network I can access our FTP collection simply by attaching to the MARS_NWE server. I also downloaded and installed a DHCP server to make my job of assigning IP addresses easier. I've added a 56K x2 modem to accomodate our ever increasing need for Internet bandwidth. As our need grows, I suspect we may need to consider dedicated access and/or ISDN, both of which will be easy to accomodate with our Linux gateway.

Internet access has also increased substantially our ability to interact with other law fims, in particular firms who frequently represent our opponents in litigation. We are able to use Internet email to electronically exchange word processing documents that require modification and editing by opposing counsel, such as settlement agreements and discovery requests. At the time I set up our gateway, I believed that our firm was on the cutting edge of Internet connectivity among the law firms in our city. Since then, other local law firms have learned the value of Internet access and have obtained Internet access. As our needs have grown, so has the complexity of our Internet gateway. In mid-1999, I replaced the original 486DX2 Slackware-based gateway with a Pentium 200 RedHat 6.0 based system I built into our old file server. Right now, the gateway machine performs, inter alia the following functions: IP masquerading (NAT), DHCP service, hosting out local intranet home page, email retrieval and delivery, hosting of several listservs, web caching, firewalling, etc. We are planning to replace our dialup with with a dedicated DSL link in the very near future. Linux has enabled us to provide Internet access to anyone in our firm who needs it at a fraction of the cost of other commercial options on the market.

Configuration files from the old Slackware gateway

chatscript

exec /usr/sbin/chat -r /tmp/report ABORT BUSY "" atdt80,7627577 CONNECT \
"" ogin: your_username_here word: your_password_here

rc.inet1

#! /bin/sh
#
# rc.inet1	This shell script boots up the base INET system.
#
# Version:	@(#)/etc/rc.d/rc.inet1	1.01	05/27/93
#

HOSTNAME=`cat /etc/HOSTNAME`

# Attach the loopback device.
/sbin/ifconfig lo 127.0.0.1
/sbin/route add -net 127.0.0.0

# IF YOU HAVE AN ETHERNET CONNECTION, use these lines below to configure the 
# eth0 interface. If you're only using loopback or SLIP, don't include the
# rest of the lines in this file.

# Edit for your setup.
IPADDR="192.168.1.1"	# REPLACE with YOUR IP address!
NETMASK="255.255.255.0"	# REPLACE with YOUR netmask!
NETWORK="192.168.1.0"	# REPLACE with YOUR network address!
BROADCAST="192.168.255.255"	# REPLACE with YOUR broadcast address, if you
			# have one. If not, leave blank and edit below.
GATEWAY="192.168.1.1"	# REPLACE with YOUR gateway address!

# Uncomment the line below to initialize the ethernet device.
/sbin/ifconfig eth0 ${IPADDR} broadcast ${BROADCAST} netmask ${NETMASK}

# If the line above is uncommented, the code below can also be uncommented.
# It sees if the ethernet was properly initialized, and gives the admin some
# hints about what to do if it wasn't.
if [ ! $? = 0 ]; then
  cat << END
Your ethernet card was not initialized properly.  Here are some reasons why this
may have happened, and the solutions:
1. Your kernel does not contain support for your card.  Including all the
   network drivers in a Linux kernel can make it too large to even boot, and
   sometimes including extra drivers can cause system hangs.  To support your
   ethernet, either edit /etc/rc.d/rc.modules to load the support at boottime,
   or compile and install a kernel that contains support.
2. You don't have an ethernet card, in which case you should comment out this
   section of /etc/rc.d/rc.inet1.  (Unless you don't mind seeing this error...)
END
fi


# Uncomment these to set up your IP routing table.
/sbin/route add -net ${NETWORK} netmask ${NETMASK}
/sbin/route add 192.168.1.254 eth0
/sbin/route add -net 192.168.2.0 netmask 255.255.255.0 gw 192.168.1.254
# The following line is for DHCP to work correctly
/sbin/route add -host all-ones dev eth0
#/sbin/route add default gw ${GATEWAY} metric 1

# End of rc.inet1

rc.inet2


#!/bin/sh
#
# rc.inet2	This shell script boots up the entire INET system.
#		Note, that when this script is used to also fire
#		up any important remote NFS disks (like the /usr
#		distribution), care must be taken to actually
#		have all the needed binaries online _now_ ...
#
# Author:	Fred N. van Kempen, 
#

# Constants.
NET="/usr/sbin"
IN_SERV="lpd"
LPSPOOL="/var/spool/lpd"

# At this point, we are ready to talk to The World...
echo "Mounting remote file systems..."
/sbin/mount -a -t nfs		# This may be our /usr runtime!!!

echo -n "Starting daemons:"

# Start the SYSLOGD/Klogd daemons.  These must come first.
if [ -f ${NET}/syslogd ]; then
  echo -n " syslogd"
  ${NET}/syslogd
  echo -n " klogd"
  ${NET}/klogd
fi

# Start the SUN RPC Portmapper.
if [ -f ${NET}/rpc.portmap ]; then
   echo -n " portmap"
   ${NET}/rpc.portmap
fi

# Start the INET SuperServer
if [ -f ${NET}/inetd ]; then
  echo -n " inetd"
  ${NET}/inetd
else
  echo "no INETD found.  INET cancelled!"
  exit 1
fi

# Start the NAMED/BIND name server.
if [ -f ${NET}/named ]; then
   echo -n " named"
   ${NET}/named
fi

# # Start the ROUTEd server.
if [ -f ${NET}/routed ]; then
   echo -n " routed"
   ${NET}/routed -g
fi

# # Start the RWHO server.
# if [ -f ${NET}/rwhod ]; then
#   echo -n " rwhod"
#   ${NET}/rwhod -t -s
# fi

# Start the DIALD server.
if [ -f /usr/local/sbin/diald ]; then
   echo -n " diald"
   /usr/local/sbin/diald -daemon 2> /dev/tty7 &
fi

# Start the HTTPD server.
if [ -f ${NET}/httpd ]; then
   echo -n " httpd"
   ${NET}/httpd
fi

# Start the DHCPD server.
if [ -f /usr/local/sbin/dhcpd ]; then
   echo -n " dhcpd"
   /usr/local/sbin/dhcpd 2> /dev/null
fi

# Start the various INET servers.
for server in ${IN_SERV} ; do
  if [ -f ${NET}/${server} ]; then
    echo -n " ${server}"
    ${NET}/${server}
  fi
done

# # Start the various SUN RPC servers.
if [ -f ${NET}/rpc.portmap ]; then
  # Start the NFS server daemons.
  if [ -f ${NET}/rpc.mountd ]; then
    echo -n " mountd"
    ${NET}/rpc.mountd
  fi
  if [ -f ${NET}/rpc.nfsd ]; then
    echo -n " nfsd"
    ${NET}/rpc.nfsd
  fi




#  # Fire up the PC-NFS daemon(s).
#  if [ -f ${NET}/rpc.pcnfsd ]; then
#    echo -n " pcnfsd"
#    ${NET}/rpc.pcnfsd ${LPSPOOL}
#  fi
#  if [ -f ${NET}/rpc.bwnfsd ]; then
#    echo -n " bwnfsd"
#    ${NET}/rpc.bwnfsd ${LPSPOOL}
#  fi
fi # Done starting various SUN RPC servers.

# The 'echo' below will put a carriage return at the end
# of the list of started servers.
echo

# # Setting up NIS:
# # (NOTE: For detailed information about setting up NIS, see the
# #  documentation in /usr/doc/yp-clients and /usr/doc/ypserv)
# #
# # First, we must set the NIS domainname.  NOTE: this is not
# # necessarily the same as your DNS domainname, set in 
# # /etc/resolv.conf!  The NIS domainname is the name of a domain
# # served by your NIS server.
#
# if [ -r /etc/defaultdomain ]; then
#   domainname `cat /etc/defaultdomain`
# fi
#
# # Then, we start up ypbind.  It will use broadcast to find a server.
#
# if [ -d /var/yp ] ; then
#   echo "Running ypbind..."
#   /usr/sbin/ypbind 
# fi

# Done!

rc.local

#!/bin/sh
#
# /etc/rc.d/rc.local:  Local system initialization script.
#
# Put any local setup commands in here:
#echo Starting diald...
#/usr/sbin/diald
#/usr/bin/sleep 5
/bin/setserial /dev/modem spd_vhi
/sbin/depmod -a
/sbin/modprobe -a \*
echo Configuring IP Masquerade and Firewall...
/sbin/ipfwadm -F -p deny
/sbin/ipfwadm -F -a m -S 192.168.0.0/16 -D 0.0.0.0/0 -W ppp0
/sbin/ipfwadm -F -a m -S 192.168.0.0/16 -D 0.0.0.0/0 -W sl0
/sbin/ipfwadm -I -a deny -S 192.168.1.1/32 -D 0.0.0.0/0 -o -W ppp0
echo 1 > /proc/sys/net/ipv4/ip_dynaddr
echo Starting MARS_NWE...
/sbin/nwserv &
#/usr/sbin/syslogd &

options

# PPP options
silent
ipcp-accept-local
ipcp-accept-remote

named.boot

;
;    boot file for name server
;
directory /etc
; type		domain			source host/file	backup file

cache		.			root.cache
primary		glancynet.com		named.hosts
primary		0.0.127.IN-ADDR.ARPA	named.local
primary   	168.192.IN-ADDR.ARPA	named.rev
forwarders	199.72.95.1 199.72.95.3
;slave
options forward-only
;options no-recursion

standard.filter

# This is a pretty complicated set of filter rules.
# (These are the rules I use myself.)
#
# I've divided the rules up into four sections.
# TCP packets, UDP packets, ICMP packets and a general catch all rule
# at the end.


#------------------------------------------------------------------------------
# Rules for TCP packets.
#------------------------------------------------------------------------------
# General comments on the rule set:
#
# In general we would like to treat only data on a TCP link as signficant
# for timeouts. Therefore, we try to ignore packets with no data.
# Since the shortest possible set of headers in a TCP/IP packet is 40 bytes.
# Any packet with length 40 must have no data riding in it.
# We may miss some empty packets this way (optional routing information
# and other extras may be present in the IP header), but we should get
# most of them. Note that we don't want to filter out packets with
# tcp.live clear, since we use them later to speedup disconnects
# on some TCP links.
#
# We also want to make sure WWW packets live even if the TCP socket
# is shut down. We do this because WWW doesn't keep connections open
# once the data has been transfered, and it would be annoying to have the link
# keep bouncing up and down every time you get a document.
#
# Outside of WWW the most common use of TCP is for long lived connections,
# that once they are gone mean we no longer need the network connection.
# We don't neccessarily want to wait 10 minutes for the connection
# to go down when we don't have any telnet's or rlogin's running,
# so we want to speed up the timeout on TCP connections that have
# shutdown. We do this by catching packets that do not have the live flag set.

# --- start of rule set proper ---

# When initiating a connection we only give the link 15 seconds initially.
# The idea here is to deal with possibility that the network on the opposite
# end of the connection is unreachable. In this case you don't really
# want to give the link 10 minutes up time. With the rule below
# we only give the link 15 seconds initially. If the network is reachable
# then we will normally get a response that actually contains some
# data within 15 seconds. If this causes problems because you have a slow
# response time at some site you want to regularly access, you can either
# increase the timeout or remove this rule.
accept tcp 15 tcp.syn

# Keep named xfers from holding the link up
ignore tcp tcp.dest=tcp.domain
ignore tcp tcp.source=tcp.domain

# Keep netbios from holding us up as well.
ignore tcp tcp.source=tcp.netbios-ns,tcp.dest=tcp.netbios-ns

# (Ack! SCO telnet starts by sending empty SYNs and only opens the
# connection if it gets a response. Sheesh..)
accept tcp 5 ip.tot_len=40,tcp.syn

# keep empty packets from holding the link up (other than empty SYN packets)
ignore tcp ip.tot_len=40,tcp.live

# make sure http transfers hold the link for 2 minutes, even after they end.
# If the link is already down, don't let a FIN packet bring it back up.
# NOTE: Your /etc/services may not define the tcp service www, in which
# case you should comment out the following two lines or get a more
# up to date /etc/services file. See the FAQ for information on obtaining
# a new /etc/services file.
ignore tcp !tcp.live,tcp.dest=tcp.www
ignore tcp !tcp.live,tcp.source=tcp.www
accept tcp 120 tcp.dest=tcp.www
accept tcp 120 tcp.source=tcp.www

# Once the link is no longer live, we try to shut down the connection
# quickly.
keepup tcp 5 !tcp.live
ignore tcp !tcp.live

# IP Masquerading splits the TCP/IP connection inbound/outbound
# Detect the FIN and allow 30 s for the acknowledgement

keepup tcp 30 tcp.fin                           # jmk 97.10.20 (added)
ignore tcp tcp.fin                              # jmk 97.10.20               

# an ftp-data or ftp connection can be expected to show reasonably frequent
# traffic.
accept tcp 120 tcp.dest=tcp.ftp
accept tcp 120 tcp.source=tcp.ftp

#NOTE: ftp-data is not defined in the /etc/services file provided with
# the latest versions of NETKIT, so I've got this commented out here.
# If you want to define it add the following line to your /etc/services:
# ftp-data        20/tcp
# and uncomment the following two rules.
#accept tcp 120 tcp.dest=tcp.ftp-data
#accept tcp 120 tcp.source=tcp.ftp-data

# If we don't catch it above, give the link 10 minutes up time.
accept tcp 600 any

# Rules for UDP packets
#
# We time out domain requests right away, we just want them to bring
# the link up, not keep it around for very long.
# This is because the network will usually come up on a call
# from the resolver library (unless you have all your commonly
# used addresses in /etc/hosts, in which case you will discover
# other problems.)
# Note that you should not make the timeout shorter than the time you
# might expect your DNS server to take to respond. Otherwise
# when the initial link gets established there might be a delay
# greater than this between the initial series of packets before
# any packets that keep the link up longer pass over the link.

# Don't bring the link up for rwho.
ignore udp udp.dest=udp.who
ignore udp udp.source=udp.who
# Don't bring the link up for RIP.
ignore udp udp.dest=udp.route
ignore udp udp.source=udp.route
# Don't bring the link up for NTP or timed.
ignore udp udp.dest=udp.ntp
ignore udp udp.source=udp.ntp
ignore udp udp.dest=udp.timed
ignore udp udp.source=udp.timed
# Don't bring up on domain name requests between two running nameds.
#ignore udp udp.dest=udp.domain,udp.source=udp.domain
# Bring up the network whenever we make a domain request from someplace
# other than named.
accept udp 30 udp.dest=udp.domain 
accept udp 30 udp.source=udp.domain
# Do the same for netbios-ns broadcasts
# NOTE: your /etc/services file may not define the netbios-ns service
# in which case you should comment out the next three lines.
ignore udp udp.source=udp.netbios-ns,udp.dest=udp.netbios-ns
accept udp 30 udp.dest=udp.netbios-ns
accept udp 30 udp.source=udp.netbios-ns
# keep routed and gated transfers from holding the link up
ignore udp tcp.dest=udp.route
ignore udp tcp.source=udp.route
# Anything else gest 2 minutes.
accept udp 120 any

# Give icmp packets 30 seconds.
accept icmp 30 any

# Any packets we did not catch above belong to some bizzare protocol
# that we don't know about. We ignore them.

diald.conf

mode ppp
connect "/etc/ppp/chatscript"
device /dev/ttyS1
speed 115200
modem
lock
crtscts
local 192.168.0.1
remote 192.168.0.2
dynamic
defaultroute
fifo /etc/diald.fifo
include /usr/local/lib/diald/standard.filter
pppd-options lcp-echo-interval 10 lcp-echo-failure 2


Last updated: May 20, 2005
J. William Snyder, Jr. ()

Back to the Will's Home Page