I have a linux box set up as a multi-purpose server for my home with three Windows client PC's. The linux box is based on a slightly modified Slackware 9.0 distribution using Linux 2.4.20 and an unfortinately old, slow AMD processor with a miserable 512Kb RAM. The linux box serves the CIFS file system to the Windows boxes, runs the SQUID HTTP proxy, the Apache web server, a print server, does masquerading, mail serving and a very effective firewall using iptables.

This system, although slow, has run perfectly for several years.

Let me say that again - This system works perfectly.

I had decided that now is the time to upgrade the hardware, so I bought a Gigabyte LGA775 motherboard which has two 1Gb network interfaces on it, an ASUS 256Mb PCI-E display card, 2Gb of DDR3 RAM, an Intel Core2-Quad processor and a bunch of 500Gb SATA drives to set up a RAID5 array (but I intend that the system boot off one of several 40Gb PATA drives I have).
I set up the processor, motherboard, display card, RAM, a SATA DVD Drive and a 40Gb PATA hard disk in a "breadboard" layout and installed distro 13.1, being careful to set up the static IP for the local network, dhcpcd to get an IP address from the cable modem (my internet connection) and to enable ip_forward in the network configuration.
Then I installed a script invoked by /etc/rc.d/rc.local which installed all the SAME iptables rules as my old Linux box. There was one minor glitch when I had to change 8 occurrences of "-d ! $LOCAL_NET to"
"! --destination $LOCAL_NET" but that was no problem. I also set up /etc/resolv.conf, /etc/hosts , the BIND server files etc. etc. exactly as in the old box.
I am able to ping mirror.aarnet.edu.au (this is at the heart of Australia's internet hub network - if it's down the whole bloody thing is down) and have the system find the correct IP from the designated nameservers and contact that server with a return trip time of 35ms. I am able to run a telnet session from one of the Windows boxes and edit files on the Linux server. So both network interfaces work and I've got them the right way around.
I am able to run FTP on one of the Windows boxes and connect through to mirror.aarnet.edu.au, although it seems to hang when I try a DIR (but then so does the old linux system).

BUT

No web browser can get a message from a Windows box through the new linux setup out to the outside world. I have done a fair amount of logging in iptables and the http packets on port 80 are being redirected to port 3128 HOWEVER, squid reports back that page "/" cannot be opened (it seems that the URL is not being passed across to squid). iptables does NOT report that any packets are outgoing during this exchange. If I comment out the REDIRECT instructions to iptables and re-run the script, then again try a web browser on one of the Windows boxes, Windows pops up a connection diagnostic, reporting that the (unspecified) page cannot be found.

Before you ask, yes, I have checked that /proc/sys/net/ipv4/ip_forward is set to 1.


Why is this so. Or in other words, HELP.

Peter.

No ideas on this?

are you kidding ???
you are expecting settings and config files to work on a 4 versions newer OS
??? would you expect windows ME/2000 settings to work on win 7 ???

reset them back to the default and use the slack 13 tools to set the network connections and iptable rules
and aliases

Not hardly - as if I would expect it to be that simple.
Obviously you didn't read my post closely enough. I have set up two (different) ethernet NICs dhcpd, named, dhcpcd, inetd and they all work correctly. They would have to be working correctly for the FTP and telnet sessions I describe to work as described.

BTW I'm not now and never have run X.

IPTABLES and ip_forwarding are the functions not working. There are no clues in the relevant man pages as to why the newer version should behave differently to the old version. Over to you, lets see what you've got.

The location of ip_forwarding may have changed in your latest kernel. Several kernel modules that netfilter uses have different names. E.G. tc_conntrack is now nf_conntrack. An old firewall script may load modules by their old name. There may be other differences. In the latest version of ssh, you need to indicate the location of authorized_hosts with %h/.ssh/authorized_hosts instead of .ssh/authorized_hosts in /etc/ssh/sshd_config.
Some configuration files may have moved into directories, instead of a single configuration file. This has been happening for quite some time for services and scripts like logrotate, xinetd, udev, and now even xorg.conf and profile. These directories tend to end with ".d". Software packages will drop a file in these directories instead of editing the existing global script. Your old configurations may exist in a script while a conflicting script exists in a directory.

