On Saturday 19 November 2005 00:14, Darryl Gregorash wrote:
It's possible the firewall script has become corrupted. Refresh the SuSEfirewall2 package from the installation media, and restart the firewall. If that doesn't resolve the issue, email your
I copied SuSEfirewall2-3.4-6.noarch.rpm off the DVD, ran "rpm -Uvh --force SuSEfirewall2-3.4-6.noarch.rpm", and rebooted. Nothing changed as far as I could tell. I ran the script you sent me in debug mode, and got a very respectable set of firewall rules for my system -- internal and external interfaces are both network cards, with internal IP fixed and external assigned by DHCP. Both cards are configured at boot time, and the firewall is established when the network is brought up. In your case, the firewall
On 11/19/2005 12:57 PM, Peter A. Taylor wrote: script is being run "on demand", called from the /etc/ppp/if-up script, but otherwise there is no significant difference between our systems. Furthermore, there is no essential difference between our firewall configuration files. So long as "modem0" is a link to a defined PPP device (and I assume you would be unable to dail out if it were not), your firewall should be getting set up properly. I stated earlier that the masquerading subroutine is being executed, but only the rules for icmp are being established. This was actually not correct, but it is true that the script is executing everything up to, and following, that subroutine. What we need to do is establish whether or not the subroutine is actually being entered. For this, I would like you to make the following cosmetic changes to your /sbin/SuSEfirewall2 script: search for "masquerading_rules()" before the line "for nets in $FW_MASQ_NETS; do" add the following lines: echo IN MASQ ROUTINE sleep 5 save Run "/sbin/SuSEfirewall2 debug". Don't walk away, because you only have 5 seconds to see if that line actually does get echoed to the screen :) The only way those two lines will never execute is if your FW_MASQUERADE variable in /etc/sysconfig/SuSEfirewall2 is not strictly equal to "yes". Given your previous posts, this would imply the presence of a non-printing character in the string (there are no typographical errors in firewall script or config file). Therefore, before trying this test, you might want to edit the value of FW_MASQUERADE in your firewall config file. I would suggest deleting the entire line including end-of-line, as well as the end-of-line on the preceding line; then simply re-open the file and replace all the missing text. And if **that** doesn't work, my prematurely grey hair will begin to fall out, I am sure.
Is there some way that a hardware problem could be causeing masquerade to choke under one OS but not another? This computer was inside a house that
No, because the firewall script does not actually care whether or not a device is even configured. In truth, though I have never checked, I am not sure the device even needs to exist; all the firewall script does is write a bunch of stuff into kernel memory, and for that, only the netfilter modules are strictly necessary.
USE_IPV6=yes
This is part of the network config file, and should have no effect on the firewall (I do wish that one variable would turn IPv6 on/off globally, but that is up to the folx at SuSE). However, you have IPv6 turned off everywhere else, and you may with to turn it off here as well. I don't know what effect, if any, the missing quote marks might have; as far as I know, they are only critical if your string is null.