Okay... I've figured out a couple of things. I'll post them here in case anyone else gets in the same trouble. There are hints of solutions to all this in various places scattered around the Web, but nothing explicit or in one place, that I could find. Basically, I just spent enough time trying combinations of things and finally got lucky. (I have V0.8xx so any or all of this may or may not apply to later versions.)
(1) The setup "wizard" defaults to device "eth0" as the primary communication device. If you *either* fail to select "ppp0" *or* the selection somehow changes (which is what happened to me, emphasis on the "somehow" - rerunning the "wizard" and regenerating the Firestarter shell script is a common procedure and probably subject to accidents, if nothing else...), Firestarter redirects various (but not all!) IP traffic to the LAN interface - i.e., things which are supposed to go in/out the connection to the ISP, end up forwarded to the Ethernet interface (causing the MAC transaction kernel logging messages to appear in the console window). Interestingly, enabling specific connections to specific IP addresses in the Firestarter rules, does cause those connections to then be directed to whatever running app needs them, on a rule-by-rule basis, while everything else continues to squirt out the Ethernet interface. This setup idiosyncrasy is undoubtedly the result of Firestarter being intended to run on a dedicated firewall machine, rather than being set up as a "personal firewall"... (2) Starting Firestarter manually as root *before* using "kppp" to connect with an ISP, does not work. What happens is, Firestarter can't find an existing pppd task to glom onto, and (for whatever reason), guess what - goes about redirecting the IP traffic out onto the network interface, in the same manner as it does if the "eth0" device is incorrectly selected. *Restarting* the firewall *after* establishing the PPP connection causes the firewall to start working correctly (at least, apps/utilities (Netscape, "ping", etc.) can then access the PPP connection correctly). Based on some snatches of conversation I found on the "sourceforge" website, I suspect that Firestarter needs to be started by init.d, and at the correct runlevel, in order to avoid this second problem. However, in my case at least, I was forced to disable the (default) startup behavior, because it locked up KDE on startup. There are some "gtk" errors (e.g., Gtk-WARNING **: invalid cast from (NULL) pointer to `GtkContainer', Gtk-CRITICAL **: file gtkcontainer.c: line 726 (gtk_container_remove):assertion `container != NULL' failed., etc.) which are generated with every call Firestarter makes to the window it puts up (i.e. every time it updates the transaction log in the log window), and apparently that causes KDE to choke on startup. (Interestingly, logging in and starting KDE as root worked, but logging in as a non-privileged user did not - go figure...). There was also a problem involving locale detection, which I've since fixed; I suppose I should try reinstating the init.d links to see if that was what was causing the KDE lockup. But, I'm not sure I want the firewall running until I'm ready to start a dialup connection in any case. Thus far, I haven't found any solution to the "gtk" error messages, which are commonly discussed in various places on the net w/r/t various apps; they're mentioned specifically w/r/t Firestarter on one of the German Linux security websites, but (to the best of my limited ability to translate German) the problem was deemed unsolvable without an upgrade. (I haven't looked to see if there's a newer "stable" version of the Gnome toolkit yet... I suppose that's worth a try.) Upgrading "woody" to Firestarter 0.9xx is more or less unworkable, from what I can tell (as has been previously explored here...) - a complete upgrade to "sarge" would make more sense. Unless I can find a backport of Firestarter version 0.9xx to Woody, I'll have to work around all the "Issues" for the time being. I may end up just using the scripts and "iptables" commands Firestarter has generated, as a starting point for a manually scripted personal firewall implementation. Thanks to everyone who responded, for your help. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]