One such directory on OpenSUSE is /etc/sysconfig/SuSEfirewall2.d/services/. I'm not running Slackware, but they may have adopted the same strategy.

For the services where you have problems, configure them from scratch using your distro's current tools if needed.

You may want to read the release notes for each newer version of Slackware. I found out about "%h" in sshd_config by reading a release note. Before that I couldn't ssh pubkey authentication working copying my old config sshd_config after upgrading.

1 members found this post helpful.

I was under the initial impression that this board dealt with Slackware distributions only and accordingly left out that I am upgrading from Slackware 9.0 with Linux 2.4.20 to 13.1 using Linux 2.6.33.4 and the install DVD.
My method of upgrading is to install the entire default distibution (including the Huge-smp kernel precompiled and supplied with this distro)then get each of the functions I need running and tested one by one. Only if I find something missed out in the supplied kernel or I get everything I want working will I compile a kernel - and even then I will use one of the generic .config files supplied as a jumping-off point.
That being my workflow, I choose to disable as many options as possible during the scripted install and then enable them as I need them and only after reading any scripts and man pages involved.
Accordingly, I read through the /etc/rc.d/rc.ip_forwarding script and it sets the /proc/sys/net/ipv4/ip_forwarding flag. I don't recall enabling ipv6 at all (nor sshd or most of the other functions you mentioned).

Will things not work now if ipv6 and the relevant forwarding are not enabled?

I didn't mean to imply that you needed to enable ipv6. Only that I hadn't noticed "/proc/sys/net/ipv4/conf/all/forwarding" before.
The ssh difference was just an example of differences you can run into when copying old config files. It was an example I learned from experience after copying my old sshd_config file. When I read the release notes, I discovered the problem.

If your problem is with ip_tables, then print out your ip_tables rules. Read through your firewall script. There may be some kernel modules loaded at the start of the script. Make sure that those modules still exist, and haven't been renamed in the newest kernel release.

IMHO, you may not have a problem with ip_tables. Check the squid configuration and setup.

Did you run Squid "squid -z" to create the cache store directories?

1 members found this post helpful.

Thank you for your helpful reply. _I_ wrote my iptables and firewall scripts and have now checked which modules named in it are available in the default Slackware 13.1 distro. They are all there except iptables_filter, iptables_mangle and iptables_nat. I will read through the appropriate .config script to ensure that these have been compiled embedded as I expect they will.
And yes, I have done squid -z. Much use of the iptables LOG facility has revealed that packets from a web browser on on XP client machine are being redirected to port 3128 and that squid does send the admin page to that browser reporting that the page "/" cannot be found. I deduce that the URL is not being passed correctly to squid. I have also tried removing the REDIRECT commands from the iptables script which, as you know, bypasses squid since port 80 packets should then be forwarded straight through. That produces the web browser's admin page saying that the URL cannot be found.
If you like, I will find a way to post my iptables script here for you to look at.

Probably any module you used before that had IP_ in the name now uses NF instead, with versions for IPv4 and IPv6.

2 members found this post helpful.

Thank you for that list jschiwal.
All now works.
I commented out the instruction which redirected forwarded port 80 packets to port 3128 for SQUID - cutting squid out of the equation. I also did a 'chmod a-x /etc/rc.d/rc.squid'. Then I concentrated on debugging and editing the iptables script.
I don't know what the exact problem was as I finished up doing a semi-redesign of the whole script and eventually, it worked.
I then re-enabled the redirection which supports squid and experimented with squid. I did not realise that squid-3.1.4 is an experimental version but when I did I downloaded squid-3.0.STABLE11, configured and tried to compile it - no luck. I kept getting simple syntax errors (such as a 'const char*' variable requiring a cast to 'char*' in a function call) so I dug out my previusly-working squid-2.3.STABLE4 and installed that and that now works. Sorting out later version problems can wait until I get the meat of the upgrade done.

Gratefully, Peter.

Here's my iptables script.