Hey guys, I''m having a problem trying to use tcclasses / tcrules to shape the traffic here, all traffic is being sent to the default queue regardless of their marking. here''s what I have: tcclasses ############################################### eth1 1 10kbit 256kbit 3 eth1 2 full full 1 default ############################################### tcrules ##################################### 1 192.168.200.1 0.0.0.0/0 all 2 192.168.200.10 0.0.0.0/0 all ###################################### With these rules, everyone uses the full bandwidth... with tcclasses looking like this: ############################################### eth1 1 10kbit 256kbit 3 default eth1 2 full full 1 ############################################### everyone uses 256. Any help would be appreciated! thanks and happy new year guys! Ismael ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Ismael Milach da Silveira wrote:> > > Any help would be appreciated! >First you can help us by submitting the information requested at http://www.shorewall.net/support.htm#Guidelines 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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
ok, there it is... shorewall version - 3.0.1-1 the hosts involved in the connection: from: 192.168.200.1 to: 201.3.160.245 I''ve made some changes but with the same result I''ve previously reported. dump is attached. thanks! ----- Original Message ----- From: "Tom Eastep" <teastep@shorewall.net> To: "Shorewall Users" <shorewall-users@lists.sourceforge.net> Sent: Friday, December 29, 2006 1:56 PM Subject: Re: [Shorewall-users] TC - not marking correctly> ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net''s Techsay panel and you''ll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV--------------------------------------------------------------------------------> _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Ismael Milach da Silveira wrote:> ok, there it is... > > shorewall version - 3.0.1-1 > > the hosts involved in the connection: > from: 192.168.200.1 > to: 201.3.160.245 > > I''ve made some changes but with the same result I''ve previously reported. > > dump is attached. >>From the dump:Mangle Table ... Chain tcfor (1 references) pkts bytes target prot opt in out source destination 0 0 MARK all -- * * 192.168.200.1 0.0.0.0/0 MARK set 0x1 <================== 3 247 MARK all -- * * 192.168.200.10 0.0.0.0/0 MARK set 0x2 Chain tcout (1 references) pkts bytes target prot opt in out source destination Chain tcpost (1 references) pkts bytes target prot opt in out source destination 0 0 CLASSIFY all -- * eth0 0.0.0.0/0 0.0.0.0/0 MARK match 0x1 CLASSIFY set 1:11 3 247 CLASSIFY all -- * eth0 0.0.0.0/0 0.0.0.0/0 MARK match 0x2 CLASSIFY set 1:12 No traffic with source IP address 192.168.200.1 was forwarded by the firewall during the time covered by this dump as evidenced by the zeros in the ''pkts'' column for the rule for that source address. So no traffic was sent to the 1:11 TC class (Regrettably, you are running an old version of Shorewall that does not display traffic shaping information in the dump). -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
odd... i did it again, and it showed some traffic now.
##############################################
[doctor@srvsisdia doctor]$ /sbin/ifconfig
eth0 Link encap:Ethernet HWaddr 00:02:55:58:5E:C6
inet addr:192.168.200.1 Bcast:192.168.200.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:38643181 errors:0 dropped:0 overruns:0 frame:0
TX packets:38547925 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:991136881 (945.2 Mb) TX bytes:197020047 (187.8 Mb)
Interrupt:27 Base address:0x2000
[doctor@srvsisdia doctor]$ wget www.doctornet.com.br/matrix.zip
--15:04:21-- http://www.doctornet.com.br/matrix.zip
=> `matrix.zip.2''
Resolving www.doctornet.com.br... done.
Connecting to www.doctornet.com.br[201.3.160.245]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 199,947,030 [application/zip]
26% [========> ] 52,717,056 58.43K/s ETA
41:00
#########################################
----- Original Message -----
From: "Tom Eastep" <teastep@shorewall.net>
To: "Shorewall Users" <shorewall-users@lists.sourceforge.net>
Sent: Friday, December 29, 2006 3:05 PM
Subject: Re: [Shorewall-users] TC - not marking correctly
> Ismael Milach da Silveira wrote:
>> ok, there it is...
>>
>> shorewall version - 3.0.1-1
>>
>> the hosts involved in the connection:
>> from: 192.168.200.1
>> to: 201.3.160.245
>>
>> I''ve made some changes but with the same result I''ve
previously reported.
>>
>> dump is attached.
>>
>
>>From the dump:
>
> Mangle Table
>
> ...
>
> Chain tcfor (1 references)
> pkts bytes target prot opt in out source
> destination
> 0 0 MARK all -- * * 192.168.200.1
> 0.0.0.0/0 MARK set 0x1 <==================> 3 247 MARK
all -- * * 192.168.200.10
> 0.0.0.0/0 MARK set 0x2
>
> Chain tcout (1 references)
> pkts bytes target prot opt in out source
> destination
>
> Chain tcpost (1 references)
> pkts bytes target prot opt in out source
> destination
> 0 0 CLASSIFY all -- * eth0 0.0.0.0/0
> 0.0.0.0/0 MARK match 0x1 CLASSIFY set 1:11
> 3 247 CLASSIFY all -- * eth0 0.0.0.0/0
> 0.0.0.0/0 MARK match 0x2 CLASSIFY set 1:12
>
> No traffic with source IP address 192.168.200.1 was forwarded by the
> firewall during the time covered by this dump as evidenced by the
> zeros in the ''pkts'' column for the rule for that source
address.
> So no traffic was sent to the 1:11 TC class (Regrettably, you are
> running an old version of Shorewall that does not display traffic
> shaping information in the dump).
>
> -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
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net''s Techsay panel and you''ll get the
chance to share
> your
> opinions on IT & business topics through brief surveys - and earn cash
>
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Shorewall-users mailing list
> Shorewall-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shorewall-users
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net''s Techsay panel and you''ll get the chance
to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Ismael Milach da Silveira wrote:> odd... i did it again, and it showed some traffic now. > > ############################################## > [doctor@srvsisdia doctor]$ /sbin/ifconfig > eth0 Link encap:Ethernet HWaddr 00:02:55:58:5E:C6 > inet addr:192.168.200.1 Bcast:192.168.200.255 Mask:255.255.255.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:38643181 errors:0 dropped:0 overruns:0 frame:0 > TX packets:38547925 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:991136881 (945.2 Mb) TX bytes:197020047 (187.8 Mb) > Interrupt:27 Base address:0x2000 > > [doctor@srvsisdia doctor]$ wget www.doctornet.com.br/matrix.zip > --15:04:21-- http://www.doctornet.com.br/matrix.zip > => `matrix.zip.2'' > Resolving www.doctornet.com.br... done. > Connecting to www.doctornet.com.br[201.3.160.245]:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 199,947,030 [application/zip]Wait a minute -- traffic leaving the firewall through interface eth1 should never have source IP 192.168.200.1 -- it will have destination address 192.168.200.1. So you marking rules are screwed up.... -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
sorry about the mess, I had already tried that before and it didn''t work either... eth0 is external and eth1 internal, I tried to put the same mark for both interfaces, incoming and outgoing, but it really doesn''t make any difference, the traffic always follow the default queue. ----- Original Message ----- From: "Tom Eastep" <teastep@shorewall.net> To: "Shorewall Users" <shorewall-users@lists.sourceforge.net> Sent: Friday, December 29, 2006 3:53 PM Subject: Re: [Shorewall-users] TC - not marking correctly> ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net''s Techsay panel and you''ll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV--------------------------------------------------------------------------------> _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Ismael Milach da Silveira wrote:> sorry about the mess, I had already tried that before and it didn''t work > either... > > eth0 is external and eth1 internal, I tried to put the same mark for both > interfaces, incoming and outgoing, but it really doesn''t make any > difference, the traffic always follow the default queue.a) We don''t know what you are trying to accomplish. b) Your configuration changes between each post. c) Your posts consist largely of "It didn''t work". So d) I can''t help you. -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
a) the config changed only once since the first post, and I reported it. b) what I''m trying to do is quite simple, one IP would have 256 to work with and the other would have all the bandwidth; c) I''m not really saying that you or anyone else should resolve my problem, or even help me in any way if you don''t want to or whatever the reason is, I know I''m doing something wrong, that''s obvious, all I tried to do is posting my problem here so maybe someone could give a tip on what is wrong. d) when I''m saying "it didn''t work", it''s because, well, It didn''t :-) the result I have is the same... anyway, thanks for your time and extensive work with shorewall and have a nice day. Ismael ----- Original Message ----- From: "Tom Eastep" <teastep@shorewall.net> To: "Shorewall Users" <shorewall-users@lists.sourceforge.net> Sent: Friday, December 29, 2006 4:16 PM Subject: Re: [Shorewall-users] TC - not marking correctly> ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net''s Techsay panel and you''ll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV--------------------------------------------------------------------------------> _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Ismael Milach da Silveira wrote:> a) the config changed only once since the first post, and I reported it. > b) what I''m trying to do is quite simple, one IP would have 256 to work with > and the other would have all the bandwidth;And we still don''t know what you are trying to do. Are you trying to limit this one IP to download or upload or both?> c) I''m not really saying that you or anyone else should resolve my problem, > or even help me in any way if you don''t want to or whatever the reason is, I > know I''m doing something wrong, that''s obvious, all I tried to do is posting > my problem here so maybe someone could give a tip on what is wrong.And I gave you that -- under the assumption that you were trying to limit download.> d) when I''m saying "it didn''t work", it''s because, well, It didn''t :-) the > result I have is the same...The devil here is in the details; if you change your configuration as I suggested and it still doesn''t work, then we need to see the details again. But it would sure help if you would upgrade your configuration to at least 3.0.4 so that the output of "dump" includes traffic shaping information. -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Hello, I don''t know if this has any sense as I haven''t read the configuration dump, so I''m exposing myself to the most deserved flames. I just saw that the rule is in "tcfor" and the IP is local so, shouldn''t it be in "tcout" ? It shouldn''t pass through the forward table then, just the output. IF the firewall is routing traffing (thus forwarding and using tcfor) it would only have the local IP as source if you''re doing some kind of NAT, in any other case the src ip should be the localnet''s or the remote''s but not the firewall''s. And even in that case I''d have to check because I don''t know if mangling goes before natting or the other way around. (To know if have to do nat or not you already need to know the output iface, so you should pass forwarding before natting and do natting on postrouting... in which case your forwarding rule shouldn''t work even if natting. Does that have any sense ?) So my guess is that you should mark using iface name and not ip address (for forwarding), or $FW if marking output traffic. Or both, for triple care. But marking for me was a bit more complex than that as I was mixing shaping and different providers (highmarks,routemarks,tcmarks,ormarks,andmarks,setmarks,...) I can''t remember the details, so it could be more complex in this case too. I think the "tcfor" and the "ifconfig" lines with that rule posted... do not fit too well. Hope it helps, and please no flames if I''m lost and wrong. I''m a sensitive guy and could commit suicide at any time. Best regards, Jorge Jorge Daza García-Blanes jorge@drqueue.org - GPG id: 5D7ACDEF P.S.: Tom, why should it have dest ip the local ip ? because that should happen if you receive the traffic, but then marks would only be useful as connmarks but not as tcmarks, wouldn''t they ? On 29/12/2006, at 18:53, Tom Eastep wrote:> Ismael Milach da Silveira wrote: >> odd... i did it again, and it showed some traffic now. >> >> ############################################## >> [doctor@srvsisdia doctor]$ /sbin/ifconfig >> eth0 Link encap:Ethernet HWaddr 00:02:55:58:5E:C6 >> inet addr:192.168.200.1 Bcast:192.168.200.255 Mask: >> 255.255.255.0 >> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 >> RX packets:38643181 errors:0 dropped:0 overruns:0 frame:0 >> TX packets:38547925 errors:0 dropped:0 overruns:0 carrier:0 >> collisions:0 txqueuelen:1000 >> RX bytes:991136881 (945.2 Mb) TX bytes:197020047 (187.8 Mb) >> Interrupt:27 Base address:0x2000 >> >> [doctor@srvsisdia doctor]$ wget www.doctornet.com.br/matrix.zip >> --15:04:21-- http://www.doctornet.com.br/matrix.zip >> => `matrix.zip.2'' >> Resolving www.doctornet.com.br... done. >> Connecting to www.doctornet.com.br[201.3.160.245]:80... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: 199,947,030 [application/zip] > > Wait a minute -- traffic leaving the firewall through interface > eth1 should > never have source IP 192.168.200.1 -- it will have destination address > 192.168.200.1. So you marking rules are screwed up.... > > -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 > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net''s Techsay panel and you''ll get the chance to > share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV________________________________ > _______________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Jorge Daza García-Blanes wrote:> > I just saw that the rule is in "tcfor" and the IP is local so, > shouldn''t it be in "tcout" ?Jorge, You often have to read between the lines when dealing with Shorewall problem reports. The ifconfig output that made you think the IP is local was apparently obtained on a system other than where Shorewall is running. I came to that conclusion by comparing that ifconfig output with the dump attached to the same post. The dump showed the following: 2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc htb qlen 1000 link/ether 00:40:f4:cb:33:75 brd ff:ff:ff:ff:ff:ff inet 201.89.170.10/29 brd 201.89.170.15 scope global eth0 inet6 fe80::240:f4ff:fecb:3375/64 scope link valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:02:55:5e:fa:ff brd ff:ff:ff:ff:ff:ff inet 192.168.200.254/24 brd 192.168.200.255 scope global eth1 inet6 fe80::202:55ff:fe5e:faff/64 scope link valid_lft forever preferred_lft forever So it seems that the traffic in question is arriving on the firewall''s eth0 and being sent through eth1; hence, it will traverse the ''tcfor'' chain. -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Thanks for your non-flaming post Tom, I apologize. Now I''ve read the dump and will try to make a humble second guess, I think that somehow related to my first post. This has been taken from the dump: tcp 6 431999 ESTABLISHED src=192.168.200.1 dst=201.3.160.245 sport=33955 dport=80 src=192.168.200.254 dst=192.168.200.1 sport=3128 dport=33955 [ASSURED] mark=0 use=1 This line looks to me a redirection to a 3128 (squid transparent proxy?), is it ? Then incomming traffic wouldn''t have the proper mark using IP because source address has been changed by the local one, would also fail using iface name... I guess. So my guess is that this would be what I mentioned in the previous email as "natting". If that were correct, my guess is you could either use connection marks on mangle''s prerouting and check for it. Or look for every packet... this might be a bit more complex because incomming traffic generated that way wouldn''t have a known destionation port (comes from 80 but squid [or whoever] wouldn''t be forced to use 3128 as destination port). As we wouldn''t know at that point the destination local address, could also be harder to create exclusions or any other more refined marking rule... I have some theories on why that could also fail even if the masquerade theory is right (basically because you could have two tcp connections). But am I closer now at why it is marking right given the rules ? Now, show no mercy, I decided to live one more day. :) Jorge Daza García-Blanes jorge@drqueue.org - GPG id: 5D7ACDEF On 30/12/2006, at 0:42, Tom Eastep wrote:> Jorge Daza García-Blanes wrote: > >> >> I just saw that the rule is in "tcfor" and the IP is local so, >> shouldn''t it be in "tcout" ? > > Jorge, > > You often have to read between the lines when dealing with Shorewall > problem reports. The ifconfig output that made you think the IP is > local > was apparently obtained on a system other than where Shorewall is > running. I came to that conclusion by comparing that ifconfig output > with the dump attached to the same post. > > The dump showed the following: > > 2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc htb qlen 1000 > link/ether 00:40:f4:cb:33:75 brd ff:ff:ff:ff:ff:ff > inet 201.89.170.10/29 brd 201.89.170.15 scope global eth0 > inet6 fe80::240:f4ff:fecb:3375/64 scope link > valid_lft forever preferred_lft forever > 3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 > link/ether 00:02:55:5e:fa:ff brd ff:ff:ff:ff:ff:ff > inet 192.168.200.254/24 brd 192.168.200.255 scope global eth1 > inet6 fe80::202:55ff:fe5e:faff/64 scope link > valid_lft forever preferred_lft forever > > So it seems that the traffic in question is arriving on the firewall''s > eth0 and being sent through eth1; hence, it will traverse the > ''tcfor'' chain. > > -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 > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net''s Techsay panel and you''ll get the chance to > share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV________________________________ > _______________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Ok, I''ll try to be more specific this time :-)
Server''s external interface is eth0
Server''s internal iface is eth1
I have squid running on the server.
192.168.200.1 is the local machine I''m testing the rules now.
I have a 512 kbps link that I want to optimize, the main objective will be
later to reserve 256-512 to VPN and "0"-256 to the rest, but now the
only
thing I want to accomplish is to have a default rule with no limitations and
to have an exception to this rule (applied to 192.168.200.1) limitting the
bandwidth usage to 256. I''m trying to limit download...upload really
doesn''t
matter (for now at least, will be important later).
look what I tried to do now, I put a rule limitting all traffic to port 80
to 256, the rest is free...
1 and 2 refer to eth0 (external), 3 and 4 to eth1 (local)
tcrules
#######################################
1 0.0.0.0/0 0.0.0.0/0 tcp 80
2 0.0.0.0/0 0.0.0.0/0 all
3 0.0.0.0/0 0.0.0.0/0 tcp 80
4 0.0.0.0/0 0.0.0.0/0 all
######################################
tcclasses
###############################
eth0 1 128kbps 256kbps 2
eth0 2 full full 1 default
eth1 3 128kbps 256kbps 2
eth1 4 full full 1 default
##############################
tcdevices
###################################
eth0 512kbit 512kbit
eth1 100000kbit 100000kbit
###################################
tried the connection from 192.168.200.1 (local machine)
#####################################
[doctor@srvsisdia doctor]$ wget www.doctornet.com.br/matrix.zip
--09:05:16-- http://www.doctornet.com.br/matrix.zip
=> `matrix.zip.11''
Resolving www.doctornet.com.br... done.
Connecting to www.doctornet.com.br[201.3.160.245]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 199,947,030 [application/zip]
0% [ ] 249,152 59.37K/s ETA
54:44
######################################
It is attached here as status80.txt.bz2
Oh, I did the upgrade.
####
sudint:/etc/shorewall# shorewall version
3.2.6
###
----- Original Message -----
From: "Tom Eastep" <teastep@shorewall.net>
To: "Shorewall Users" <shorewall-users@lists.sourceforge.net>
Sent: Friday, December 29, 2006 6:13 PM
Subject: Re: [Shorewall-users] TC - not marking correctly
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net''s Techsay panel and you''ll get the
chance to share
> your
> opinions on IT & business topics through brief surveys - and earn cash
>
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
--------------------------------------------------------------------------------
> _______________________________________________
> Shorewall-users mailing list
> Shorewall-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shorewall-users
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net''s Techsay panel and you''ll get the chance
to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
On 12/30/06, Ismael Milach da Silveira <ismael@doctornet.com.br> wrote:> tcclasses > ############################### > eth0 1 128kbps 256kbps 2 > eth0 2 full full 1 defaultFor some reason I don''t know why, your actual tcrules are translated thus! Note that the 1:11 is 1024kbit/2048kbit. htb 1:12 is 512kbit/512kbit. htb 1:1 is 512/512. class htb 1:11 parent 1:1 leaf 11: prio 2 quantum 12288 rate 1024Kbit ceil 2048Kbit burst 1627b/8 class htb 1:1 root rate 512000bit ceil 512000bit burst 1563b/8 mpu 0b overhead 0b cburst 1563b/8 class htb 1:12 parent 1:1 leaf 12: prio 1 quantum 6144 rate 512000bit ceil 512000bit burst 1563b/8 Secondly, tcrules ####################################### 1 0.0.0.0/0 0.0.0.0/0 tcp 80 2 0.0.0.0/0 0.0.0.0/0 all 3 0.0.0.0/0 0.0.0.0/0 tcp 80 4 0.0.0.0/0 0.0.0.0/0 all ###################################### If you look at your tcfor, you''ll find that you first mark the outgoing packet as 0x1 and then as 0x3. Since there is no 0x3 for eth0, it goes into default perhaps? Third, you seem to have squid running on 3128, can''t really tell myself though. In which case you need to mark packets from $FW to 0.0.0.0/0 tcp 80, and shorewall automatically puts it in the tcpost. My 2c(entavos in this case :) Prasanna. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
As usual this will be stupid but here I go to show the world I''m able to beat own records.> tcclasses > ############################### > eth0 1 128kbps 256kbps 2 > eth0 2 full full 1 default > > eth1 3 128kbps 256kbps 2 > eth1 4 full full 1 default > ##############################Have you tried ? eth0 1 128kbps 256kbps 1 eth0 2 full full 2 default eth1 1 128kbps 256kbps 1 eth1 2 full full 2 default Also, for some reason I haven''t tried to discover, on my setup same set of rules work with TC_EXPERT=Yes and do not work if changed to No. So I had to set it to "Yes" (no laughs, please). No errors or warnings with neither config... so as it was working and didn''t use more time messing with so many complex interactions, I left it there. And works flawlessly. It''s an amazing tool. Jorge Daza García-Blanes jorge@drqueue.org - GPG id: 5D7ACDEF On 30/12/2006, at 13:12, Ismael Milach da Silveira wrote:> Ok, I''ll try to be more specific this time :-) > > Server''s external interface is eth0 > Server''s internal iface is eth1 > I have squid running on the server. > > 192.168.200.1 is the local machine I''m testing the rules now. > > I have a 512 kbps link that I want to optimize, the main objective > will be later to reserve 256-512 to VPN and "0"-256 to the rest, > but now the only thing I want to accomplish is to have a default > rule with no limitations and to have an exception to this rule > (applied to 192.168.200.1) limitting the bandwidth usage to 256. > I''m trying to limit download...upload really doesn''t matter (for > now at least, will be important later). > > look what I tried to do now, I put a rule limitting all traffic to > port 80 to 256, the rest is free... > > 1 and 2 refer to eth0 (external), 3 and 4 to eth1 (local) > > tcrules > ####################################### > 1 0.0.0.0/0 0.0.0.0/0 tcp 80 > 2 0.0.0.0/0 0.0.0.0/0 all > > 3 0.0.0.0/0 0.0.0.0/0 tcp 80 > 4 0.0.0.0/0 0.0.0.0/0 all > ###################################### > > tcclasses > ############################### > eth0 1 128kbps 256kbps 2 > eth0 2 full full 1 default > > eth1 3 128kbps 256kbps 2 > eth1 4 full full 1 default > ############################## > > tcdevices > ################################### > eth0 512kbit 512kbit > eth1 100000kbit 100000kbit > ################################### > > tried the connection from 192.168.200.1 (local machine) > ##################################### > [doctor@srvsisdia doctor]$ wget www.doctornet.com.br/matrix.zip > --09:05:16-- http://www.doctornet.com.br/matrix.zip > => `matrix.zip.11'' > Resolving www.doctornet.com.br... done. > Connecting to www.doctornet.com.br[201.3.160.245]:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 199,947,030 [application/zip] > > 0% [ ] 249,152 59.37K/ > s ETA 54:44 > ###################################### > > It is attached here as status80.txt.bz2 > > Oh, I did the upgrade. > #### > sudint:/etc/shorewall# shorewall version > 3.2.6 > ### > > > > ----- Original Message ----- From: "Tom Eastep" > <teastep@shorewall.net> > To: "Shorewall Users" <shorewall-users@lists.sourceforge.net> > Sent: Friday, December 29, 2006 6:13 PM > Subject: Re: [Shorewall-users] TC - not marking correctly > > >> --------------------------------------------------------------------- >> ---- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net''s Techsay panel and you''ll get the chance to >> share your >> opinions on IT & business topics through brief surveys - and earn >> cash >> http://www.techsay.com/default.php? >> page=join.php&p=sourceforge&CID=DEVDEV > > > ---------------------------------------------------------------------- > ---------- > > >> _______________________________________________ >> Shorewall-users mailing list >> Shorewall-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/shorewall-users >> <status80.txt.bz2> > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net''s Techsay panel and you''ll get the chance to > share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV________________________________ > _______________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
This line looks to me a redirection to a 3128 (squid transparent proxy?), is it ? Then incomming traffic wouldn''t have the proper mark using IP because source address has been changed by the local one, would also fail using iface name... I guess. **************** I think you''re absolutely correct.. One thing I thought would do the trick was to limit the traffic coming from port 3128 to everywhere, tried that also. The other thing I did was to limit every traffic to dport 80, coming from anywhere, (the dump attached on the previous post). Now, why that didn''t work? Thanks Jorge! Ismael ----- Original Message ----- From: "Jorge Daza García-Blanes" <jorge@drqueue.org> To: "Shorewall Users" <shorewall-users@lists.sourceforge.net> Sent: Saturday, December 30, 2006 6:54 AM Subject: Re: [Shorewall-users] TC - not marking correctly Thanks for your non-flaming post Tom, I apologize. Now I''ve read the dump and will try to make a humble second guess, I think that somehow related to my first post. This has been taken from the dump: tcp 6 431999 ESTABLISHED src=192.168.200.1 dst=201.3.160.245 sport=33955 dport=80 src=192.168.200.254 dst=192.168.200.1 sport=3128 dport=33955 [ASSURED] mark=0 use=1 This line looks to me a redirection to a 3128 (squid transparent proxy?), is it ? Then incomming traffic wouldn''t have the proper mark using IP because source address has been changed by the local one, would also fail using iface name... I guess. So my guess is that this would be what I mentioned in the previous email as "natting". If that were correct, my guess is you could either use connection marks on mangle''s prerouting and check for it. Or look for every packet... this might be a bit more complex because incomming traffic generated that way wouldn''t have a known destionation port (comes from 80 but squid [or whoever] wouldn''t be forced to use 3128 as destination port). As we wouldn''t know at that point the destination local address, could also be harder to create exclusions or any other more refined marking rule... I have some theories on why that could also fail even if the masquerade theory is right (basically because you could have two tcp connections). But am I closer now at why it is marking right given the rules ? Now, show no mercy, I decided to live one more day. :) Jorge Daza García-Blanes jorge@drqueue.org - GPG id: 5D7ACDEF On 30/12/2006, at 0:42, Tom Eastep wrote:> Jorge Daza García-Blanes wrote: > >> >> I just saw that the rule is in "tcfor" and the IP is local so, >> shouldn''t it be in "tcout" ? > > Jorge, > > You often have to read between the lines when dealing with Shorewall > problem reports. The ifconfig output that made you think the IP is > local > was apparently obtained on a system other than where Shorewall is > running. I came to that conclusion by comparing that ifconfig output > with the dump attached to the same post. > > The dump showed the following: > > 2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc htb qlen 1000 > link/ether 00:40:f4:cb:33:75 brd ff:ff:ff:ff:ff:ff > inet 201.89.170.10/29 brd 201.89.170.15 scope global eth0 > inet6 fe80::240:f4ff:fecb:3375/64 scope link > valid_lft forever preferred_lft forever > 3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 > link/ether 00:02:55:5e:fa:ff brd ff:ff:ff:ff:ff:ff > inet 192.168.200.254/24 brd 192.168.200.255 scope global eth1 > inet6 fe80::202:55ff:fe5e:faff/64 scope link > valid_lft forever preferred_lft forever > > So it seems that the traffic in question is arriving on the firewall''s > eth0 and being sent through eth1; hence, it will traverse the > ''tcfor'' chain. > > -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 > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net''s Techsay panel and you''ll get the chance to > share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV________________________________ > _______________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Thanks ! well, I think that could have not worked because of (blind guesses): - it should be dst port 3128 but that would be only for local connections, squid could be creating a second connection for the external iface to the destination using a different port (not 3128). If squid has a specific user on the system, use marking based on the username owning the packet. This has the limitation that would affect all users using squid, so you might not be able to create exceptions. That''s why I thought about about using connection marking on the input iface, but I gues wouldn''t work neither because it would mark your connection between the localnet system and squid, and not squid''s to external. I''m basing all this on the asumption that squid creates a new connection to the target system. I read it nowhere, I''m guessing... sorry if wrong. If that would be the case you might be able to use squid authentication to create some kind of internal squid marking, like ToS, and the use that value on shorewall as the base for new marking rules. Don''t know squid. But if you don''t need exceptions the "marking based on user" is a fast an easy solution. Hope it helps, jorge Jorge Daza García-Blanes jorge@drqueue.org - GPG id: 5D7ACDEF On 30/12/2006, at 14:31, Ismael Milach da Silveira wrote:> This line looks to me a redirection to a 3128 (squid transparent > proxy?), is it ? > > Then incomming traffic wouldn''t have the proper mark using IP because > source address has been changed by the local one, would also fail > using iface name... I guess. > > **************** > > I think you''re absolutely correct.. > > One thing I thought would do the trick was to limit the traffic > coming from > port 3128 to everywhere, tried that also. > > The other thing I did was to limit every traffic to dport 80, > coming from > anywhere, (the dump attached on the previous post). Now, why that > didn''t > work? > > Thanks Jorge! > > Ismael > > > > > > ----- Original Message ----- > From: "Jorge Daza García-Blanes" <jorge@drqueue.org> > To: "Shorewall Users" <shorewall-users@lists.sourceforge.net> > Sent: Saturday, December 30, 2006 6:54 AM > Subject: Re: [Shorewall-users] TC - not marking correctly > > > Thanks for your non-flaming post Tom, > > I apologize. > > Now I''ve read the dump and will try to make a humble second guess, I > think that somehow related to my first post. > > This has been taken from the dump: > tcp 6 431999 ESTABLISHED src=192.168.200.1 dst=201.3.160.245 > sport=33955 dport=80 src=192.168.200.254 dst=192.168.200.1 sport=3128 > dport=33955 [ASSURED] mark=0 use=1 > > This line looks to me a redirection to a 3128 (squid transparent > proxy?), is it ? > > Then incomming traffic wouldn''t have the proper mark using IP because > source address has been changed by the local one, would also fail > using iface name... I guess. > > So my guess is that this would be what I mentioned in the previous > email as "natting". > > If that were correct, my guess is you could either use connection > marks on mangle''s prerouting and check for it. Or look for every > packet... this might be a bit more complex because incomming traffic > generated that way wouldn''t have a known destionation port (comes > from 80 but squid [or whoever] wouldn''t be forced to use 3128 as > destination port). As we wouldn''t know at that point the destination > local address, could also be harder to create exclusions or any other > more refined marking rule... > > I have some theories on why that could also fail even if the > masquerade theory is right (basically because you could have two tcp > connections). > > But am I closer now at why it is marking right given the rules ? > > Now, show no mercy, I decided to live one more day. :) > > Jorge Daza García-Blanes > jorge@drqueue.org - GPG id: 5D7ACDEF > > > On 30/12/2006, at 0:42, Tom Eastep wrote: > >> Jorge Daza García-Blanes wrote: >> >>> >>> I just saw that the rule is in "tcfor" and the IP is local so, >>> shouldn''t it be in "tcout" ? >> >> Jorge, >> >> You often have to read between the lines when dealing with Shorewall >> problem reports. The ifconfig output that made you think the IP is >> local >> was apparently obtained on a system other than where Shorewall is >> running. I came to that conclusion by comparing that ifconfig output >> with the dump attached to the same post. >> >> The dump showed the following: >> >> 2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc htb qlen 1000 >> link/ether 00:40:f4:cb:33:75 brd ff:ff:ff:ff:ff:ff >> inet 201.89.170.10/29 brd 201.89.170.15 scope global eth0 >> inet6 fe80::240:f4ff:fecb:3375/64 scope link >> valid_lft forever preferred_lft forever >> 3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 >> link/ether 00:02:55:5e:fa:ff brd ff:ff:ff:ff:ff:ff >> inet 192.168.200.254/24 brd 192.168.200.255 scope global eth1 >> inet6 fe80::202:55ff:fe5e:faff/64 scope link >> valid_lft forever preferred_lft forever >> >> So it seems that the traffic in question is arriving on the >> firewall''s >> eth0 and being sent through eth1; hence, it will traverse the >> ''tcfor'' chain. >> >> -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 >> >> --------------------------------------------------------------------- >> - >> --- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net''s Techsay panel and you''ll get the chance to >> share your >> opinions on IT & business topics through brief surveys - and earn >> cash >> http://www.techsay.com/default.php? >> page=join.php&p=sourceforge&CID=DEVDEV_______________________________ >> _ >> _______________ >> Shorewall-users mailing list >> Shorewall-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/shorewall-users > > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net''s Techsay panel and you''ll get the chance to > share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net''s Techsay panel and you''ll get the chance to > share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
I forgot, the dport 80 not working: could it be because should be sport 80 ? Best wishes, jorge Jorge Daza García-Blanes jorge@drqueue.org - GPG id: 5D7ACDEF On 30/12/2006, at 14:31, Ismael Milach da Silveira wrote:> This line looks to me a redirection to a 3128 (squid transparent > proxy?), is it ? > > Then incomming traffic wouldn''t have the proper mark using IP because > source address has been changed by the local one, would also fail > using iface name... I guess. > > **************** > > I think you''re absolutely correct.. > > One thing I thought would do the trick was to limit the traffic > coming from > port 3128 to everywhere, tried that also. > > The other thing I did was to limit every traffic to dport 80, > coming from > anywhere, (the dump attached on the previous post). Now, why that > didn''t > work? > > Thanks Jorge! > > Ismael > > > > > > ----- Original Message ----- > From: "Jorge Daza García-Blanes" <jorge@drqueue.org> > To: "Shorewall Users" <shorewall-users@lists.sourceforge.net> > Sent: Saturday, December 30, 2006 6:54 AM > Subject: Re: [Shorewall-users] TC - not marking correctly > > > Thanks for your non-flaming post Tom, > > I apologize. > > Now I''ve read the dump and will try to make a humble second guess, I > think that somehow related to my first post. > > This has been taken from the dump: > tcp 6 431999 ESTABLISHED src=192.168.200.1 dst=201.3.160.245 > sport=33955 dport=80 src=192.168.200.254 dst=192.168.200.1 sport=3128 > dport=33955 [ASSURED] mark=0 use=1 > > This line looks to me a redirection to a 3128 (squid transparent > proxy?), is it ? > > Then incomming traffic wouldn''t have the proper mark using IP because > source address has been changed by the local one, would also fail > using iface name... I guess. > > So my guess is that this would be what I mentioned in the previous > email as "natting". > > If that were correct, my guess is you could either use connection > marks on mangle''s prerouting and check for it. Or look for every > packet... this might be a bit more complex because incomming traffic > generated that way wouldn''t have a known destionation port (comes > from 80 but squid [or whoever] wouldn''t be forced to use 3128 as > destination port). As we wouldn''t know at that point the destination > local address, could also be harder to create exclusions or any other > more refined marking rule... > > I have some theories on why that could also fail even if the > masquerade theory is right (basically because you could have two tcp > connections). > > But am I closer now at why it is marking right given the rules ? > > Now, show no mercy, I decided to live one more day. :) > > Jorge Daza García-Blanes > jorge@drqueue.org - GPG id: 5D7ACDEF > > > On 30/12/2006, at 0:42, Tom Eastep wrote: > >> Jorge Daza García-Blanes wrote: >> >>> >>> I just saw that the rule is in "tcfor" and the IP is local so, >>> shouldn''t it be in "tcout" ? >> >> Jorge, >> >> You often have to read between the lines when dealing with Shorewall >> problem reports. The ifconfig output that made you think the IP is >> local >> was apparently obtained on a system other than where Shorewall is >> running. I came to that conclusion by comparing that ifconfig output >> with the dump attached to the same post. >> >> The dump showed the following: >> >> 2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc htb qlen 1000 >> link/ether 00:40:f4:cb:33:75 brd ff:ff:ff:ff:ff:ff >> inet 201.89.170.10/29 brd 201.89.170.15 scope global eth0 >> inet6 fe80::240:f4ff:fecb:3375/64 scope link >> valid_lft forever preferred_lft forever >> 3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 >> link/ether 00:02:55:5e:fa:ff brd ff:ff:ff:ff:ff:ff >> inet 192.168.200.254/24 brd 192.168.200.255 scope global eth1 >> inet6 fe80::202:55ff:fe5e:faff/64 scope link >> valid_lft forever preferred_lft forever >> >> So it seems that the traffic in question is arriving on the >> firewall''s >> eth0 and being sent through eth1; hence, it will traverse the >> ''tcfor'' chain. >> >> -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 >> >> --------------------------------------------------------------------- >> - >> --- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net''s Techsay panel and you''ll get the chance to >> share your >> opinions on IT & business topics through brief surveys - and earn >> cash >> http://www.techsay.com/default.php? >> page=join.php&p=sourceforge&CID=DEVDEV_______________________________ >> _ >> _______________ >> Shorewall-users mailing list >> Shorewall-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/shorewall-users > > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net''s Techsay panel and you''ll get the chance to > share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net''s Techsay panel and you''ll get the chance to > share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Jorge Daza García-Blanes wrote:> I forgot, the dport 80 not working: could it be because should be > sport 80 ? >Jorge, With regards to the transparent proxy, good spotting! I wouldn''t have found that in quite a while because it would never occur to me that someone would be trying to do incoming traffic shaping while running a proxy. The reason that I wouldn''t have considered that approach is that it basically can''t work correctly. What you are usually trying to do when shaping incoming traffic is to limit the load on your Internet link; in this case, Ismael wants to limit the traffic generated by 192.168.200.1. But it is impossible to identify the Squid-generated Internet traffic is the result of requests from 192.168.200.1. Ismael can mark the traffic from Squid->192.168.200.1 using this rule: <mark value> $FW 192.168.200.1 tcp - 3128 But that will mark responses from Squid that were handled from its cache and that generated no traffic on the Internet link at all! -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Tom Eastep wrote:> But it is impossible to > identify the Squid-generated Internet traffic is the result of requests from > 192.168.200.1.I knew I should have proofread this one last time. The above should have been: But it is impossible to identify the Squid-generated Internet traffic *that* is the result of requests from 192.168.200.1. -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
On Sat, Dec 30, 2006 at 08:18:19AM -0800, Tom Eastep wrote:> The reason that I wouldn''t have considered that approach is that it basically > can''t work correctly. What you are usually trying to do when shaping incoming > traffic is to limit the load on your Internet link; in this case, Ismael wants > to limit the traffic generated by 192.168.200.1. But it is impossible to > identify the Squid-generated Internet traffic is the result of requests from > 192.168.200.1.The solution would appear to be to get squid to do the traffic shaping - this is one of the things which it is designed for (and you get to combine shaping rules with squid''s full ACL system). Check the manual for ''delay pools''; beyond that is offtopic here. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Thanks Tom ! actually I think there''s some option to set the ToS on squid for outgoung traffic. If that could be somehow related to an ACL belonging to that local ip, you could mark outgoing connections based on your weird ToS, and then clear the ToS value just before letting the packet go. Would that be an option ? (If that''s allowed by squid, which I haven''t checked but will right now) Best wishes, Jorge Jorge Daza García-Blanes jorge@drqueue.org - GPG id: 5D7ACDEF On 30/12/2006, at 17:18, Tom Eastep wrote:> Jorge Daza García-Blanes wrote: >> I forgot, the dport 80 not working: could it be because should be >> sport 80 ? >> > > Jorge, > > With regards to the transparent proxy, good spotting! I wouldn''t > have found that > in quite a while because it would never occur to me that someone > would be trying > to do incoming traffic shaping while running a proxy. > > The reason that I wouldn''t have considered that approach is that it > basically > can''t work correctly. What you are usually trying to do when > shaping incoming > traffic is to limit the load on your Internet link; in this case, > Ismael wants > to limit the traffic generated by 192.168.200.1. But it is > impossible to > identify the Squid-generated Internet traffic is the result of > requests from > 192.168.200.1. > > Ismael can mark the traffic from Squid->192.168.200.1 using this rule: > > <mark value> $FW 192.168.200.1 tcp - 3128 > > But that will mark responses from Squid that were handled from its > cache and > that generated no traffic on the Internet link at all! > > -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 > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net''s Techsay panel and you''ll get the chance to > share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV________________________________ > _______________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Sorry, I posted before having seen this mail. Jorge Daza García-Blanes jorge@drqueue.org - GPG id: 5D7ACDEF On 30/12/2006, at 18:09, Andrew Suffield wrote:> On Sat, Dec 30, 2006 at 08:18:19AM -0800, Tom Eastep wrote: >> The reason that I wouldn''t have considered that approach is that >> it basically >> can''t work correctly. What you are usually trying to do when >> shaping incoming >> traffic is to limit the load on your Internet link; in this case, >> Ismael wants >> to limit the traffic generated by 192.168.200.1. But it is >> impossible to >> identify the Squid-generated Internet traffic is the result of >> requests from >> 192.168.200.1. > > The solution would appear to be to get squid to do the traffic shaping > - this is one of the things which it is designed for (and you get to > combine shaping rules with squid''s full ACL system). Check the manual > for ''delay pools''; beyond that is offtopic here. > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net''s Techsay panel and you''ll get the chance to > share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Ok, thanks again, I used delay_pools on some clients and it worked, but the problem is, I still can''t do traffic shaping with shorewall using other ports either. tcclasses ##################################### eth0 1 128kbps 256kbps 2 eth0 2 full full 1 default eth1 3 128kbps 256kbps 2 eth1 4 full full 1 default ####################################### tcrules ############################### 1 0.0.0.0/0 192.168.200.1 all 1 192.168.200.1 0.0.0.0/0 all 3 0.0.0.0/0 192.168.200.1 all 3 192.168.200.1 0.0.0.0/0 all ################################ scp... ################################## [doctor@srvsisdia doctor]$ scp doctor@201.3.160.245:/home/doctor/thunderbird.tar.gz . Password: thunderbird.tar.gz 2% 6660KB 56.9KB/s 1:33:25 ################################## from the dump ########################################## Chain tcfor (1 references) pkts bytes target prot opt in out source destination 1888 2274K MARK all -- * * 0.0.0.0/0 192.168.200.1 MARK set 0x1 1153 101K MARK all -- * * 192.168.200.1 0.0.0.0/0 MARK set 0x1 1888 2274K MARK all -- * * 0.0.0.0/0 192.168.200.1 MARK set 0x3 1153 101K MARK all -- * * 192.168.200.1 0.0.0.0/0 MARK set 0x3 ############################################ ########################################## tcp 6 431999 ESTABLISHED src=192.168.200.1 dst=201.3.160.245 sport=35134 dport=22 src=201.3.160.245 dst=201.89.170.10 sport=22 dport=35134 [ASSURED] mark=0 use=1 ########################################### It''s not following the marks for some reason, the dump is attached (status201.txt.bz2)..... I tried some other things, like marking all traffic from/to 201.3.160.245 (status245.txt.). Ismael ----- Original Message ----- From: "Jorge Daza García-Blanes" <jorge@drqueue.org> To: "Shorewall Users" <shorewall-users@lists.sourceforge.net> Sent: Saturday, December 30, 2006 3:42 PM Subject: Re: [Shorewall-users] TC - not marking correctly Sorry, I posted before having seen this mail. Jorge Daza García-Blanes jorge@drqueue.org - GPG id: 5D7ACDEF On 30/12/2006, at 18:09, Andrew Suffield wrote:> On Sat, Dec 30, 2006 at 08:18:19AM -0800, Tom Eastep wrote: >> The reason that I wouldn''t have considered that approach is that >> it basically >> can''t work correctly. What you are usually trying to do when >> shaping incoming >> traffic is to limit the load on your Internet link; in this case, >> Ismael wants >> to limit the traffic generated by 192.168.200.1. But it is >> impossible to >> identify the Squid-generated Internet traffic is the result of >> requests from >> 192.168.200.1. > > The solution would appear to be to get squid to do the traffic shaping > - this is one of the things which it is designed for (and you get to > combine shaping rules with squid''s full ACL system). Check the manual > for ''delay pools''; beyond that is offtopic here. > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net''s Techsay panel and you''ll get the chance to > share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
tried that, too :-) ----- Original Message ----- From: "Jorge Daza García-Blanes" <jorge@drqueue.org> To: "Shorewall Users" <shorewall-users@lists.sourceforge.net> Sent: Saturday, December 30, 2006 11:45 AM Subject: Re: [Shorewall-users] TC - not marking correctly I forgot, the dport 80 not working: could it be because should be sport 80 ? Best wishes, jorge Jorge Daza García-Blanes jorge@drqueue.org - GPG id: 5D7ACDEF On 30/12/2006, at 14:31, Ismael Milach da Silveira wrote:> This line looks to me a redirection to a 3128 (squid transparent > proxy?), is it ? > > Then incomming traffic wouldn''t have the proper mark using IP because > source address has been changed by the local one, would also fail > using iface name... I guess. > > **************** > > I think you''re absolutely correct.. > > One thing I thought would do the trick was to limit the traffic > coming from > port 3128 to everywhere, tried that also. > > The other thing I did was to limit every traffic to dport 80, > coming from > anywhere, (the dump attached on the previous post). Now, why that > didn''t > work? > > Thanks Jorge! > > Ismael > > > > > > ----- Original Message ----- > From: "Jorge Daza García-Blanes" <jorge@drqueue.org> > To: "Shorewall Users" <shorewall-users@lists.sourceforge.net> > Sent: Saturday, December 30, 2006 6:54 AM > Subject: Re: [Shorewall-users] TC - not marking correctly > > > Thanks for your non-flaming post Tom, > > I apologize. > > Now I''ve read the dump and will try to make a humble second guess, I > think that somehow related to my first post. > > This has been taken from the dump: > tcp 6 431999 ESTABLISHED src=192.168.200.1 dst=201.3.160.245 > sport=33955 dport=80 src=192.168.200.254 dst=192.168.200.1 sport=3128 > dport=33955 [ASSURED] mark=0 use=1 > > This line looks to me a redirection to a 3128 (squid transparent > proxy?), is it ? > > Then incomming traffic wouldn''t have the proper mark using IP because > source address has been changed by the local one, would also fail > using iface name... I guess. > > So my guess is that this would be what I mentioned in the previous > email as "natting". > > If that were correct, my guess is you could either use connection > marks on mangle''s prerouting and check for it. Or look for every > packet... this might be a bit more complex because incomming traffic > generated that way wouldn''t have a known destionation port (comes > from 80 but squid [or whoever] wouldn''t be forced to use 3128 as > destination port). As we wouldn''t know at that point the destination > local address, could also be harder to create exclusions or any other > more refined marking rule... > > I have some theories on why that could also fail even if the > masquerade theory is right (basically because you could have two tcp > connections). > > But am I closer now at why it is marking right given the rules ? > > Now, show no mercy, I decided to live one more day. :) > > Jorge Daza García-Blanes > jorge@drqueue.org - GPG id: 5D7ACDEF > > > On 30/12/2006, at 0:42, Tom Eastep wrote: > >> Jorge Daza García-Blanes wrote: >> >>> >>> I just saw that the rule is in "tcfor" and the IP is local so, >>> shouldn''t it be in "tcout" ? >> >> Jorge, >> >> You often have to read between the lines when dealing with Shorewall >> problem reports. The ifconfig output that made you think the IP is >> local >> was apparently obtained on a system other than where Shorewall is >> running. I came to that conclusion by comparing that ifconfig output >> with the dump attached to the same post. >> >> The dump showed the following: >> >> 2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc htb qlen 1000 >> link/ether 00:40:f4:cb:33:75 brd ff:ff:ff:ff:ff:ff >> inet 201.89.170.10/29 brd 201.89.170.15 scope global eth0 >> inet6 fe80::240:f4ff:fecb:3375/64 scope link >> valid_lft forever preferred_lft forever >> 3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 >> link/ether 00:02:55:5e:fa:ff brd ff:ff:ff:ff:ff:ff >> inet 192.168.200.254/24 brd 192.168.200.255 scope global eth1 >> inet6 fe80::202:55ff:fe5e:faff/64 scope link >> valid_lft forever preferred_lft forever >> >> So it seems that the traffic in question is arriving on the >> firewall''s >> eth0 and being sent through eth1; hence, it will traverse the >> ''tcfor'' chain. >> >> -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 >> >> --------------------------------------------------------------------- >> - >> --- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net''s Techsay panel and you''ll get the chance to >> share your >> opinions on IT & business topics through brief surveys - and earn >> cash >> http://www.techsay.com/default.php? >> page=join.php&p=sourceforge&CID=DEVDEV_______________________________ >> _ >> _______________ >> Shorewall-users mailing list >> Shorewall-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/shorewall-users > > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net''s Techsay panel and you''ll get the chance to > share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net''s Techsay panel and you''ll get the chance to > share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Ismael Milach da Silveira wrote:> Ok, thanks again, I used delay_pools on some clients and it worked, but > the problem is, I still can''t do traffic shaping with shorewall using > other ports either. > > tcclasses > ##################################### > eth0 1 128kbps 256kbps 2 > eth0 2 full full 1 default > > eth1 3 128kbps 256kbps 2 > eth1 4 full full 1 default > ####################################### > > tcrules > ############################### > 1 0.0.0.0/0 192.168.200.1 all > 1 192.168.200.1 0.0.0.0/0 all > > 3 0.0.0.0/0 192.168.200.1 all > 3 192.168.200.1 0.0.0.0/0 allRemember that rules in the ''tcrules'' file are non-terminating so after a packet is applied to one rule, it goes on to the next one; so with your rules, *forwarded* traffic to and from 192.168.200.1 will always have mark 3 and will never have mark 1. Traffic between 192.168.200.1 and the firewall will never be marked. 192.168.200.1 connects through eth1. That being the case, any traffic FROM 192.168.200.1 will be coming FROM eth1 and going TO eth0. So you want: 1 192.168.200.1 0.0.0.0/0 all Similarly, traffic forwarded TO 192.168.200.1 will be coming FROM eth0 and going TO eth1. So you want: 3 0.0.0.0/0 192.168.200.1 all Those are the only two rules you need for forwarded traffic. If you also want to shape traffic from the firewall to 192.168.200.1, add ONE additional rule: 3 $FW 192.168.200.1 all -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
############################## So you want: 1 192.168.200.1 0.0.0.0/0 all Similarly, traffic forwarded TO 192.168.200.1 will be coming FROM eth0 and going TO eth1. So you want: 3 0.0.0.0/0 192.168.200.1 all Those are the only two rules you need for forwarded traffic. ############################ Ok, the dump with that config is attached... I had done that already last week :-) ############################################# [doctor@srvsisdia doctor]$ scp doctor@201.3.160.245:/home/doctor/thunderbird.tar.gz . Password: thunderbird.tar.gz 6% 20MB 52.8KB/s 1:36:01 ############################################## ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Ismael Milach da Silveira wrote:> ############################## > So you want: > 1 192.168.200.1 0.0.0.0/0 all > Similarly, traffic forwarded TO 192.168.200.1 will be coming FROM eth0 > and going > TO eth1. So you want: > 3 0.0.0.0/0 192.168.200.1 all > Those are the only two rules you need for forwarded traffic. > ############################ > > Ok, the dump with that config is attached... I had done that already > last week :-) > > ############################################# > [doctor@srvsisdia doctor]$ scp > doctor@201.3.160.245:/home/doctor/thunderbird.tar.gz . > Password: > thunderbird.tar.gz 6% 20MB 52.8KB/s 1:36:01 > ############################################## >Ok. Your rules are now marking correctly: Chain tcfor (1 references) pkts bytes target prot opt in out source destination 3744 209K MARK all -- * * 192.168.200.1 0.0.0.0/0 MARK set 0x1 6650 9851K MARK all -- * * 0.0.0.0/0 192.168.200.1 MARK set 0x3 Chain tcout (1 references) pkts bytes target prot opt in out source destination 194 10568 MARK all -- * * 0.0.0.0/0 192.168.200.1 MARK set 0x3 Chain tcpost (1 references) pkts bytes target prot opt in out source destination 3744 209K CLASSIFY all -- * eth0 0.0.0.0/0 0.0.0.0/0 MARK match 0x1/0xff CLASSIFY set 1:11 0 0 CLASSIFY all -- * eth0 0.0.0.0/0 0.0.0.0/0 MARK match 0x2/0xff CLASSIFY set 1:12 6844 9862K CLASSIFY all -- * eth1 0.0.0.0/0 0.0.0.0/0 MARK match 0x3/0xff CLASSIFY set 2:13 0 0 CLASSIFY all -- * eth1 0.0.0.0/0 0.0.0.0/0 MARK match 0x4/0xff CLASSIFY set 2:14 In particular, 6844 forwarded packets to 192.168.200.1 were classified with 2:13. From the TC information: class htb 2:13 parent 2:1 leaf 13: prio 2 quantum 12288 rate 1024Kbit ceil 2048Kbit burst 1627b/8 mpu 0b overhead 0b cburst 1755b/8 mpu 0b overhead 0b level 0 ------------- Sent 9982131 bytes 6861 pkts (dropped 0, overlimits 0) rate 481776bit 41pps -------------- lended: 6861 borrowed: 0 giants: 0 tokens: 928 ctokens: 976 The ceiling for class 2:13 is 2 Mbit/second; you are seeing a transfer rate of 52.8 Kilobytes or approximately .4 Mbit/second (actually 481,776 bites per second -- see above) which is much less than 2 Mbit/second. So, what problem are you reporting? -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Tom Eastep wrote:> In particular, 6844 forwarded packets to 192.168.200.1 were classified with 2:13. > > From the TC information: > > class htb 2:13 parent 2:1 leaf 13: prio 2 quantum 12288 rate 1024Kbit ceil 2048Kbit burst 1627b/8 mpu 0b overhead 0b cburst 1755b/8 mpu 0b overhead 0b level 0 > ------------- > Sent 9982131 bytes 6861 pkts (dropped 0, overlimits 0) > rate 481776bit 41pps > -------------- > lended: 6861 borrowed: 0 giants: 0 > tokens: 928 ctokens: 976 > > The ceiling for class 2:13 is 2 Mbit/second; you are seeing a transfer rate of 52.8 Kilobytes or approximately .4 Mbit/second (actually 481,776 bites per second -- see above) which is much less than 2 Mbit/second. > > So, what problem are you reporting?Ah! -- I think I see A problem.... From one of your earlier posts: tcdevices ################################### eth0 512kbit 512kbit eth1 100000kbit 100000kbit ################################### So eth0 has a speed of 512K *BITS* in each direction. But also from earlier posts: tcclasses ####################################### eth1 3 128kbps 256kbps 2 eth1 4 full full 1 default ####################################### So your Mark=3 class on eth1 defines a much wider pipe than eth0 (128K *BYTES* per second guaranteed and 256K *BYTES* per second max). So even though you are now correctly classifying traffic with your tcrules, you will not have any effective shaping of download traffic to 192.168.200.1. -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
damnit I was using kbps as kilobits instead of kbytes!!!
$%¨$¨%$#¨%$&#¨&¨#$&%¨%¨*&#*%¨*
IT''S WORKING!
:-)
Guys, It was not really a life or death situation here, but obviously
It''s
something I''ll later "sell" as a service... so I
can''t thank you enough for
what you, Jorge and Andrew did, I mean, taking the time close to new
year''s
eve to help some stranger who could barely report ir''s problem
correctly and
it ended up being a stupid mistake...
really, you da men, there''ll be a "caipirinha" waiting for
you when you come
to Brazil :-)
Oh, here''s the result:
the default is "full", 200.1 should use 256 kbps max, I mean, 256
kilobitspersecond :-)
############################
[doctor@srvsisdia doctor]$ scp
doctor@201.3.160.245:/home/doctor/thunderbird.tar.gz .
Password:
thunderbird.tar.gz 4% 13MB 26.5KB/s 3:16:01
ETA
############################
ssh ---> ok!
##############################################
[doctor@srvsisdia doctor]$ wget www.doctornet.com.br/matrix.zip
--15:27:39-- http://www.doctornet.com.br/matrix.zip
=> `matrix.zip''
Resolving www.doctornet.com.br... done.
Connecting to www.doctornet.com.br[201.3.160.245]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 199,947,030 [application/zip]
0% [ ] 1,912,720 24.35K/s ETA
2:12:23
#####################################################
www ---> thru squid ---> ok!
I''ll do some tuning and post the whole result here, with 2 VPNs and
other
stuff.
Thanks again!!
Ismael
----- Original Message -----
From: "Tom Eastep" <teastep@shorewall.net>
To: "Shorewall Users" <shorewall-users@lists.sourceforge.net>
Sent: Tuesday, January 02, 2007 3:01 PM
Subject: Re: [Shorewall-users] TC - not marking correctly
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net''s Techsay panel and you''ll get the
chance to share
> your
> opinions on IT & business topics through brief surveys - and earn cash
>
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
--------------------------------------------------------------------------------
> _______________________________________________
> Shorewall-users mailing list
> Shorewall-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shorewall-users
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net''s Techsay panel and you''ll get the chance
to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
############ So your Mark=3 class on eth1 defines a much wider pipe than eth0 (128K *BYTES* per second guaranteed and 256K *BYTES* per second max). So even though you are now correctly classifying traffic with your tcrules, you will not have any effective shaping of download traffic to 192.168.200.1. ############ exactly :-) Now it''s: ############################## eth0 1 16kbps 30kbps 2 eth0 2 full full 1 default eth1 3 16kbps 30kbps 2 eth1 4 full full 1 default ############################### working perfectly right :-)) ----- Original Message ----- From: "Tom Eastep" <teastep@shorewall.net> To: "Shorewall Users" <shorewall-users@lists.sourceforge.net> Sent: Tuesday, January 02, 2007 3:15 PM Subject: Re: [Shorewall-users] TC - not marking correctly> ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net''s Techsay panel and you''ll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV--------------------------------------------------------------------------------> _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV