|
|
||
An IPCop Journal© Copyright Darrell Anderson. (Winter 2003–2004) IntroductionMy sole computer is a Pentium MMX, 66 MHz FSB box. A few years ago I swapped the MMX CPU for a snappier and cooler operating K6-III+. After adding a silent Seagate 40 GB hard drive and some carbon resistors to decrease fan voltage and noise, I have been content with my silent and efficient PC. I have used NT4 Workstation since 1997 and have done much hand-tuning to create a stable system. I never have had any desire to move to Windows 2000 or XP and subject myself to the nonsense of those new licensing schemes. I use my computer primarily for writing in Word 97, surfing with Firefox, and checking email with Eudora 5.1. My only true computer bottleneck to impede my personal production is a rural dial-up connection. For two years I have been learning more about Linux. Linux matches my personal philosophy and I want to eventually migrate away from the secretive and manipulative world of closed-source software (Note: I am not against making a living or a profit from software development, I only oppose the concept of closed source and vendor lock-in). I have been using Mandrake 9.0 and 9.2, but I never have used Linux in a productive manner—only as a learning environment. However, as a home user, I’ve been hampered with owning only one computer and necessarily being required to multiboot between my primary NT4 system and Linux. A great frustration with a multiboot system is while exploring Linux I cannot concurrently inspect my NT4 configuration to review how I do things there to make real-time comparative changes. Continually rebooting between the two OSs is annoying and time consuming. Although I am pursuing a goal of one day fully migrating to Linux, that effort is taking longer that I had hoped or anticipated. Thankfully, my NT4 system is rock solid and stable and I’m as productive in that environment as I need to be. Everything just works. Therefore, my migration plan is facing no deadlines. One box running both OSs offers only a handful of solutions. VMWare is an expensive way to go but with aging hardware that solution is undoable except to masochists. Other solutions include Win4Lin, WINE, and Crossover Office, but again, my hardware limits the practicality of solutions. Additionally, I prefer not to run Windows software on a Linux partition. I want to migrate cleanly to equivalent Linux software. If I am going to use Windows software then I’ll keep using my stable NT4 system. Currently, other than as a self-teaching project, the only productive reason I use Linux is the K3B CD program. I never had any success running CD software on my NT4 box and for a while I gave up on Linux because I was unable to burn Linux distro CDs. After I discovered K3B, I was able to burn CD ISO images and I again began exploring Linux. Recently I inherited a second computer—a PII-350 box. Because my NT4 system is quite snappy on my K6-III+ box, and Linux GUIs on that box tends to be sluggish, I decided that I would configure my “new” and more modern hardware as a dedicated Linux box. With two computers available, one remaining as a multiboot system hosting NT4 and Linux (and WFWG 3.11—for nostalgia’s sake, just like old cars), and the other box dedicated to Linux, I foresaw a need to network the two boxes. Additionally, I want to be able to connect to the internet from either box. I have two phone lines into my house, and I foresee occasions as I teach myself Linux wanting the ability to have both boxes connected online simultaneously. A more obvious solution is a dedicated firewall/router/gateway. Several mini-distros dedicated to that task are well received in the Linux community and I decided to investigate that option. Additionally, because I am stuck with dialup—and likely will be for several years, I envisioned an “intelligent” web proxy caching server improving my surfing experience. I am the only computer user in my house and even with an old hard drive and a 10 Mbps NIC, computer-to-computer transfer speeds would be much faster than any 28.8 Kbps I’d see from my dialup connection. Thus, a dedicated firewall and gateway box seemed like a worthy experiment. PreparationsSeveral Linux distros beckoned my testing. After lightly studying the topic, the first distro I decided to try was IPCop. The first thing I did was download the CD image and the nine patches. I did that while visiting a relative who has broadband. When I returned home I wanted to merge the nine patches into the same CD containing the original IPCop disk image. I had no idea how to do what seemed to me a straightforward task. Additionally, my experience with Linux CD burning is limited to copying only entire disk images, not merging images with new files to create anew disk image. After much trial and error—mostly error, I finally discovered a way to merge the patch files and create a new CD image. I had to use the command line. Doable but a nuisance. Sorry, old Linux diehards, GUI is here to stay and that is the way I prefer to work too, despite having lived through the “old” days of command lines. So do millions of other computer users. Perhaps the newer versions of K3B will make such tasks easier, and if Linux is to increase market share then I hope such tasks become easily supported. However, a more direct question is why don’t distro vendors create and provide current disk images? One of the aspects about Linux that I deplore is playing the update game. Users should be able to download the latest CD image that includes all updates to that date. This is not just an IPCop problem but one that affects many Linux distros. With today’s technology, there should be no reason that people cannot download updated current versions of any distro. Many people still do not have broadband and likely will not for several years, yet they are hampered by this cumbersome updating process. I have experimented with only a few distros, but before downloading I always wait several months after a distro is released to ensure I thereafter don’t have to worry much about additional updates or patches. I download those updates along with the original CD image. I hope Linux distro vendors stop playing this updating game. Uploading patches makes sense for those people who already have installed the original CD image, but people who want to try that distro should be able to download a current updated CD image containing all the latest files. During this image burning exercise I discovered that K3B would install a disk image to a CD-RW. I was pleasantly surprised to find that NT4 could read the CD-RW as a normal disk. The only time I previously played with CD-RW disks was when I was trying to get the Roxio program working on NT4 and Roxio always kept the CD-RW disk “open” using a UDF driver. Nonetheless this discovery was a nice surprise because momentarily I did not have any CD-R disks to burn and I wanted to get started on this project without the delay of waiting to go to the store. HardwareI still owned a “vintage” 1991 486-33 box. For several years my 486 box has been sitting quietly on a shelf. According to many reports, my 486 box should be ideal for running a Linux firewall/router/gateway mini-distro. The box contains 16 MB of SIMM RAM, a 540 MB hard drive, an ATI Ultra graphics card, and an SMC WD8013 NIC. Long ago when I still used the box I installed a Cyrix 586 adapted to the 486 socket. Although I suspected that more RAM would help, the box was suitable as is for testing. Years ago that 486 box was once my main production system, running MS-DOS 6.22 and WFWG 3.11. My hard drive on that system still contained that original configuration. For about two years as I slowly migrated to NT4 on my then-new Pentium MMX system, I used a CAT-5 crossover cable to network the two computers. The CAT-5 crossover cable would once again connect my two computers. For now, the PII-350 box would sit stored away, although I would use the plug-and-pray (PnP) modem that came with the box. Preparing My 486Although I once had the 486 networked with my K6-III+ box, I decided to fiddle with that again to ensure both NICs still functioned. I verified everything worked okay using NetBEUI and I did not bother testing TCP because I would have had to install a WFWG add-on TCP package. That was extra work for something for a system that soon would no longer exist. For now I wanted only to test the NICs and they tested fine. My 486 contains a multi-interface card to provide the connectors for my serial, parallel, floppy, and hard drive ports. The card supports two devices from the IDE connector. I tried connecting a spare CD drive but the 486 box would lock and refuse to boot. I am not sure what the problem was, but every time I disconnected the CD drive everything worked okay. I triple-checked jumpers, BIOS, etc. I tried some half-hearted steps to configure an FTP server with my Mandrake Linux side of my dual boot, but as I began to read the documentation for ProFTPd I decided that I would be in over my head. Rome was not built in a day and I cannot be expected to learn all of this overnight. According to the IPCop installation manual, I had three options for installing: (1) directly from a CD drive, (2) booting with a floppy and then continuing with a CD drive, and (3) booting with a floppy and continuing the installation from an FTP server. At this point I seemed stumped at getting IPCop installed to my 486 hard drive. Installing IPCopWith respect to the installation, I found the IPCop documentation lacking. There is a certain presumption in the documentation of a certain skill-of-the-craft. I see products such as IPCop as being important software that could nudge Linux into many homes, but not with documentation written for geeks. I acknowledge that some networking skills are needed to install a home network, but the IPCop developers could have done better with the documentation. Another thing I discovered as sad but somewhat humorous, is IPCop is touted as a firewall appliance and is designed to use those old 486s sitting in the closet. Yet, many of those old boxes do not support CD drives, or like my box, are finicky about adding devices. What I don’t understand is why the IPCop people did not support simple peer-to-peer networking to act as a substitute for the CD drive. Who has time to learn and configure FTP servers when all they want is a firewall appliance using old hardware? If the software developers could create an FTP option to complete the installation, they could have done so with simple networking too. Without a CD drive or an FTP server, I wondered if I could move components to a computer with a CD drive and install from there. From there I hopefully would get IPCop installed and the NIC correctly configured. The modem is another question because there is no way to manually configure the PnP card—no jumpers. I suspected that IPCop would recognize the PnP modem in the PII-350 box, but not when transferred to the 486 box. I later might have to opt for a different modem or use the modem from my main box. I therefore temporarily moved the hard drive, modem, and NIC to my “new” PII-350 box. I began the installation. I then ran into my first challenge. I had to reconfigure the BIOS to recognize the old hard drive. The old BIOS did not have an Auto option and I had to manually configure the information. I made the changes and continued. My next challenge was the PII box contained 256 MB of RAM. IPCop demanded a hard drive size of 125 MB + 2x RAM, or a 637 MB hard drive. I understand the desire to configure IPCop that way, but only if one wants to run Squid and Snort. I disagreed that a user should be prevented from continuing the installation without that hardware requirement. Many people use IPCop without those two programs and 16 MB of RAM is sufficient for a basic firewall. Nonetheless, I shut down the computer, removed a memory stick, and tried again. The installation proceeded to the point where I was instructed to remove the CD. After configuring the network address and type (GREEN with a modem) I got stuck in a loop with IPCop continually displaying a text message of “Pushing non local network down.” I could not proceed to the next section to configure DHCP or passwords. Then I realized the dialog box did not contain “OK” and “Cancel” buttons, but “OK” and “Done” buttons! I selected the Done button and proceeded to the DHCP page. Everything proceeded according to Hoyle thereafter. Configuring IPCopThe next step was to see if my browser on my NT4 box could find IPCop. No go. Then I reconfigured NT4 for DHCP. No go. I then set IPCop and my workstation for static addresses. I set NT4 to 192.168.1.10/255.255.255.0. No go. I toggled my browser to bypass my Proxomitron web filter proxy. No go. I disabled my Kerio firewall (I was offline). No go. I tried pinging IPCop at 192.168.1.1. No go. However, I could see both NIC LEDs flickering during the ping. I then logged in at the IPCop box and browsed the logs. Everything seemed okay, at least as much as I know about Linux. I rebooted into my Linux Mandrake 9.2 partition. I went into the Mandrake Control Center and configured the NIC. Then I rebooted. Nothing. When I rechecked the Mandrake Control Center, the card was listed as down. I gave up, shut down the PII box, and transferred the hard drive, NIC, and modem back to my 486 box. I booted and IPCop loaded fine. Apparently my plan worked to install on another computer. I wish the IPCop installation manual had mentioned this option rather than leave me guessing. Yet, I still could not ping. I shut down the 486 box because of the noisy hard drive and I went to the internet hoping for a clue. I took some notes, but found nothing dramatic except for an indirect blurb that reminded me to check my NT4 services. There I found the DHCP Client service disabled. That discovery explained why my NT4 box could not find a DHCP server, but did not explain why I could not ping while using static addresses, or why in Mandrake the NIC would not start. While in the middle of my online research, I had a weird suspicion that possibly the NIC and modem were fighting for an IRQ. I pulled the PnP modem card. I started the IPCop box and for whatever reason I could ping from my NT4 box to my IPCop box. I then quickly fired up my browser and went to http://192.168.1.1:81. Success! Was the modem card the culprit? I did not know and because the modem was PnP, I had no intentions of investigating later. Although I could now ping the IPCop box, I could not ping from my IPCop box to my NT4 box. Then I remembered I had configured my Kerio firewall rules to forbid unsolicited ICMP pings except those I initiated. I disabled the firewall (I was offline) and I then could ping from the IPCop box to my NT4 box. I then created additional Kerio firewall rules to allow pinging from the IPCop box. While I had taken notes during my surfing, I had a light bulb moment that the reason my Mandrake system was not starting the NIC was that I was not starting the network service. I rebooted into Mandrake and started that service. Everything then seemed to be working fine. I could ping both ways in both OSs. I decided not to go back and retest DHCP because with only two computers today and three in the future, I see no challenge with maintaining static addresses. Additionally, for the period through which I would be testing firewall and gateway distros, I would want to continue dialup access from my primary computer. Lastly, unless I commit to a full-time LAN, I won’t always be booting or needing the gateway box. Thus, to avoid DHCP error messages during booting, static addresses seemed best. I configured my browser to bypass my Proxomitron web filter proxy when accessing local network address of 192.168.1.1. Then I tried configuring the IPCop dial-up account using the browser interface. Regardless of what I tried, I always received a message that the box was configured improperly. Masking this problem was another concurrent problem I encountered throughout these attempted configuration changes. I could not make changes while in my client browser. Everything I tried failed. I tried completely bypassing my Proxomitron web filter proxy. No go. I tried enabling Javascript. No go. I tried enabling cookies. No go. I enabled the HTTP Referrer header and finally I could make changes. I do not typically surf with that option enabled, nor do I typically use Javascript or cookies. I will go back through the manuals but I don’t recall reading anything that enabling the HTTP Referrer header is required. I suppose from a security perspective that requirement makes sense, but I wasted a lot of time hunting down that one fix. With that problem corrected, I finally got frustrated with my Dial-up configuration efforts and I unchecked all options. I stopped receiving error messages. I finally discovered that IPCop refused to let me enable the Dial on Demand for DNS option. Yet, I still could not dial out. I presumed the 486 box was not recognizing the PnP modem (in hindsight I should have watched the serial port section during the BIOS boot-up screen or Linux kernel boot messages to see if a third port was available). I temporarily transferred my non-PnP ISA 56K modem from my primary box to the IPCop box. By this time I was mentally tired because I could not get the modem to work in the 486 box. I checked the jumpers to no avail. I then grabbed my old 14.4 Kbps modem that I originally had used when I bought the 486 box in 1991. I finally dialed out from my browser on my primary computer through IPCop. Although surfing at 14.4 Kbps required patience, when I got the IPCop box to dial out I immediately ran into a huge conceptual road block. How do I surf? Not at all intuitive or obvious to me! Then by chance I changed the browser proxy settings to 192.168.1.1:80, disabled my Proxomitron web filter proxy and my Kerio software firewall, and I finally could browse. I found nothing in the IPCop documentation about that simple conceptual exercise. I then slowly returned my system to normal using Proxomitron and Kerio. Yet, I could not surf with my browser. Finally I succeeded—based upon warning messages from my Kerio firewall. I realized I needed to configure my Proxomitron web filter proxy to use the IPCop proxy at 192.168.1.1. Finally connected online, the first thing I wanted to do was visit the Shields Up! web site. Were all my ports running in Stealth mode? As I tried accessing that web site, I realized I needed additional rules for my Kerio firewall. I am cautious about phone-home nonsense and I have rules regulating queries to port 53 for DNS. I needed to add rules to allow DNS calls to my IPCop gateway box. I also needed to add additional rules to allow ICMP pinging within the local network and to outside the LAN. I finally succeeded in displaying the Shields Up! site but I was dissatisfied with the report. Port 113 was not stealthed. I realize that in practical terms a closed port is as safe as a stealthed port, but after years of running my NT4 box with all ports stealthed, I wanted the same with IPCop. I recalled reading about port 113 while browsing an IPCop discussion forum and I disabled that port. Now Shields Up! showed all ports stealthed. Although all ports were stealthed, that effort was rendered meaningless because I could not stop the IPCop box from responding to ICMP pings. After surfing for solutions at the discussion forums and trying some of those solutions, I never could figure out how to stop IPCop from responding to outside pings. Conceptually, I realized I needed to stop pings from the Red zone but allow pings within the Green zone. However, understanding and tinkering with IPTables was far beyond my current learning curve. Yet, as an out-of-the-box project, why wasn’t IPCop automatically configured to ignore all Red Zone pings and why wasn’t port 113 disabled? Those people who want to setup VPNs or use chat tools more than likely know enough how to manage firewall rules. Thus, the default should be to ignore everything. In my primary box I then booted into my Mandrake partition. I bypassed the IPCop box and I discovered ports 631 and 6000 open. The former port allows internet access to the CUPS printing system. The latter port allows access to the X windowing system. After additional surfing I discovered ways to block those ports from internet access. Although I wanted CUPs available for an internal local network, I have no need or desire to allow internet access. Although I might one day experiment with Virtual Networking (VNC) within my small home LAN, I nonetheless disabled port 6000 for now and wrote notes for future reference. However, I never could figure out how to configure my Mandrake partition for stealth operations. Again, a lack of understanding about IPTables blocked my progress. Returning from a project break of a few hours I realized why my 56K modem was not working. I had only checked the IRQ jumper but had forgotten to check the COM port jumper. I changed the jumper. I finally got the IPCop to dial out using the 56K modem. Additional ServicesNow that I had the basic firewall and gateway working, I wanted to try the Squid caching program. I had read that Squid is RAM hungry and that 16 MB might be a struggle. However, I was the sole user and system demand should be minimal. My instincts said that I should get Squid to work. I did and I enjoyed the results. I suspect more RAM would help, however. Next I configured the NTP time service. After finding a host server geographically close, I was able to keep my IPCop box clock synchronized. I needed that too because my old 486 box was lagging several minutes every hour. I did not try to get my NT4 box to sync its clock to the IPCop box because I already had a small applet program installed to synch that clock using the older port 37 process. I never enabled Snort, the intrusion detection service. Years ago I used BlackIce on my NT4 system, and after several weeks I grew weary of watching logs and being interrupted by alerts. After long ago migrating to Tiny Personal Firewall and then its successor Kerio, I have been long comfortable with my firewall rule set and stopped most logging and alerts. Likewise, as long as my IPCop box was not responding at any port request, my box would be transparent to the internet except to my ISP and web sites I visited. I do not anticipate ever needing Snort for my simple home network and thankfully—I could dispense with that overhead. Next I could not conceptually figure out how to check my email from NT4 with Eudora. I gave up trying to figure out what I suspected was something that should be intuitively obvious but I gave up and finally went to bed after that first day of exploration. The next day I realized in my NT4 TCP/IP configuration I never had set an address for the NIC default gateway. Finally I could check email from NT4 through IPCop. I wish I had immediate access to additional RAM because the 486 box was very slow, with or without Squid running. SSH connections were irritatingly slow despite an otherwise snappy network response. I recommend to many home users who decide to use old 486 boxes as an internet gateway and firewall to keep a monitor and keyboard connected and make configuration changes directly at the IPCop box rather than with the browser or SSH. There are only a handful of configuration files and once learned, can be edited with the vi text editor. The 486 box is simply too slow for cross-LAN configuration changes. Then again, once most of the configuration changes are active and in place, there should be little need to tinker. Another slow aspect I noticed, is the actual dial-up. After entering a login name and password, I waited a long time for the 486 box to actually dial out. From my primary box, my NT4 Dial-Up Networking and Linux KDE KPPP tool connect within a couple of seconds. I do not have any written notes, but I recall needing about two minutes for the dial out. I have no idea why IPCop takes so long, but my browser or email client always would timeout before IPCop connected. Through my exploration I found some interesting information about redesigning the IPCop browser pages. To the main page I added information about my IP address, automatically assigned DNS servers, as well as KB transferred in and out. I added a refresh tag to update the page every 5 minutes. That kind of information should have been standard. However, all of the IPCop interface browser pages downloaded to my primary box very slowly. Thus, I removed the sidebar IPCop image to help improve that process. I also deleted the HTML lines that automatically looked to the Sourceforge web site for updated images. I dislike that latter idea with respect to a dedicated firewall box and the IPCop developers are displaying much pomposity by inserting such code. The most likely reason for those three lines of code is to superficially increase Sourceforge statistics about people accessing the IPCop web site. If that is the reason then we are witnessing dishonest advertising—something the Linux philosophy should discourage. ConclusionAlthough successful, for now I decided not to continue operating with a dedicated firewall and gateway box. The box consumes extra electricity and as a solitary user I do not need the dedicated box. Additionally, one aspect I do not like about the browser interface is the requirement to connect using a login name and password. Perhaps one day I’ll discover an option to dial without that requirement. For a small home network, I want to click and dial without any fuss—just like I do with my Dial-Up Networking and KPPP tools. As a home user, if I permanently used that 486 box as an internet gateway and firewall, I would have to move the box far away from me because the old hard drive is noisy. I do not have the option of updating the hard drive to a quiet fluid bearing drive because the BIOS will not recognize such large drives. My primary box is a silent PC and the 486 noise was greatly irritating. Additionally, although IPCop is touted as a way to put old 486 boxes to good use, the disk thrashing that went on whenever I had the box running almost put me into the loony house. The thrashing happened even when not connected and only idling. Someday I hope to learn more to disable some of that unnecessary logging and related disk thrashing. When I finally configure my PII-350 box as a dedicated Linux box, I intend to configure that box as a workstation but I also will experiment with configuring the box as an internet gateway and firewall for my primary dual-boot box. Although I never could get the PnP modem to work in NT4, my Linux partition had no problem finding the modem and I already know the PnP modem works in the PII-350 box. With a faster CPU, a 100 MHz FSB, 256 MB of RAM, and a silent Seagate ATA-33 40 GB hard drive, I suspect the hardware of my PII box will be more than enough to handle both workstation and gateway duties and will provide noticeable speed improvements over the 486 box. However, when that day arrives, I might also play some more with the 486 box as a dedicated gateway. I suspect that now with my experience and recent education, that I might be able to research ways to fine-tune that 486 box to operate more quickly. If not, then the box will remain on the shelf for a long time. Additionally, I hope later to test the Smoothwall Express 2.0 firewall and gateway. The product is similar to IPCop as both products came from the same project roots. Based upon web site information, the Smoothwall browser pages seem more aesthetically pleasing and informational than the IPCop pages. Additionally, the Smoothwall product name is more appealing to me than a product containing the name “cop.” Philosophically the IPCop name does not settle well with me. Isn’t there enough totalitarianism in this world without philosophically encouraging that process through product names? A great lesson for new users is documentation in the Linux world still leaves many new and nontraditional Linux users frustrated. If Linux is ever to make significant progress into the market then software developers must hire competent technical writers to help provide documentation. Good technical writers see both the trees and the forest and ask questions that developers never consider. Despite barely adequate documentation, I discovered how to install IPCop using a method not mentioned in the documentation. I discovered that a user cannot make IPCop configuration changes unless a browser is sending HTTP Referrer headers. I discovered that interfacing with a gateway box from Windows or Linux requires a much better checklist than anything I found within the IPCop documentation or online in discussions. I likely discovered these options primarily because of my own technical writing background. Overall, I got the IPCop system to work, but only through much trial and error. Based upon reports and reviews, I had anticipated a much easier investigation. Nonetheless, adding a dedicated internet gateway and firewall is doable process for the home user newbie. If you are a newbie, however, do not expect to build Rome in a day. Be patient, take lots of notes, and hopefully this essay has provided some precautionary perspectives for where the typical newbie might stumble. A Firewall/Router/Gateway Checklist
|
||