Shorewall users - Nov 2007 - [Fwd: Re: Shorewall 3.2.9 (Etch) 2 providers and traffic shaping]

Thanks, Jerry.

Cristian -- there is certainly something inconsistent in the numbering of
the providers between the working and non-working configurations.

-Tom

-------- Original Message --------
Subject: Re: [Shorewall-users] Shorewall 3.2.9 (Etch) 2 providers and
traffic shaping
Date: Tue, 06 Nov 2007 13:51:25 -0500
From: Jerry Vonau <jvonau@shaw.ca>
To: Tom Eastep <teastep@shorewall.net>
References: <472F2E9E.7020306@shorewall.net>
<472F61C8.4010103@sengo.net>
<47308943.8080307@shorewall.net>

Hi Tom:
> The only difference that I see in the two is that, because you
haven''t
> applied the patch which corrects a problem with HIGH_ROUTE_MARKS=No (see
> http://www.shorewall.net/shorewall_index.htm#Notice), your working
> configuration is operating as if you had set TC_EXPERT=Yes. So, grasping at
> straws, you might set TC_EXPERT=Yes in the non-working configuration and
see
> if that makes any difference.
> 
> Jerry: Do you see anything in Cristian''s dumps?
> 
The only thing that jumps out at me is the route rules between the
working/non-working configs:

Routing Rules working

0:	from all lookup 255
10001:	from all fwmark 0x1 lookup smrt2 <<<<<<
10002:	from all fwmark 0x2 lookup fweb1 <<<<<<
10256:	from all fwmark 0x100 lookup smrt2
10512:	from all fwmark 0x200 lookup fweb1
20256:	from 82.104.128.42 lookup smrt2
20257:	from 82.104.128.43 lookup smrt2
20258:	from 82.104.128.44 lookup smrt2
20512:	from 21.244.102.218 lookup fweb1
32766:	from all lookup main
32767:	from all lookup default

Routing Rules non working

0:	from all lookup 255
10001:	from all fwmark 0x1 lookup fweb1 <<<<<<
10002:	from all fwmark 0x2 lookup 3  <<<<<<
10256:	from all fwmark 0x100 lookup fweb1
10512:	from all fwmark 0x200 lookup smrt2
20000:	from 82.104.128.42 lookup smrt2
20001:	from 82.104.128.43 lookup smrt2
20002:	from 82.104.128.44 lookup smrt2
20256:	from 21.244.102.218 lookup fweb1
32766:	from all lookup main
32767:	from all lookup default

That hoses the track option, right? What''s up with table
"3"(in the
non-working dump), that could be a hang-around-er from not having the
routing rules/tables cleared with that version.

I''d like to see back to back dumps of the working config, after a
network restart, and then adding in the shaping stuff, with a network
restart, just to be sure the base line is the same

The other interesting thing is that the providers are processed in a
different order, the route rules assignment order is changed, could be
just the listing order in the providers file, just not sure from here.

Jerry

-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Il giorno mar, 06/11/2007 alle 11.04 -0800, Tom Eastep ha
scritto:
> Thanks, Jerry.
> 
> Cristian -- there is certainly something inconsistent in the numbering of
> the providers between the working and non-working configurations.
> 
Hi Tom, hi did some cleaning in the config files today, now the
configurations are consistent, but it doesn''t work
anyway.
> 
> > The only difference that I see in the two is that, because you
haven''t
> > applied the patch which corrects a problem with HIGH_ROUTE_MARKS=No
(see
> > http://www.shorewall.net/shorewall_index.htm#Notice), your working
> > configuration is operating as if you had set TC_EXPERT=Yes. So,
grasping at
> > straws, you might set TC_EXPERT=Yes in the non-working configuration
and see
> > if that makes any difference.
I applied the patch as well and set TC_EXPERT=Yes in the non-working
config, but still no go :(
> > Jerry: Do you see anything in Cristian''s dumps?
> > 
> 
> The only thing that jumps out at me is the route rules between the
> working/non-working configs:
> 
> I''d like to see back to back dumps of the working config, after a
> network restart, and then adding in the shaping stuff, with a network
> restart, just to be sure the base line is the same
> 
> The other interesting thing is that the providers are processed in a
> different order, the route rules assignment order is changed, could be
> just the listing order in the providers file, just not sure from here.
> 
> Jerry
Hi Jerry, I can''t net-restart remotely, but I''ll post a dump
of working
and non-working configs after a reboot (should be the same of restarting
the net I guess :))


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Ok, I started all over with a clean 3.2.9 shorewall.conf and dumped the
two configurations. I also noticed that TC_EXPERT=Yes breaks the track
options with the working config, but it does NOT with the other
(HIGH_ROUTE_MARKS=Yes and shaping rules).

I attached the two dumps, each done after a reboot and all my config
files (in the next post) if you want to take a look.

Thanks very much for your time 

Cristian





-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Config files



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Cristian Mammoli wrote:
> Ok, I started all over with a clean 3.2.9 shorewall.conf and dumped the
> two configurations. I also noticed that TC_EXPERT=Yes breaks the track
> options with the working config, but it does NOT with the other
> (HIGH_ROUTE_MARKS=Yes and shaping rules).
> 
> I attached the two dumps, each done after a reboot and all my config
> files (in the next post) if you want to take a look.
> 
> Thanks very much for your time 
How exactly did you test these two configurations and what did you see
that was different between the two? I ask because I don''t see anything
happening in one that isn''t also happening in the other.

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Il giorno mar, 06/11/2007 alle 13.55 -0800, Tom Eastep ha scritto:
> How exactly did you test these two configurations and what did you see
> that was different between the two? I ask because I don''t see
anything
> happening in one that isn''t also happening in the other.
> 
> -Tom
I put the "working" confg files in /etc/shorewall with TC_EXPERT=Yes
and rebooted

I tried to telnet on port 25 from the internet to the dmz host and the
request timed out

I used "traceproto $VARIOUS_INTERNET_HOSTS -p tcp -d 25" from the dmz
host and all the requests got correctly routed through provider smrt1

I set TC_EXPERT=No and rebooted

I tried to telnet on port 25 from the internet to the dmz host and the
request was succesful

I used "traceproto $VARIOUS_INTERNET_HOSTS -p tcp -d 25" from the dmz
host and all the requests got correctly routed through provider smrt1

I changed the MARK number in providers from 1 to 256 and from 2 to 512,
changed the values accordingly in tcrules, added tcdevices and tcclasses
in /etc/shorewall, added the traffic shaping rules at the bottom of
tcrules and rebooted

I tried to telnet on port 25 from the internet to the dmz host and the
request was succesful

I used "traceproto $VARIOUS_INTERNET_HOSTS -p tcp -d 25" from the dmz
host and some requests went out through provider smrt1, some through
fweb1

The behaviour with HIGH_ROUTE_MARKS=1 is the same with TC_EXPERT=Yes and
TC_EXPERT=No

Cristian


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Cristian Mammoli wrote:
> 
> I used "traceproto $VARIOUS_INTERNET_HOSTS -p tcp -d 25" from the
dmz
> host and some requests went out through provider smrt1, some through
> fweb1
Please try the attached patch.

Thanks,
-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Tom Eastep wrote:
> Cristian Mammoli wrote:
> 
>> I used "traceproto $VARIOUS_INTERNET_HOSTS -p tcp -d 25" from
the dmz
>> host and some requests went out through provider smrt1, some through
>> fweb1
> 
> Please try the attached patch.
My belief is that the problem stems from the fact that the compilers use
--or-mark for setting MARK values > 255. This means that if a packet
matches more than one PREROUTING/OUTPUT rule with HIGH_ROUTE_MARKS=Yes,
then the resulting mark value will be the logical product of the mark
values in the matching rules.

Example:

	0x100	192.168.1.44	0.0.0.0/0
	0x200	0.0.0.0/0	0.0.0.0/0	tcp	25

    A TCP packet from 192.168.1.44 with destination port 25 would end
    up with a mark value of 0x300 whereas the expected value is 0x200.

In Cristian''s case, 0x300 is not associated with any provider so
packets
with that mark value are routed by the main table; the result is that
these packets'' connections are balanced between the two providers.

This problem is present in Shorewall versions 3.2, 3.4 and 4.0 (both
Shorewall-shell and Shorewall-perl). Errata patches are available; see:

http://www1.shorewall.net/pub/shorewall/3.2/shorewall-3.2.11/known_problems.txt
http://www1.shorewall.net/pub/shorewall/3.4/shorewall-3.4.7/known_problems.txt
http://www1.shorewall.net/pub/shorewall/4.0/shorewall-4.0.5/known_problems.txt

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

On Nov 7, 2007 5:37 AM, Tom Eastep <teastep@shorewall.net>
wrote:
> Example:
>
>         0x100   192.168.1.44    0.0.0.0/0
>         0x200   0.0.0.0/0       0.0.0.0/0       tcp     25
>
>     A TCP packet from 192.168.1.44 with destination port 25 would end
>     up with a mark value of 0x300 whereas the expected value is 0x200.
If I add a mark for traffic shaping in this case, prior to the above
two rules, making them look like

0x11  192.168.1.44  0.0.0.0/0
0x100   192.168.1.44    0.0.0.0/0
0x200   0.0.0.0/0       0.0.0.0/0       tcp     25

What would be the effect of the patch? Would that mean that the
provider rule over-writes the shaping rule? Or should I be using the
mask?

Thanks,
Prasanna.
-- 
www.elinanetworks.com
Seamless, secure delivery of applications.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Prasanna Krishnamoorthy wrote:
> On Nov 7, 2007 5:37 AM, Tom Eastep <teastep@shorewall.net> wrote:
>> Example:
>>
>>         0x100   192.168.1.44    0.0.0.0/0
>>         0x200   0.0.0.0/0       0.0.0.0/0       tcp     25
>>
>>     A TCP packet from 192.168.1.44 with destination port 25 would end
>>     up with a mark value of 0x300 whereas the expected value is 0x200.
> If I add a mark for traffic shaping in this case, prior to the above
> two rules, making them look like
> 
> 0x11  192.168.1.44  0.0.0.0/0
> 0x100   192.168.1.44    0.0.0.0/0
> 0x200   0.0.0.0/0       0.0.0.0/0       tcp     25
> 
> What would be the effect of the patch? Would that mean that the
> provider rule over-writes the shaping rule? Or should I be using the
> mask?
The above is an invalid set of rules. As always, you should apply routing
marks in the PREROUTING/OUTPUT chains and traffic shaping marks in the
FORWARD and POSTROUTING chains.

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

On Nov 7, 2007 8:35 AM, Tom Eastep <teastep@shorewall.net>
wrote:
> Prasanna Krishnamoorthy wrote:
> > If I add a mark for traffic shaping in this case, prior to the above
> > two rules, making them look like
> >
> > 0x11  192.168.1.44  0.0.0.0/0
> > 0x100   192.168.1.44    0.0.0.0/0
> > 0x200   0.0.0.0/0       0.0.0.0/0       tcp     25
> >
> > What would be the effect of the patch? Would that mean that the
> > provider rule over-writes the shaping rule? Or should I be using the
> > mask?
>
> The above is an invalid set of rules. As always, you should apply routing
> marks in the PREROUTING/OUTPUT chains and traffic shaping marks in the
> FORWARD and POSTROUTING chains.
Thanks for the clarification Tom.

Prasanna
-- 
www.elinanetworks.com
Seamless, secure delivery of applications.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Il giorno mar, 06/11/2007 alle 14.25 -0800, Tom Eastep ha
scritto:
> Cristian Mammoli wrote:
> 
> > 
> > I used "traceproto $VARIOUS_INTERNET_HOSTS -p tcp -d 25"
from the dmz
> > host and some requests went out through provider smrt1, some through
> > fweb1
> 
> Please try the attached patch.
> 
> Thanks,
> -Tom
It seems to work correctly, I''ll do further tests today.

Thanks

Cristian


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/