I had not planned on another Beta, but the work that I''ve been doing
with Simple Traffic Shaping has been so promising that I want to get it
into the 4.4.13 release.
New Features:
1) The OPTIONS column in the blacklists file may now be a comma-
separated list of ''to'' and ''from''.
Duplicates are ignored with a
warning message.
2) There is now an OUT-BANDWIDTH column in
/etc/shorewall/tcinterfaces.
The format of this column is:
<rate>[:[<burst>][:[<latency>][:[<peak>][:[<minburst>]]]]]
These terms are described in tc-tbf(8). Shorewall supplies default
values as follows:
<burst> = 10kb
<latency> = 200ms
The remaining options are defaulted by tc.
3) The IN-BANDWIDTH column in both /etc/shorewall/tcdevices and
/etc/shorewall/tcinterfaces now accepts an optional burst parameter.
<rate>[:<burst>]
The default burst is 10kb. A larger burst can help make the <rate>
more accurate; often for fast lines, the enforced rate is well
below the specified <rate>.
Problems Corrected:
1) Avoid an Internal Error when a ''to'' blacklist entry occurs
and
there are no type-2 blacklisted interfaces.
2) When a comma-separated list of ''src'' and/or
''dst'' was specified in
an ipset invocation (e.g., "+fooset[src,src]), all but the first
''src'' or ''dst'' was previously ignored
when generating the resulting
iptables rule.
3) Beginning with Shorewall 4.4.9, the SAME target in tcrules has
generated invalid iptables (ip6tables) input. That target now
generates correct input.
4) Ipsets associated with ''dynamic'' zones were being created
during
''restart'' but not during ''start''.
-Tom
--
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
> 1) The OPTIONS column in the blacklists file may now be a comma- > separated list of ''to'' and ''from''. Duplicates are ignored with a > warning message. >I am trying to use this (with ipsets and "from,to" specified in the options column), but I don''t think it works! I looked at "shorewall show" and the only difference I can spot (between using no option and "from,to" in the option column) is one additional chain (blocklist I think it was called), which is only referenced by eth0_fwd, which in itself has 0 references. Trying to initiate a connection to a banned address "succeeds" (it is stopped by the "manual" drop statements I have in my fw2net chain). I remember you mentioned something about blocklist=1 and blocklist=2, but there is nothing in "man shorewall.conf" or "man blacklist". ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
Tom
A ''shorewall clear'' produces the following messages:
/var/lib/shorewall/firewall: line 608: setpolicy: command not found
/var/lib/shorewall/firewall: line 609: setpolicy: command not found
/var/lib/shorewall/firewall: line 610: setpolicy: command not found
The appropriate lines from /var/lib/shorewall/firewall:
clear_firewall() {
stop_firewall
setpolicy INPUT ACCEPT
setpolicy FORWARD ACCEPT
setpolicy OUTPUT ACCEPT
----------------------------------------------------------------------------
Steven.
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
On 9/14/10 1:07 PM, Mr Dash Four wrote:> >> 1) The OPTIONS column in the blacklists file may now be a comma- >> separated list of ''to'' and ''from''. Duplicates are ignored with a >> warning message. >> > I am trying to use this (with ipsets and "from,to" specified in the > options column), but I don''t think it works!It''s broken in Beta 4.> > I looked at "shorewall show" and the only difference I can spot (between > using no option and "from,to" in the option column) is one additional > chain (blocklist I think it was called), which is only referenced by > eth0_fwd, which in itself has 0 references. Trying to initiate a > connection to a banned address "succeeds" (it is stopped by the "manual" > drop statements I have in my fw2net chain). > > I remember you mentioned something about blocklist=1 and blocklist=2, > but there is nothing in "man shorewall.conf" or "man blacklist".Man shorewall-interfaces. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
On 9/14/10 1:16 PM, Steven Jan Springl wrote:> Tom > > A ''shorewall clear'' produces the following messages: > > /var/lib/shorewall/firewall: line 608: setpolicy: command not found > /var/lib/shorewall/firewall: line 609: setpolicy: command not found > /var/lib/shorewall/firewall: line 610: setpolicy: command not found > > The appropriate lines from /var/lib/shorewall/firewall: > > clear_firewall() { > stop_firewall > > setpolicy INPUT ACCEPT > setpolicy FORWARD ACCEPT > setpolicy OUTPUT ACCEPTCrap -- and I grepped for setpolicy() before deleting it. The attached patch restores it. Thanks, -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
On 9/14/10 1:40 PM, Tom Eastep wrote:> On 9/14/10 1:16 PM, Steven Jan Springl wrote: >> Tom >> >> A ''shorewall clear'' produces the following messages: >> >> /var/lib/shorewall/firewall: line 608: setpolicy: command not found >> /var/lib/shorewall/firewall: line 609: setpolicy: command not found >> /var/lib/shorewall/firewall: line 610: setpolicy: command not found >> >> The appropriate lines from /var/lib/shorewall/firewall: >> >> clear_firewall() { >> stop_firewall >> >> setpolicy INPUT ACCEPT >> setpolicy FORWARD ACCEPT >> setpolicy OUTPUT ACCEPT > > Crap -- and I grepped for setpolicy() before deleting it. The attached > patch restores it.Hold on a moment -- I think that patch is broken. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
On 9/14/10 1:46 PM, Tom Eastep wrote:> On 9/14/10 1:40 PM, Tom Eastep wrote: >> On 9/14/10 1:16 PM, Steven Jan Springl wrote: >>> Tom >>> >>> A ''shorewall clear'' produces the following messages: >>> >>> /var/lib/shorewall/firewall: line 608: setpolicy: command not found >>> /var/lib/shorewall/firewall: line 609: setpolicy: command not found >>> /var/lib/shorewall/firewall: line 610: setpolicy: command not found >>> >>> The appropriate lines from /var/lib/shorewall/firewall: >>> >>> clear_firewall() { >>> stop_firewall >>> >>> setpolicy INPUT ACCEPT >>> setpolicy FORWARD ACCEPT >>> setpolicy OUTPUT ACCEPT >> >> Crap -- and I grepped for setpolicy() before deleting it. The attached >> patch restores it. > > Hold on a moment -- I think that patch is broken.Yes -- it was. I managed to delete something in the corrected file before generating the patch. This one should work. You will have to ''shorewall compile'' before ''shorewall clear''. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
On 9/14/10 1:18 PM, Tom Eastep wrote:> On 9/14/10 1:07 PM, Mr Dash Four wrote: >> >>> 1) The OPTIONS column in the blacklists file may now be a comma- >>> separated list of ''to'' and ''from''. Duplicates are ignored with a >>> warning message. >>> >> I am trying to use this (with ipsets and "from,to" specified in the >> options column), but I don''t think it works! > > It''s broken in Beta 4.And it appears that very simple cases are also broken in Beta 5 :-( I''ll take a look. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
> And it appears that very simple cases are also broken in Beta 5 :-( > > I''ll take a look. >Tom, wouldn''t be easier if you include the blacklst chain at the beginning of each configured device/zone depending on the ''from,to'' options in the blacklist file? You did it, unidirectionally, with ''from'', all it needs to be done is include that part of the code, but at the other end of the chains, or am I simplifying it a bit here - is there more to it? ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
On 9/14/10 2:07 PM, Tom Eastep wrote:> On 9/14/10 1:18 PM, Tom Eastep wrote: >> On 9/14/10 1:07 PM, Mr Dash Four wrote: >>> >>>> 1) The OPTIONS column in the blacklists file may now be a comma- >>>> separated list of ''to'' and ''from''. Duplicates are ignored with a >>>> warning message. >>>> >>> I am trying to use this (with ipsets and "from,to" specified in the >>> options column), but I don''t think it works! >> >> It''s broken in Beta 4. > > And it appears that very simple cases are also broken in Beta 5 :-( > > I''ll take a look.The attached patch seems to correct this for simple configs. patch /usr/share/shorewall/Shorewall/Rules < BLACKLIST.patch Expect offset warnings. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
On 9/14/10 2:22 PM, Mr Dash Four wrote:> >> And it appears that very simple cases are also broken in Beta 5 :-( >> >> I''ll take a look. >> > Tom, wouldn''t be easier if you include the blacklst chain at the > beginning of each configured device/zone depending on the ''from,to'' > options in the blacklist file? You did it, unidirectionally, with > ''from'', all it needs to be done is include that part of the code, but at > the other end of the chains, or am I simplifying it a bit here - is > there more to it?There''s more to it. ''blacklist'' is not a zone attribute. It is a host-group attribute( See shorewall-hosts(5) ). I regret that it was initially implemented that way but it was and I need to maintain compatibility. At any rate, the patch I just posted corrects the problem. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
On Tuesday 14 September 2010 21:49:53 Tom Eastep wrote:> On 9/14/10 1:46 PM, Tom Eastep wrote: > > On 9/14/10 1:40 PM, Tom Eastep wrote: > >> On 9/14/10 1:16 PM, Steven Jan Springl wrote: > >>> Tom > >>> > >>> A ''shorewall clear'' produces the following messages: > >>> > >>> /var/lib/shorewall/firewall: line 608: setpolicy: command not found > >>> /var/lib/shorewall/firewall: line 609: setpolicy: command not found > >>> /var/lib/shorewall/firewall: line 610: setpolicy: command not found > >>> > >>> The appropriate lines from /var/lib/shorewall/firewall: > >>> > >>> clear_firewall() { > >>> stop_firewall > >>> > >>> setpolicy INPUT ACCEPT > >>> setpolicy FORWARD ACCEPT > >>> setpolicy OUTPUT ACCEPT > >> > >> Crap -- and I grepped for setpolicy() before deleting it. The attached > >> patch restores it. > > > > Hold on a moment -- I think that patch is broken. > > Yes -- it was. I managed to delete something in the corrected file > before generating the patch. > > This one should work. You will have to ''shorewall compile'' before > ''shorewall clear''. > > -TomTom That''s fixed it. Thanks. Steven. ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
> There''s more to it. ''blacklist'' is not a zone attribute. It is a > host-group attribute( See shorewall-hosts(5) ). I regret that it was > initially implemented that way but it was and I need to maintain > compatibility. >OK, I applied the patch, checked and had eth0_out with ''blackout'' as the first ref. entry and in it I had the blacklisted ipsets as expected. Did a dry run and tried to connect to a blacklisted address and it worked. Now for the confusing bits: eth0 in ''interfaces'' has ''blacklist'' option set (NO numbers). So, according to shorewall-interfaces I wouldn''t be allowed to use blacklisted features on packets originating from that interface, but as you can read above - it works. The whole thing is VERY confusing - I should have at least some sort of ''fool-proof'' system in place, which should prevent me from using daft combinations like selecting blacklist=1 and then using the "to" option in the blacklist file and vice versa. Also, the man shorewall-interface does not specify what happens if I select blacklist=2 with regards to incoming packets - by reading it I am assuming that blacklist=2 stops ONLY outgoing packets, but not incoming. If that is not the case it should make it clear. Or am I supposed to use "blacklist=1,blacklist=2" if I want packets to be stopped in both directions? As I pointed out - it is very confusing and these things should be made clear. ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
> The attached patch seems to correct this for simple configs. > > patch /usr/share/shorewall/Shorewall/Rules < BLACKLIST.patch > > Expect offset warnings. >OK, I just tried blacklist=2 to see what the effect is going to be (I have both from,to in my blacklist options). The result - total breakdown! I do not have blacklist chain any more, I do have eth0_out, but it has 0 references, so it is not linked anywhere and connecting to blacklisted address is stopped manually from my statements in fw2net. Using blacklist=1 has the same effect as with blacklist (see my previous post). ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
On 9/14/10 4:01 PM, Mr Dash Four wrote:> >> The attached patch seems to correct this for simple configs. >> >> patch /usr/share/shorewall/Shorewall/Rules < BLACKLIST.patch >> >> Expect offset warnings. >> > OK, I just tried blacklist=2 to see what the effect is going to be (I > have both from,to in my blacklist options). The result - total > breakdown! I do not have blacklist chain any more, I do have eth0_out, > but it has 0 references, so it is not linked anywhere and connecting to > blacklisted address is stopped manually from my statements in fw2net. > > Using blacklist=1 has the same effect as with blacklist (see my previous > post).Good -- it is supposed to. Please don''t give me any more feedback until you have installed Beta 5. At this point, I don''t need any more rants about Beta 4. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
> Please don''t give me any more feedback until you have installed Beta 5. > At this point, I don''t need any more rants about Beta 4. >FYI "shorewall version" returns "4.4.13-Beta5" ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
On 9/14/10 4:24 PM, Mr Dash Four wrote:> >> Please don''t give me any more feedback until you have installed Beta 5. >> At this point, I don''t need any more rants about Beta 4. >> > FYI "shorewall version" returns "4.4.13-Beta5"Okay -- then I''m going to have to learn something about your configuration to make any progress with your issues. The output of ''shorewall dump'' as an attachment is best. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
On 9/14/10 3:37 PM, Mr Dash Four wrote:> >> There''s more to it. ''blacklist'' is not a zone attribute. It is a >> host-group attribute( See shorewall-hosts(5) ). I regret that it was >> initially implemented that way but it was and I need to maintain >> compatibility. >> > OK, I applied the patch, checked and had eth0_out with ''blackout'' as the > first ref. entry and in it I had the blacklisted ipsets as expected. Did > a dry run and tried to connect to a blacklisted address and it worked. > Now for the confusing bits: > > eth0 in ''interfaces'' has ''blacklist'' option set (NO numbers). So, > according to shorewall-interfaces I wouldn''t be allowed to use > blacklisted features on packets originating from that interface, but as > you can read above - it works. > > The whole thing is VERY confusing - I should have at least some sort of > ''fool-proof'' system in place, which should prevent me from using daft > combinations like selecting blacklist=1 and then using the "to" option > in the blacklist file and vice versa.That''s not daft. It is very reasonable. Please read the man page again. And also please note that during Betas (especially), the latest documentation is always available at http://ipv6.shorewall.net/Documentation.html (has an A record as well as AAAA). -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
On 9/14/10 4:40 PM, Tom Eastep wrote:> On 9/14/10 3:37 PM, Mr Dash Four wrote: >> >>> There''s more to it. ''blacklist'' is not a zone attribute. It is a >>> host-group attribute( See shorewall-hosts(5) ). I regret that it was >>> initially implemented that way but it was and I need to maintain >>> compatibility. >>> >> OK, I applied the patch, checked and had eth0_out with ''blackout'' as the >> first ref. entry and in it I had the blacklisted ipsets as expected. Did >> a dry run and tried to connect to a blacklisted address and it worked. >> Now for the confusing bits: >> >> eth0 in ''interfaces'' has ''blacklist'' option set (NO numbers). So, >> according to shorewall-interfaces I wouldn''t be allowed to use >> blacklisted features on packets originating from that interface, but as >> you can read above - it works. >> >> The whole thing is VERY confusing - I should have at least some sort of >> ''fool-proof'' system in place, which should prevent me from using daft >> combinations like selecting blacklist=1 and then using the "to" option >> in the blacklist file and vice versa. > > That''s not daft. It is very reasonable. > > Please read the man page again. And also please note that during Betas > (especially), the latest documentation is always available at > http://ipv6.shorewall.net/Documentation.html (has an A record as well as > AAAA).Hopefully this will help. Here''s a simple example of a two-interface Shorewall box. /etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST OPTIONS net eth0 detect ...,blacklist=1 loc eth1 detect ...,blacklist=2 /etc/shorewall/blacklist: #ADDRESS PROTO PORT(S) OPTIONS 1.2.3.4 - - to,from So eth0 is the internet-facing interface and eth1 is local. -A INPUT -j accounting -A INPUT -m conntrack --ctstate NEW,INVALID -j dynamic -A INPUT -i eth0 -j net2fw ... -A net2fw -m conntrack --ctstate NEW,INVALID -j blacklst So packets from the net addressed to the firewall go through ''blacklst''. -A FORWARD -j accounting -A FORWARD -m conntrack --ctstate NEW,INVALID -j dynamic -A FORWARD -i eth0 -o eth1 -j net2loc -A FORWARD -i eth1 -o eth0 -j loc2net ... -A net2loc -m conntrack --ctstate NEW,INVALID -j blacklst So packets from the net addressed to local hosts go through ''blacklst''. -A loc2net -m conntrack --ctstate NEW,INVALID -j blackout So packets from the local net address to Internet hosts go through ''blackout''. -A OUTPUT -j accounting -A OUTPUT -o eth0 -j eth0_out ... -A eth0_out -m conntrack --ctstate NEW,INVALID -j blackout So packets originating on the firewall and going out eth0 are passed through ''blackout''. -A blacklst -s 1.2.3.4 -j DROP -A blackout -d 1.2.3.4 -j DROP So ''blacklst'' drops packets from 1.2.3.4 and ''blackout'' drops packets to 1.2.3.4. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
> Okay -- then I''m going to have to learn something about your > configuration to make any progress with your issues. The output of > ''shorewall dump'' as an attachment is best. >See attached. ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
> Hopefully this will help. Here''s a simple example of a two-interface > Shorewall box. >So, if I have eth0 and want all traffic from AND to eth0 to pass through my blacklist what do I do, in simple terms, without the need to resort to ugly DROP statements in my rules file to rely on to do the job? ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
On 9/14/10 5:23 PM, Mr Dash Four wrote:> >> Hopefully this will help. Here''s a simple example of a two-interface >> Shorewall box. >> > So, if I have eth0 and want all traffic from AND to eth0 to pass through > my blacklist what do I do, in simple terms, without the need to resort > to ugly DROP statements in my rules file to rely on to do the job?Set blacklist=1 on eth0. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
On 9/14/10 5:16 PM, Mr Dash Four wrote:> >> Okay -- then I''m going to have to learn something about your >> configuration to make any progress with your issues. The output of >> ''shorewall dump'' as an attachment is best. >> > See attached.Working as designed. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
> Set blacklist=1 on eth0. >Right, so in other words blacklist=2 only blocks forwarded traffic passing through this interface destined to nets in the blacklist with the ''to'' option. Wouldn''t it be easier to just use ''fwd'' as the blacklist option - ''to'' with blacklist=2 is very different from ''to'' and blacklist=1, you can just have ''blacklist'' and choose between ''from'',''to'' (as if blacklist=1) and, say, ''fwd'' (as if blacklist=2) - no need for so many permutations when these 3 options in the blacklist file alone will cover everything you''ll ever need. As I wrote previously - confusing. ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
> Working as designed. >So, I assume that because my eth0 is not ''forwarded'' I have precisely zero references to the eth0_out chain, right? Also, try "blacklist=1,blacklist=2" in the interfaces and see what happens. ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
On 9/14/10 5:53 PM, Mr Dash Four wrote:> >> Working as designed. >> > So, I assume that because my eth0 is not ''forwarded'' I have precisely > zero references to the eth0_out chain, right? Also, try > "blacklist=1,blacklist=2" in the interfaces and see what happens.Presumably, it works like blacklist=2.... -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
On 9/14/10 5:51 PM, Mr Dash Four wrote:> >> Set blacklist=1 on eth0. >> > Right, so in other words blacklist=2 only blocks forwarded traffic > passing through this interface destined to nets in the blacklist with > the ''to'' option. Wouldn''t it be easier to just use ''fwd'' as the > blacklist option - ''to'' with blacklist=2 is very different from ''to'' and > blacklist=1, you can just have ''blacklist'' and choose between > ''from'',''to'' (as if blacklist=1) and, say, ''fwd'' (as if blacklist=2) - no > need for so many permutations when these 3 options in the blacklist file > alone will cover everything you''ll ever need. As I wrote previously - > confusing.Luckily, with your one-interface, two-zone configuration, you won''t have an opportunity to use the confusing blacklist=2 setting. It is designed for internal interfaces, and given that you don''t have any internal interfaces, it shouldn''t be a problem for you. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
On 9/14/10 7:33 AM, Tom Eastep wrote:> > 3) The IN-BANDWIDTH column in both /etc/shorewall/tcdevices and > /etc/shorewall/tcinterfaces now accepts an optional burst parameter. > > <rate>[:<burst>] > > The default burst is 10kb. A larger burst can help make the <rate> > more accurate; often for fast lines, the enforced rate is well > below the specified <rate>. >I just noticed that the code to add this feature to tcdevices is missing from Beta 5. You can find it in commit ba89ec39b53a8f158252356f844d704ca87b670e. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
>> So, I assume that because my eth0 is not ''forwarded'' I have precisely >> zero references to the eth0_out chain, right? Also, try >> "blacklist=1,blacklist=2" in the interfaces and see what happens. >> > > Presumably, it works like blacklist=2.... >It should have been picked as a syntax error (I could have used something like "blacklist=1,routefilter,blacklist,blacklist=2" and that should not be allowed). ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
> Luckily, with your one-interface, two-zone configuration, you won''t have > an opportunity to use the confusing blacklist=2 setting. It is designed > for internal interfaces, and given that you don''t have any internal > interfaces, it shouldn''t be a problem for you. >And you know this how exactly? The fact that I am testing on "one-interface two-zone" machine should not matter one bit. Perhaps if you do not like my configuration or my testing methods you should pick up somebody else with more suitable configuration that you are happy with? ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
On 09/15/2010 02:10 PM, Mr Dash Four wrote:> >>> So, I assume that because my eth0 is not ''forwarded'' I have precisely >>> zero references to the eth0_out chain, right? Also, try >>> "blacklist=1,blacklist=2" in the interfaces and see what happens. >>> >> >> Presumably, it works like blacklist=2.... >> > It should have been picked as a syntax error (I could have used > something like "blacklist=1,routefilter,blacklist,blacklist=2" and that > should not be allowed).Fixed it yesterday. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
On 9/15/10 2:13 PM, Mr Dash Four wrote:> >> Luckily, with your one-interface, two-zone configuration, you won''t have >> an opportunity to use the confusing blacklist=2 setting. It is designed >> for internal interfaces, and given that you don''t have any internal >> interfaces, it shouldn''t be a problem for you. >> > And you know this how exactly? > > The fact that I am testing on "one-interface two-zone" machine should > not matter one bit. Perhaps if you do not like my configuration or my > testing methods you should pick up somebody else with more suitable > configuration that you are happy with?I have no problem with either your configuration or your testing methods, although I do find your "brick in the face" style of raising issues and pointing out perceived shortcomings to be rather tiresome. I don''t want to delay 4.4.13 any longer with this blacklisting issue. So what I''m going to do is to return Shorewall blacklisting to its 4.4.11 state (no OPTIONS column in the blacklist files) and when I find the time and energy to tackle this problem again, I''ll take all of your objections and suggestions into account. Regards, -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev