Hi all, I''m a long time user of iptables but recently decided to move to try out shorewall and after a bit of trial and error I''m getting on ok with it. I am trying to implement traffic shaping with TC and I''m having problems marking the packets to go into the right queues. My classes are very basic at the moment, 1 is for high priority real-time traffic (ssh), 2 is for http bulk traffic, and 10 is everything else. I''m trying to use a rule to mark everything going from internal to external port 22 with 1: 1:11 0.0.0.0/0 0.0.0.0/0 tcp 22 CONTINUE 0.0.0.0/0 0.0.0.0/0 tcp 22 I''ve also tried with 1 instead of 1:11 and I''ve tried without CONTINUEs. Unfortunately, everything get dropped down to the 10 queue. Can anyone supply me with a clue how to mark my packets for ssh, http and everything else as final resort? I would really appreciate some pointers with this. Thanks Matt ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can''t happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
Some more information: No packets are being marked according to "shorewall show connections". Even if I try and mark everything with a single class, it doesn''t show up. I''ve tried all the examples on the website recipe guide...but it doesn''t seem to work like it should. Thanks Matt ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can''t happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
Matt Harrison wrote:> Hi all, > > I''m a long time user of iptables but recently decided to move to try out > shorewall and after a bit of trial and error I''m getting on ok with it. > > I am trying to implement traffic shaping with TC and I''m having problems > marking the packets to go into the right queues. > > My classes are very basic at the moment, 1 is for high priority real-time > traffic (ssh), 2 is for http bulk traffic, and 10 is everything else. > > I''m trying to use a rule to mark everything going from internal to external > port 22 with 1: > > 1:11 0.0.0.0/0 0.0.0.0/0 tcp 22 > CONTINUE 0.0.0.0/0 0.0.0.0/0 tcp 22 > > I''ve also tried with 1 instead of 1:11 and I''ve tried without CONTINUEs. > Unfortunately, everything get dropped down to the 10 queue. > > Can anyone supply me with a clue how to mark my packets for ssh, http and > everything else as final resort? > > I would really appreciate some pointers with this.When marking rules don''t work as expected, it is usually the result of failing to take into account which direction the packets are flowing relative to which way the connections were originally made. Your rules above will only mark outgoing packets from connections that originate behind the firewall. Outgoing packets from connections that originate on the net and connect to SSH servers behind the firewall will have SOURCE PORT == 22 rather than DEST PORT == 22. If that is not the problem in your case, please submit the output of ''shorewall dump'' collected as described at http://www.shorewall.net/support.htm#Guidelines. Thanks ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can''t happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
Matt Harrison wrote:> Some more information: > > No packets are being marked according to "shorewall show connections". > > Even if I try and mark everything with a single class, it doesn''t show up. >That is because only *connection* marks show up in the output of "shorewall show connections". See http://www.shorewall.net/PacketMarking.html which is indexed under "Packet Marking" in the online Shorewall Documentation Index. ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can''t happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
Shorewall Geek wrote:> When marking rules don''t work as expected, it is usually the result of > failing to take into account which direction the packets are flowing > relative to which way the connections were originally made. Your rules > above will only mark outgoing packets from connections that originate > behind the firewall. Outgoing packets from connections that originate on > the net and connect to SSH servers behind the firewall will have SOURCE > PORT == 22 rather than DEST PORT == 22.Thanks for the replies, That makes sense. I was only trying for connections originating inside the network, but when that''s working I will look at the other way.> If that is not the problem in your case, please submit the output of > ''shorewall dump'' collected as described at > http://www.shorewall.net/support.htm#Guidelines.Please see attached status.txt.bz2 Thanks ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can''t happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
Matt Harrison wrote:> Shorewall Geek wrote: >> When marking rules don''t work as expected, it is usually the result of >> failing to take into account which direction the packets are flowing >> relative to which way the connections were originally made. Your rules >> above will only mark outgoing packets from connections that originate >> behind the firewall. Outgoing packets from connections that originate on >> the net and connect to SSH servers behind the firewall will have SOURCE >> PORT == 22 rather than DEST PORT == 22. > > Thanks for the replies, > > That makes sense. I was only trying for connections originating inside > the network, but when that''s working I will look at the other way. > >> If that is not the problem in your case, please submit the output of >> ''shorewall dump'' collected as described at >> http://www.shorewall.net/support.htm#Guidelines. > > Please see attached status.txt.bz2Chain tcpost (1 references) pkts bytes target prot opt in out source destination 607 160K CLASSIFY tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 CLASSIFY set 1:12 12 1488 CLASSIFY all -- * eth1 0.0.0.0/0 0.0.0.0/0 MARK match 0x1/0xff CLASSIFY set 1:11 0 0 CLASSIFY all -- * eth1 0.0.0.0/0 0.0.0.0/0 MARK match 0x2/0xff CLASSIFY set 1:12 0 0 CLASSIFY all -- * eth1 0.0.0.0/0 0.0.0.0/0 MARK match 0xa/0xff CLASSIFY set 1:110 Chain tcpre (1 references) pkts bytes target prot opt in out source destination 261 15876 MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 MARK set 0x1 You are setting the mark to 1 for outgoing SSH to 1. 261 packets destined for TCP port 22 entered PREROUTING. Note, however that only 12 of them exited through eth1; those were correctly classified to class 1:11.>From further down in the dump, we see:class htb 1:11 parent 1:1 leaf 11: prio 1 quantum 1500 rate 40000bit ceil 512000bit burst 1504b/8 mpu 0b overhead 0b cburst 1563b/8 mpu 0b overhead 0b level 0 Sent 1656 bytes 12 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 lended: 12 borrowed: 0 giants: 0 tokens: 284570 ctokens: 23132 So exactly 12 packets were sent through class 1:11. PS -- you are running a very old and unsupported version of Shorewall. ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can''t happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
Shorewall Geek wrote:> Matt Harrison wrote: >> Shorewall Geek wrote: >>> When marking rules don''t work as expected, it is usually the result of >>> failing to take into account which direction the packets are flowing >>> relative to which way the connections were originally made. Your rules >>> above will only mark outgoing packets from connections that originate >>> behind the firewall. Outgoing packets from connections that originate on >>> the net and connect to SSH servers behind the firewall will have SOURCE >>> PORT == 22 rather than DEST PORT == 22. >> Thanks for the replies, >> >> That makes sense. I was only trying for connections originating inside >> the network, but when that''s working I will look at the other way. >> >>> If that is not the problem in your case, please submit the output of >>> ''shorewall dump'' collected as described at >>> http://www.shorewall.net/support.htm#Guidelines. >> Please see attached status.txt.bz2 > > Chain tcpost (1 references) > pkts bytes target prot opt in out source > destination > 607 160K CLASSIFY tcp -- * * 0.0.0.0/0 > 0.0.0.0/0 tcp dpt:80 CLASSIFY set 1:12 > 12 1488 CLASSIFY all -- * eth1 0.0.0.0/0 > 0.0.0.0/0 MARK match 0x1/0xff CLASSIFY set 1:11 > 0 0 CLASSIFY all -- * eth1 0.0.0.0/0 > 0.0.0.0/0 MARK match 0x2/0xff CLASSIFY set 1:12 > 0 0 CLASSIFY all -- * eth1 0.0.0.0/0 > 0.0.0.0/0 MARK match 0xa/0xff CLASSIFY set 1:110 > > Chain tcpre (1 references) > pkts bytes target prot opt in out source > destination > 261 15876 MARK tcp -- * * 0.0.0.0/0 > 0.0.0.0/0 tcp dpt:22 MARK set 0x1 > > You are setting the mark to 1 for outgoing SSH to 1. 261 packets > destined for TCP port 22 entered PREROUTING. Note, however that only 12 > of them exited through eth1; those were correctly classified to class 1:11. > >>From further down in the dump, we see: > > class htb 1:11 parent 1:1 leaf 11: prio 1 quantum 1500 rate 40000bit > ceil 512000bit burst 1504b/8 mpu 0b overhead 0b cburst 1563b/8 mpu 0b > overhead 0b level 0 > Sent 1656 bytes 12 pkt (dropped 0, overlimits 0 requeues 0) > rate 0bit 0pps backlog 0b 0p requeues 0 > lended: 12 borrowed: 0 giants: 0 > tokens: 284570 ctokens: 23132 > > So exactly 12 packets were sent through class 1:11. > > PS -- you are running a very old and unsupported version of Shorewall.Well this version is the current stable version in gentoo portage, however it does seem quite old. I was confused as the shorewall show connections says the mark was 0, and using tc class show didn''t seem to be counting 1:11 packets. I will do an upgrade and see what happens. Thanks Matt ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can''t happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
Shorewall Geek wrote:>>From further down in the dump, we see: > > class htb 1:11 parent 1:1 leaf 11: prio 1 quantum 1500 rate 40000bit > ceil 512000bit burst 1504b/8 mpu 0b overhead 0b cburst 1563b/8 mpu 0b > overhead 0b level 0 > Sent 1656 bytes 12 pkt (dropped 0, overlimits 0 requeues 0) > rate 0bit 0pps backlog 0b 0p requeues 0 > lended: 12 borrowed: 0 giants: 0 > tokens: 284570 ctokens: 23132 > > So exactly 12 packets were sent through class 1:11.You are exactly right, it is working, to a point. I now have categories of traffic assigned to classes. I have a 512/256 ADSL line, thats actual transfer speeds of 62kB/s download and 32kB/s upload. My device: #INTERFACE IN-BANDWITH OUT-BANDWIDTH eth1 512kbit 256kbit My classes: # high priority, fastest class eth1 1 40kbit 512kbit 1 tos-minimize-delay # medium-low priority, internet games eth1 3 50kbit 100kbit 2 tos-maximize-reliability # medium priority, managed bulk traffic eth1 2 100kbit 512kbit 3 # low priority, catchall bulk traffic eth1 10 50kbit 512kbit 10 default # low priority, bittorrent eth1 9 50kbit 512kbit 11 My problem now is that when I am downloading a file over http, transferring at between 50 and 60kB/s, it only shows around 20kbits rate for that class. Shouldn''t it be showing something in the region of 480kbits? As it stands, my setup won''t really work because the classes will never hit their limits. Have I gone completely mad with this? Thanks Matt ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can''t happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
Matt Harrison wrote:> Shorewall Geek wrote: >> >From further down in the dump, we see: >> >> class htb 1:11 parent 1:1 leaf 11: prio 1 quantum 1500 rate 40000bit >> ceil 512000bit burst 1504b/8 mpu 0b overhead 0b cburst 1563b/8 mpu 0b >> overhead 0b level 0 >> Sent 1656 bytes 12 pkt (dropped 0, overlimits 0 requeues 0) >> rate 0bit 0pps backlog 0b 0p requeues 0 >> lended: 12 borrowed: 0 giants: 0 >> tokens: 284570 ctokens: 23132 >> >> So exactly 12 packets were sent through class 1:11. > > You are exactly right, it is working, to a point. I now have categories > of traffic assigned to classes. > > I have a 512/256 ADSL line, thats actual transfer speeds of 62kB/s > download and 32kB/s upload. > > My device: > > #INTERFACE IN-BANDWITH OUT-BANDWIDTH > eth1 512kbit 256kbit > > My classes: > > # high priority, fastest class > eth1 1 40kbit 512kbit 1 tos-minimize-delay > > # medium-low priority, internet games > eth1 3 50kbit 100kbit 2 > tos-maximize-reliability > > # medium priority, managed bulk traffic > eth1 2 100kbit 512kbit 3 > > # low priority, catchall bulk traffic > eth1 10 50kbit 512kbit 10 default > > # low priority, bittorrent > eth1 9 50kbit 512kbit 11 > > > My problem now is that when I am downloading a file over http,TRAFFIC SHAPING WORKS ON OUTPUT, NOT INPUT!!!!!!!!!!!!!!!!!!!! Download traffic is INPUT on the external interface -- all that is outgoing are ACKs. ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can''t happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
Matt Harrison wrote:> Shorewall Geek wrote: >> Matt Harrison wrote: >>> Shorewall Geek wrote: >>>> When marking rules don''t work as expected, it is usually the result of >>>> failing to take into account which direction the packets are flowing >>>> relative to which way the connections were originally made. Your rules >>>> above will only mark outgoing packets from connections that originate >>>> behind the firewall. Outgoing packets from connections that originate on >>>> the net and connect to SSH servers behind the firewall will have SOURCE >>>> PORT == 22 rather than DEST PORT == 22. >>> Thanks for the replies, >>> >>> That makes sense. I was only trying for connections originating inside >>> the network, but when that''s working I will look at the other way. >>> >>>> If that is not the problem in your case, please submit the output of >>>> ''shorewall dump'' collected as described at >>>> http://www.shorewall.net/support.htm#Guidelines. >>> Please see attached status.txt.bz2 >> Chain tcpost (1 references) >> pkts bytes target prot opt in out source >> destination >> 607 160K CLASSIFY tcp -- * * 0.0.0.0/0 >> 0.0.0.0/0 tcp dpt:80 CLASSIFY set 1:12 >> 12 1488 CLASSIFY all -- * eth1 0.0.0.0/0 >> 0.0.0.0/0 MARK match 0x1/0xff CLASSIFY set 1:11 >> 0 0 CLASSIFY all -- * eth1 0.0.0.0/0 >> 0.0.0.0/0 MARK match 0x2/0xff CLASSIFY set 1:12 >> 0 0 CLASSIFY all -- * eth1 0.0.0.0/0 >> 0.0.0.0/0 MARK match 0xa/0xff CLASSIFY set 1:110 >> >> Chain tcpre (1 references) >> pkts bytes target prot opt in out source >> destination >> 261 15876 MARK tcp -- * * 0.0.0.0/0 >> 0.0.0.0/0 tcp dpt:22 MARK set 0x1 >> >> You are setting the mark to 1 for outgoing SSH to 1. 261 packets >> destined for TCP port 22 entered PREROUTING. Note, however that only 12 >> of them exited through eth1; those were correctly classified to class 1:11. >> >> >From further down in the dump, we see: >> >> class htb 1:11 parent 1:1 leaf 11: prio 1 quantum 1500 rate 40000bit >> ceil 512000bit burst 1504b/8 mpu 0b overhead 0b cburst 1563b/8 mpu 0b >> overhead 0b level 0 >> Sent 1656 bytes 12 pkt (dropped 0, overlimits 0 requeues 0) >> rate 0bit 0pps backlog 0b 0p requeues 0 >> lended: 12 borrowed: 0 giants: 0 >> tokens: 284570 ctokens: 23132 >> >> So exactly 12 packets were sent through class 1:11. >> >> PS -- you are running a very old and unsupported version of Shorewall. > > Well this version is the current stable version in gentoo portage, > however it does seem quite old.The Gentoo community needs to light a fire under their Shorewall maintainer. The Debian community had do do that a while back; the result was that the current maintainer admitted that he no longer had time to be a maintainer and a new one stepped forward. ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can''t happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
Shorewall Geek wrote:> TRAFFIC SHAPING WORKS ON OUTPUT, NOT INPUT!!!!!!!!!!!!!!!!!!!! > > Download traffic is INPUT on the external interface -- all that is > outgoing are ACKs.So I need to shape on my internal interface? Even though that interface is running at a totally different speed than I want to shape around? Sorry but I''m still learning about shaping, it''s been a long time coming. Thanks Matt ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can''t happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
Matt Harrison wrote:> Shorewall Geek wrote: >> TRAFFIC SHAPING WORKS ON OUTPUT, NOT INPUT!!!!!!!!!!!!!!!!!!!! >> >> Download traffic is INPUT on the external interface -- all that is >> outgoing are ACKs. > > So I need to shape on my internal interface? Even though that interface > is running at a totally different speed than I want to shape around? > > Sorry but I''m still learning about shaping, it''s been a long time coming.http://www.shorewall.net/traffic_shaping.htm#Downloads http://www.shorewall.net/traffic_shaping.htm#IFB ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can''t happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/