similar to: Another Little Patch

Let''s move this to the Shorewall Development list.... On Tuesday 10 February 2004 03:14 pm, xavier wrote: > here is a patch to allow this : > |ACCEPT<10/sec:20>:debug fw lan:$ntp_servers udp 123 - - - - ntp > > a problem with the patch is that now the logprefix is mandatory. > i''m trying to debug it, but i can''t find the flaw. Also, with

hello , i''m currently trying to set-up Traffic Shapping with Shorewall and I have strong feelings that I found a bug. I may be mistaken, but I tried everything and can''t get it to work. I''ve turned ON TC_ENABLED=Yes and CLEAR_TC=Yes when i start shorewall ( shorewall start ), i get this message : Setting up Traffic Control Rules... TC Rule "2 eth1 0.0.0.0/0 tcp

I think you can change the existing firewall logging code for log_rule_limit (where you have one case for for LOGRULENUMBERS and another almost identical case without) down to this slightly shorter version with no duplication (excerpt): if [ -n "$LOGRULENUMBERS" ]; then eval rulenum=\$${chain}_logrules [ -z "$rulenum" ] && rulenum=1 fi case

This is a minor release of Shorewall. WARNING: This release introduces incompatibilities with prior releases. See http://www.shorewall.net/upgrade_issues.htm. Changes are: a) There is now a new NONE policy specifiable in /etc/shorewall/policy. This policy will cause Shorewall to assume that there will never be any traffic between the source and destination zones. b) Shorewall no longer

I am getting the following message when Shorewall stops can anybody shed any light on this message and where I should be looking? Thanks root@bobshost:~# shorewall stop Loading /usr/share/shorewall/functions... Processing /etc/shorewall/params ... Processing /etc/shorewall/shorewall.conf... Loading Modules... Stopping Shorewall...Processing /etc/shorewall/stop ... IP Forwarding Enabled

Dear list members, Masquerading does''not work for me. This is a Mandrake Linux 10 system, but I use another kernel, that included in the original distribution (original: 2.6.3, now used 2.6.8 because of a lot of suck with OpenSwan with kernels prior 2.6.4). The problem seems to be similar or identical mentioned here:

Dears, I have the below code for metropolis of the GLM logit (logistic regression) using a flat prior. Can someone help me modify the prior so that the model becomes hierarchical by using a flat prior for mu and sigma, the derived density for beta ~ N(mu, sigma^2)? Actually I took my code from a teacher that posted on the internet and modified it to the GLM logit but I can't adapt it to the

The rule: ACCEPT loc $FW::3128 tcp www doesn''t work propertly, the http access does not redirect to squid but directly exit. what''s wrong? Thanks ------- Dario Lesca (d.lesca@ivrea.osra.it) -------------------------------------- @@@@@@@ this is my shorewall-1.2.13 config: #[/etc/shorewall/common.def]-----------------------------------------------

I''m beginning to believe that the use of the last column in the rules file to designate redirection/forwarding is too subtle for many users. For 1.3, I think I''ll do something like the following: Current rule: ACCEPT net loc:192.168.1.3 tcp 80 - all New rule: FORWARD net loc:192.168.1.3 tcp 80 Current rule: ACCEPT net fw::3128 tcp 80 - all New rule: REDIRECT net

I got the fail2ban from epel. There were a number of issues relating to using a log file... logwatch was looking for both fail2ban and fail2ban.log logrotate file fail2ban added looked for fail2ban.log and then reset itself to syslog fail2ban itself went to syslog, over riding its fail2ban.log. took a while, but I use /var/log/fail2ban now, that finally worked through logrotates and logwatch.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Macklem wrote: | Tom, | | As I said in a previous mail, these rules file changes work. Thanks. | | However, I''m not sure that your firewall changes to handle the GATEWAY column in the tunnels file does work. I downloaded the most recent STABLE2 release from CVS and replaced my copy of the firewall script with the updated version

It seems to me that ipsecnat tunnel type is not complete. Latest drafts of ipsec nat-traversal use udp port 4500 for nat-traversal communications. (It''s called port floating). That is needed to get rid of ugly ipsec passthru devices. Now ipsecnat opens port udp/500 from any source port. And I think ipsecnat won''t work at all with gw zone defined? I''m not sure about

Marta, As Alan pointed out the loc->net policy is Continue, it should probably be loc->net ACCEPT. This is from Tom''s Shorewall Documentation... http://www.shorewall.net/Documentation.htm#Policy CONTINUE - The connection is neither ACCEPTed, DROPped nor REJECTed. CONTINUE may be used when one or both of the zones named in the entry are sub-zones of or intersect with another zone.

I have the problem when my localnetwork do telnet to the net Shorewall:FORWARD:REJECT:IN=eth0 OUT=eth2 my files are the following: policy #SOURCE DEST POLICY LOG LEVEL LIMIT:BURST loc net CONTINUE info loc fw ACCEPT info loc loc ACCEPT loc dmz ACCEPT info fw

Dear All, After installing Shorewall, on a router with 4 NIC, seems running ok. Next day, when connecting from clients, (MS) we keep getting ip conflict for non-conflicting ip addresses. Any help is appreciated. Detals of Startup: + shift + nolock= + ''['' 1 -gt 1 '']'' + trap ''my_mutex_off; exit 2'' 1 2 3 4 5 6 9 + command=start +

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head><meta http-equiv="content-type" content="text/html; charset=utf-8" /><style type="text/css"><!-- #msg dl { border: 1px #006 solid; background: #369; padding:

And it looks like there''s a bug. I have a "firewall" with a single ethernet interface that splits into a network zone and a local zone and as a consequence I have a hosts file with the following in it: net eth0:!192.168.0.0/24 loc eth0:192.168.0.0/24 When I run shorewall start, I get an error, running in debug mode and capturing the output give me: + run_iptables -A

Hello everybody, To make all clear; I am newbee in shorewall, but... I''ve tried to connect two computers by Mandrake Connection Sharing facility. (Mandrake 9.1). Briefly, the problem is that after all that auto-configuration activities the network is completely down, just because shorewall. The result of calling `shorewall debug start` by hand is available at the end of the

The first 1.4.0 Beta is now available at: http://www.shorewall.net/pub/shorewall/Beta ftp://ftp.shorewall.net/pub/shorewall/Beta Function from 1.3 that has been omitted from this version includes: 1) The MERGE_HOSTS variable in shorewall.conf is no longer supported. Shorewall 1.4 behavior is the same as 1.3 with MERGE_HOSTS=Yes. 2. Interface names of the form

Another bug with similar symptoms to the last one has been found by Renato Tirol. The bug fixed by the earlier errata update affects the following options: dhcp dropunclean logunclean norfc1918 routefilter multi filterping noping The bug reported by Renato and fixed in the current errata update affects: routestopped The new update is available at: