Ow Mun Heng
2006-Nov-15 08:09 UTC
TCclasses/Rules - Packets not marked correctly but seems to be in correct queues
Hi All, Wondering if someone can shed some light on this. Shorewall-3.08 Gentoo LInux tcclasses ppp0 1 full full 1 tcp-ack,tos-minimize-delay ppp0 2 9*full/10 9*full/10 2 ppp0 3 8*full/10 9*full/10 3 ppp0 4 1*full/10 9*full/10 5 ppp0 5 1*full/10 6*full/10 4 default tcrules 1 0.0.0.0/0 0.0.0.0/0 icmp echo-request 1 0.0.0.0/0 0.0.0.0/0 icmp echo-reply 2 0.0.0.0/0 0.0.0.0/0 tcp 22,873 2 0.0.0.0/0 0.0.0.0/0 tcp 22,873 2 $FW 0.0.0.0/0 tcp - 22,873 2 $FW 0.0.0.0/0 tcp - 22,873 3 $FW 0.0.0.0/0 tcp 80,443 3 $FW 0.0.0.0/0 tcp - 80,443 RESTORE 0.0.0.0/0 0.0.0.0/0 all - - - 0 CONTINUE 0.0.0.0/0 0.0.0.0/0 all - - - !0 4 0.0.0.0/0 0.0.0.0/0 ipp2p:all 4 $FW 0.0.0.0/0 ipp2p:all SAVE 0.0.0.0/0 0.0.0.0/0 all - - - !0 The issue is that when I do a sync of my portage tree (using rsync - port 873), I see this in "shorewall show connections" tcp 6 431999 ESTABLISHED src=60.x.x.x dst=212.154.208.7 sport=39354 dport=873 packets=1530 bytes=83565 src=212.154.208.7 dst=60.x.x.x sport=873 dport=39354 packets=2220 bytes=2978964 [ASSURED] mark=0 use=6 Notice that the mark=0? Shouldn''t I be expecting that this mark be mark=2? The odd thing here is that I do notice that the packets _does_ go into class 2. Am I missing something Here?? Shorewall show tc (BEfore starting rsync) ============class htb 1:12 parent 1:1 leaf 12: prio 2 quantum 2880 rate 225000bit ceil 225000bit burst 1772b/8 mpu 0b overhead 0b cburst 1772b/8 mpu 0b overhead 0b level 0 Sent 10592 bytes 24 pkt (dropped 0, overlimits 0 requeues 0) rate 600bit 0pps backlog 0b 0p requeues 0 lended: 24 borrowed: 0 giants: 0 tokens: 23487 ctokens: 23487 ======== Shorewall show tc (AFTER starting rsync) ============class htb 1:12 parent 1:1 leaf 12: prio 2 quantum 2880 rate 225000bit ceil 225000bit burst 1772b/8 mpu 0b overhead 0b cburst 1772b/8 mpu 0b overhead 0b level 0 Sent 58108 bytes 141 pkt (dropped 0, overlimits 0 requeues 0) rate 4536bit 1pps backlog 0b 0p requeues 0 lended: 141 borrowed: 0 giants: 0 tokens: 43720 ctokens: 43720 ============= The other thing which I''m seeing is that, (I just started to use ipp2p), only a handful of connections are getting marked as P2P packets and going into Queue 5. The majority of t hem are going into Queue 4 (default queue). I actually tried stopping all traffic and only starting the FC6 Bittorrent and eveything (98%) are going into Queue 4 and it''s getting marked as such in the ouput of "shorewall show connections." What''s the list users success rate with ipp2p? (or is L7-Filter a better alternative?) ------------------------------------------------------------------------- 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
2006-Nov-15 16:01 UTC
Re: TCclasses/Rules - Packets not marked correctly but seems to be in correct queues
Ow Mun Heng wrote:> Hi All, > > Wondering if someone can shed some light on this. > > Shorewall-3.08 > Gentoo LInux > > tcclasses > ppp0 1 full full 1 > tcp-ack,tos-minimize-delay > ppp0 2 9*full/10 9*full/10 2 > ppp0 3 8*full/10 9*full/10 3 > ppp0 4 1*full/10 9*full/10 5 > ppp0 5 1*full/10 6*full/10 4 > default > > tcrules > 1 0.0.0.0/0 0.0.0.0/0 icmp echo-request > 1 0.0.0.0/0 0.0.0.0/0 icmp echo-reply > 2 0.0.0.0/0 0.0.0.0/0 tcp 22,873 > 2 0.0.0.0/0 0.0.0.0/0 tcp 22,873 > 2 $FW 0.0.0.0/0 tcp - 22,873 > 2 $FW 0.0.0.0/0 tcp - 22,873 > 3 $FW 0.0.0.0/0 tcp 80,443 > 3 $FW 0.0.0.0/0 tcp - 80,443 > RESTORE 0.0.0.0/0 0.0.0.0/0 all - - - 0 > CONTINUE 0.0.0.0/0 0.0.0.0/0 all - - - !0 > 4 0.0.0.0/0 0.0.0.0/0 ipp2p:all > 4 $FW 0.0.0.0/0 ipp2p:all > SAVE 0.0.0.0/0 0.0.0.0/0 all - - - !0 > > > The issue is that when I do a sync of my portage tree (using rsync - > port 873), I see this in "shorewall show connections" > > tcp 6 431999 ESTABLISHED src=60.x.x.x dst=212.154.208.7 sport=39354 > dport=873 packets=1530 bytes=83565 src=212.154.208.7 dst=60.x.x.x > sport=873 dport=39354 packets=2220 bytes=2978964 [ASSURED] mark=0 use=6 > > Notice that the mark=0? Shouldn''t I be expecting that this mark be > mark=2? The odd thing here is that I do notice that the packets _does_ > go into class 2. Am I missing something Here??Yes -- you are not saving that mark in the connection. Traffic from port 873 will match the CONTINUE rule. -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
Stefan Adams
2006-Nov-15 16:13 UTC
Re: TCclasses/Rules - Packets not marked correctly but seems to be in correct queues
On 11/15/06, Tom Eastep <teastep@shorewall.net> wrote:> > Notice that the mark=0? Shouldn''t I be expecting that this mark be > > mark=2? The odd thing here is that I do notice that the packets _does_ > > go into class 2. Am I missing something Here?? > > Yes -- you are not saving that mark in the connection. Traffic from port 873 > will match the CONTINUE rule.How should he save that mark in the connection?> -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
Ow Mun Heng
2006-Nov-16 01:04 UTC
Re: TCclasses/Rules - Packets not marked correctly but seems to be in correct queues
On Wed, 2006-11-15 at 10:13 -0600, Stefan Adams wrote:> On 11/15/06, Tom Eastep <teastep@shorewall.net> wrote: > > > Notice that the mark=0? Shouldn''t I be expecting that this mark be > > > mark=2? The odd thing here is that I do notice that the packets _does_ > > > go into class 2. Am I missing something Here?? > > > > Yes -- you are not saving that mark in the connection. Traffic from port 873 > > will match the CONTINUE rule. > > How should he save that mark in the connection?I''m stumped too. But I guess I''ll re-read the documentation and try again to see if I understand it more. Thanks ------------------------------------------------------------------------- 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
Ow Mun Heng
2006-Nov-16 02:53 UTC
Re: TCclasses/Rules - Packets not marked correctly but seems to be in correct queues
On Wed, 2006-11-15 at 08:01 -0800, Tom Eastep wrote:> Ow Mun Heng wrote: > > Hi All, > > > > Wondering if someone can shed some light on this. > > > > Shorewall-3.08 > > Gentoo LInux > > > > tcclasses > > ppp0 1 full full 1 > > tcp-ack,tos-minimize-delay > > ppp0 2 9*full/10 9*full/10 2 > > ppp0 3 8*full/10 9*full/10 3 > > ppp0 4 1*full/10 9*full/10 5 > > ppp0 5 1*full/10 6*full/10 4 > > default > > > > tcrules > > 1 0.0.0.0/0 0.0.0.0/0 icmp echo-request > > 1 0.0.0.0/0 0.0.0.0/0 icmp echo-reply > > 2 0.0.0.0/0 0.0.0.0/0 tcp 22,873 > > 2 0.0.0.0/0 0.0.0.0/0 tcp 22,873 > > 2 $FW 0.0.0.0/0 tcp - 22,873 > > 2 $FW 0.0.0.0/0 tcp - 22,873 > > 3 $FW 0.0.0.0/0 tcp 80,443 > > 3 $FW 0.0.0.0/0 tcp - 80,443 > > RESTORE 0.0.0.0/0 0.0.0.0/0 all - - - 0 > > CONTINUE 0.0.0.0/0 0.0.0.0/0 all - - - !0 > > 4 0.0.0.0/0 0.0.0.0/0 ipp2p:all > > 4 $FW 0.0.0.0/0 ipp2p:all > > SAVE 0.0.0.0/0 0.0.0.0/0 all - - - !0 > > > > > > The issue is that when I do a sync of my portage tree (using rsync - > > port 873), I see this in "shorewall show connections" > > > > tcp 6 431999 ESTABLISHED src=60.x.x.x dst=212.154.208.7 sport=39354 > > dport=873 packets=1530 bytes=83565 src=212.154.208.7 dst=60.x.x.x > > sport=873 dport=39354 packets=2220 bytes=2978964 [ASSURED] mark=0 use=6 > > > > Notice that the mark=0? Shouldn''t I be expecting that this mark be > > mark=2? The odd thing here is that I do notice that the packets _does_ > > go into class 2. Am I missing something Here?? > > Yes -- you are not saving that mark in the connection. Traffic from port 873 > will match the CONTINUE rule.Re-Reading the website I put these in so that it reflects the rsync packets coming from the Firewall/server. Still doesn''t mark it as Mark=2, it still goes into Mark=0 1 0.0.0.0/0 0.0.0.0/0 icmp echo-request 1 0.0.0.0/0 0.0.0.0/0 icmp echo-reply 2 0.0.0.0/0 0.0.0.0/0 tcp 22,873 2 0.0.0.0/0 0.0.0.0/0 tcp 22,873 2 $FW 0.0.0.0/0 tcp - 22,873 2 $FW 0.0.0.0/0 tcp - 22,873 3 $FW 0.0.0.0/0 tcp 80,443 3 $FW 0.0.0.0/0 tcp - 80,443 RESTORE $FW 0.0.0.0/0 all - - - 0 RESTORE 0.0.0.0/0 0.0.0.0/0 all - - - 0 CONTINUE $FW 0.0.0.0/0 all - - - !0 CONTINUE 0.0.0.0/0 0.0.0.0/0 all - - - !0 4 0.0.0.0/0 0.0.0.0/0 ipp2p:all 4 $FW 0.0.0.0/0 ipp2p:all SAVE $FW 0.0.0.0/0 all - - - !0 SAVE 0.0.0.0/0 0.0.0.0/0 all - - - !0 ------------------------------------------------------------------------- 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
2006-Nov-16 05:09 UTC
Re: TCclasses/Rules - Packets not marked correctly but seems to be in correct queues
Ow Mun Heng wrote:> On Wed, 2006-11-15 at 08:01 -0800, Tom Eastep wrote:>>> >>> The issue is that when I do a sync of my portage tree (using rsync - >>> port 873), I see this in "shorewall show connections" >>> >>> tcp 6 431999 ESTABLISHED src=60.x.x.x dst=212.154.208.7 sport=39354 >>> dport=873 packets=1530 bytes=83565 src=212.154.208.7 dst=60.x.x.x >>> sport=873 dport=39354 packets=2220 bytes=2978964 [ASSURED] mark=0 use=6 >>> >>> Notice that the mark=0? Shouldn''t I be expecting that this mark be >>> mark=2? The odd thing here is that I do notice that the packets _does_ >>> go into class 2. Am I missing something Here?? >> Yes -- you are not saving that mark in the connection. Traffic from port 873 >> will match the CONTINUE rule. > > Re-Reading the website I put these in so that it reflects the rsync packets coming from the Firewall/server. > Still doesn''t mark it as Mark=2, it still goes into Mark=0And why does it matter? -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
Ow Mun Heng
2006-Nov-16 05:15 UTC
Re: TCclasses/Rules - Packets not marked correctly but seems to be in correct queues
On Wed, 2006-11-15 at 21:09 -0800, Tom Eastep wrote:> Ow Mun Heng wrote: > > On Wed, 2006-11-15 at 08:01 -0800, Tom Eastep wrote: > > >>> > >>> The issue is that when I do a sync of my portage tree (using rsync - > >>> port 873), I see this in "shorewall show connections" > >>> > >>> tcp 6 431999 ESTABLISHED src=60.x.x.x dst=212.154.208.7 sport=39354 > >>> dport=873 packets=1530 bytes=83565 src=212.154.208.7 dst=60.x.x.x > >>> sport=873 dport=39354 packets=2220 bytes=2978964 [ASSURED] mark=0 use=6 > >>> > >>> Notice that the mark=0? Shouldn''t I be expecting that this mark be > >>> mark=2? The odd thing here is that I do notice that the packets _does_ > >>> go into class 2. Am I missing something Here?? > >> Yes -- you are not saving that mark in the connection. Traffic from port 873 > >> will match the CONTINUE rule. > > > > Re-Reading the website I put these in so that it reflects the rsync packets coming from the Firewall/server. > > Still doesn''t mark it as Mark=2, it still goes into Mark=0 > > And why does it matter?In this example, it really doesn''t, however I''m finding that a lot of the P2P packets don''t go into the correct queues, it''s instead going into the default queue (Queue 4) ------------------------------------------------------------------------- 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
2006-Nov-16 15:50 UTC
Re: TCclasses/Rules - Packets not marked correctly but seems to be in correct queues
Ow Mun Heng wrote:> On Wed, 2006-11-15 at 21:09 -0800, Tom Eastep wrote: > >> And why does it matter? > > In this example, it really doesn''t, however I''m finding that a lot of > the P2P packets don''t go into the correct queues, it''s instead going > into the default queue (Queue 4)Is it P2P traffic to/from the firewall itself that you are concerned about? -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
Ow Mun Heng
2006-Nov-16 23:00 UTC
Re: TCclasses/Rules - Packets not marked correctly but seems to be in correct queues
On Thu, 2006-11-16 at 07:50 -0800, Tom Eastep wrote:> Ow Mun Heng wrote: > > On Wed, 2006-11-15 at 21:09 -0800, Tom Eastep wrote: > > > >> And why does it matter? > > > > In this example, it really doesn''t, however I''m finding that a lot of > > the P2P packets don''t go into the correct queues, it''s instead going > > into the default queue (Queue 4) > > Is it P2P traffic to/from the firewall itself that you are concerned about?That is in fact correct, I wasn''t sure if the cause if due to incorrect markings or because ipp2p is not able to differentiate the packets. (I figured that if it can''t even mark rsync packets, then perhaps something else is the matter and not ipp2p) Would really appreciate some inputs. (Or perhaps letting me know the list''s general perception of ipp2p''s capability etc.) Many Thanks ------------------------------------------------------------------------- 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
2006-Nov-17 00:46 UTC
Re: TCclasses/Rules - Packets not marked correctly but seems to be in correct queues
Ow Mun Heng wrote:> On Thu, 2006-11-16 at 07:50 -0800, Tom Eastep wrote: >> Ow Mun Heng wrote: >>> On Wed, 2006-11-15 at 21:09 -0800, Tom Eastep wrote: >>> >>>> And why does it matter? >>> In this example, it really doesn''t, however I''m finding that a lot of >>> the P2P packets don''t go into the correct queues, it''s instead going >>> into the default queue (Queue 4) >> Is it P2P traffic to/from the firewall itself that you are concerned about? > > That is in fact correct, I wasn''t sure if the cause if due to incorrect > markings or because ipp2p is not able to differentiate the packets. > (I figured that if it can''t even mark rsync packets, then perhaps > something else is the matter and not ipp2p)It IS marking rsync packets. Your ruleset just isn''t saving those marks.> 2 0.0.0.0/0 0.0.0.0/0 tcp 22,873 > 2 0.0.0.0/0 0.0.0.0/0 tcp 22,873 > 2 $FW 0.0.0.0/0 tcp - 22,873 > 2 $FW 0.0.0.0/0 tcp - 22,873 > 3 $FW 0.0.0.0/0 tcp 80,443 > 3 $FW 0.0.0.0/0 tcp - 80,443 > RESTORE 0.0.0.0/0 0.0.0.0/0 all - - - 0 > CONTINUE 0.0.0.0/0 0.0.0.0/0 all - - - !0The marks you are assigning in the first 4 rules (why you have duplicated rule, I have no clue) cause the CONTINUE rule to be taken. So when you "shorewall show connections", the mark in the connection is still 0.> > Would really appreciate some inputs. (Or perhaps letting me know the > list''s general perception of ipp2p''s capability etc.)Similarly, you are not saving the ipp2p mark values for traffic from your firewall.> 4 0.0.0.0/0 0.0.0.0/0 ipp2p:all > 4 $FW 0.0.0.0/0 ipp2p:all > SAVE 0.0.0.0/0 0.0.0.0/0 all - - - !0Your second rule marks those few $FW->net packets that ipp2p can identify but your last rule only stores the mark for forwarded traffic. You also need: SAVE $FW 0.0.0.0/0 all - - - !0 Please refer to http://www.shorewall.net/PacketMarking.html -- and I recommend that you totally separate your rules that deal with forwarded traffic from those that deal with traffic originating on the firewall. Otherwise, you will continue to have these sorts of oversights. -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
2006-Nov-17 00:55 UTC
Re: TCclasses/Rules - Packets not marked correctly but seems to be in correct queues
Tom Eastep wrote:> Ow Mun Heng wrote: >> On Thu, 2006-11-16 at 07:50 -0800, Tom Eastep wrote: >>> Ow Mun Heng wrote: >>>> On Wed, 2006-11-15 at 21:09 -0800, Tom Eastep wrote: >>>> >>>>> And why does it matter? >>>> In this example, it really doesn''t, however I''m finding that a lot of >>>> the P2P packets don''t go into the correct queues, it''s instead going >>>> into the default queue (Queue 4) >>> Is it P2P traffic to/from the firewall itself that you are concerned about? >> That is in fact correct, I wasn''t sure if the cause if due to incorrect >> markings or because ipp2p is not able to differentiate the packets. >> (I figured that if it can''t even mark rsync packets, then perhaps >> something else is the matter and not ipp2p) > > It IS marking rsync packets. Your ruleset just isn''t saving those marks. > >> 2 0.0.0.0/0 0.0.0.0/0 tcp 22,873 >> 2 0.0.0.0/0 0.0.0.0/0 tcp 22,873 >> 2 $FW 0.0.0.0/0 tcp - 22,873 >> 2 $FW 0.0.0.0/0 tcp - 22,873 >> 3 $FW 0.0.0.0/0 tcp 80,443 >> 3 $FW 0.0.0.0/0 tcp - 80,443 >> RESTORE 0.0.0.0/0 0.0.0.0/0 all - - - 0 >> CONTINUE 0.0.0.0/0 0.0.0.0/0 all - - - !0 > > The marks you are assigning in the first 4 rules (why you have > duplicated rule, I have no clue) cause the CONTINUE rule to be taken.I should note that if the rsync is occurring to/from the firewall then the packets are not processed by the CONTINUE rule which only deals with forwarded traffic. So only packets marked by the first two rules match the CONTINUE. -- 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
Ow Mun Heng
2006-Nov-17 16:12 UTC
Re: TCclasses/Rules - Packets not marked correctly but seems to be in correct queues
On Thu, 2006-11-16 at 16:55 -0800, Tom Eastep wrote:> Tom Eastep wrote: > > Ow Mun Heng wrote: > > > >> 2 0.0.0.0/0 0.0.0.0/0 tcp 22,873 > >> 2 0.0.0.0/0 0.0.0.0/0 tcp 22,873 > >> 2 $FW 0.0.0.0/0 tcp - 22,873 > >> 2 $FW 0.0.0.0/0 tcp - 22,873 > >> 3 $FW 0.0.0.0/0 tcp 80,443 > >> 3 $FW 0.0.0.0/0 tcp - 80,443 > >> RESTORE 0.0.0.0/0 0.0.0.0/0 all - - - 0 > >> CONTINUE 0.0.0.0/0 0.0.0.0/0 all - - - !0 > > > > The marks you are assigning in the first 4 rules (why you have > > duplicated rule, I have no clue) cause the CONTINUE rule to be taken. > > I should note that if the rsync is occurring to/from the firewall then > the packets are not processed by the CONTINUE rule which only deals with > forwarded traffic. > > So only packets marked by the first two rules match the CONTINUE.Tom, I really appreciate all the help, but I''m seriously wondering what''s happening. I''ve stripped out all the tcrules and leaving only this one Simple Rule 3 192.168.10.100/32 0.0.0.0/0 tcp 22,873 tcdevices eth1 500kbit 250kbit # FW Lan facing interface I then initiated an scp transfer from the firewall to my laptop (192.168.10.100) I then grepped the connection. $shorewall show connections | grep src=192.168.10.2 tcp 6 431999 ESTABLISHED src=192.168.10.2 dst=192.168.10.100 sport=37309 dport=22 packets=10298 bytes=14682124 src=192.168.10.100 dst=192.168.10.2 sport=22 dport=37309 packets=5411 bytes=295808 [ASSURED] mark=0 use=91 The mark is still at mark=0 Traffic is going into Class 3. class htb 2:1 root rate 2500Kbit ceil 2500Kbit burst 4624b/8 mpu 0b overhead 0b cburst 4624b/8 mpu 0b overhead 0b level 7 Sent 8071168 bytes 6132 pkt (dropped 0, overlimits 0 requeues 0) rate 1363Kbit 126pps backlog 0b 0p requeues 0 lended: 771 borrowed: 0 giants: 0 tokens: -5601 ctokens: -5601 class htb 2:13 parent 2:1 leaf 13: prio 3 quantum 24000 rate 2000Kbit ceil 2250Kbit burst 3999b/8 mpu 0b overhead 0b cburst 4311b/8 mpu 0b overhead 0b level 0 Sent 8000538 bytes 5565 pkt (dropped 0, overlimits 0 requeues 0) rate 1382Kbit 120pps backlog 0b 39p requeues 0 lended: 4755 borrowed: 771 giants: 0 tokens: -12391 ctokens: -12631 class htb 2:12 parent 2:1 leaf 12: prio 2 quantum 27000 rate 2250Kbit ceil 2250Kbit burst 4311b/8 mpu 0b overhead 0b cburst 4311b/8 mpu 0b overhead 0b level 0 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 lended: 0 borrowed: 0 giants: 0 tokens: 12559 ctokens: 12559 class htb 2:15 parent 2:1 leaf 15: prio 4 quantum 3000 rate 250000bit ceil 1500Kbit burst 1811b/8 mpu 0b overhead 0b cburst 3374b/8 mpu 0b overhead 0b level 0 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 lended: 0 borrowed: 0 giants: 0 tokens: 47500 ctokens: 14745 class htb 2:14 parent 2:1 leaf 14: prio 5 quantum 3000 rate 250000bit ceil 2250Kbit burst 1811b/8 mpu 0b overhead 0b cburst 4311b/8 mpu 0b overhead 0b level 0 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 lended: 0 borrowed: 0 giants: 0 tokens: 47500 ctokens: 12559 (I''m starting to pull hair out) ------------------------------------------------------------------------- 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
2006-Nov-17 16:23 UTC
Re: TCclasses/Rules - Packets not marked correctly but seems to be in correct queues
Ow Mun Heng wrote:> On Thu, 2006-11-16 at 16:55 -0800, Tom Eastep wrote: >> Tom Eastep wrote: >>> Ow Mun Heng wrote: >>> >>>> 2 0.0.0.0/0 0.0.0.0/0 tcp 22,873 >>>> 2 0.0.0.0/0 0.0.0.0/0 tcp 22,873 >>>> 2 $FW 0.0.0.0/0 tcp - 22,873 >>>> 2 $FW 0.0.0.0/0 tcp - 22,873 >>>> 3 $FW 0.0.0.0/0 tcp 80,443 >>>> 3 $FW 0.0.0.0/0 tcp - 80,443 >>>> RESTORE 0.0.0.0/0 0.0.0.0/0 all - - - 0 >>>> CONTINUE 0.0.0.0/0 0.0.0.0/0 all - - - !0 >>> The marks you are assigning in the first 4 rules (why you have >>> duplicated rule, I have no clue) cause the CONTINUE rule to be taken. >> I should note that if the rsync is occurring to/from the firewall then >> the packets are not processed by the CONTINUE rule which only deals with >> forwarded traffic. >> >> So only packets marked by the first two rules match the CONTINUE. > > Tom, I really appreciate all the help, but I''m seriously wondering > what''s happening. > > I''ve stripped out all the tcrules and leaving only this one Simple Rule > > 3 192.168.10.100/32 0.0.0.0/0 tcp 22,873 > > tcdevices > eth1 500kbit 250kbit # FW Lan facing > interface > > I then initiated an scp transfer from the firewall to my laptop > (192.168.10.100) > I then grepped the connection. > > $shorewall show connections | grep src=192.168.10.2 > tcp 6 431999 ESTABLISHED src=192.168.10.2 dst=192.168.10.100 > sport=37309 dport=22 packets=10298 bytes=14682124 > src=192.168.10.100 dst=192.168.10.2 sport=22 dport=37309 packets=5411 > bytes=295808 [ASSURED] mark=0 use=91 > > The mark is still at mark=0I sure wish that you would read http://www.shorewall.net/PacketMarking.html carefully. a) Your tcrule *does not mark traffic from applications running on your firewall*. I don''t know how I can make that any clearer. The only kind of rule that deals with those packets is a rule that has $FW in the SOURCE column. I didn''t design it this way -- I''m simply following the model that Netfilter provides me; it handles OUTPUT and FORWARD traffic separately and with different restrictions about what the rules may look like. b) Even if you get the rule right, "shorewall show connections" is *not going to show you packet marks* which is what your rule is setting. It displays the *connection mark* (Hint: It''s showing you *connections*, not *packets*). -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
Ow Mun Heng
2006-Nov-17 17:05 UTC
Re: TCclasses/Rules - Packets not marked correctly but seems to be in correct queues
On Fri, 2006-11-17 at 08:23 -0800, Tom Eastep wrote:> Ow Mun Heng wrote: > > On Thu, 2006-11-16 at 16:55 -0800, Tom Eastep wrote: > >> Tom Eastep wrote: > >>> Ow Mun Heng wrote: > >>> > >>>> 2 0.0.0.0/0 0.0.0.0/0 tcp 22,873 > >>>> 2 0.0.0.0/0 0.0.0.0/0 tcp 22,873 > >>>> 2 $FW 0.0.0.0/0 tcp - 22,873 > >>>> 2 $FW 0.0.0.0/0 tcp - 22,873 > >>>> 3 $FW 0.0.0.0/0 tcp 80,443 > >>>> 3 $FW 0.0.0.0/0 tcp - 80,443 > >>>> RESTORE 0.0.0.0/0 0.0.0.0/0 all - - - 0 > >>>> CONTINUE 0.0.0.0/0 0.0.0.0/0 all - - - !0 > >>> The marks you are assigning in the first 4 rules (why you have > >>> duplicated rule, I have no clue) cause the CONTINUE rule to be taken. > >> I should note that if the rsync is occurring to/from the firewall then > >> the packets are not processed by the CONTINUE rule which only deals with > >> forwarded traffic. > >> > >> So only packets marked by the first two rules match the CONTINUE. > > > > Tom, I really appreciate all the help, but I''m seriously wondering > > what''s happening. > > > > I''ve stripped out all the tcrules and leaving only this one Simple Rule > > > > 3 192.168.10.100/32 0.0.0.0/0 tcp 22,873 > > > > tcdevices > > eth1 500kbit 250kbit # FW Lan facing > > interface > > > > I then initiated an scp transfer from the firewall to my laptop > > (192.168.10.100) > > I then grepped the connection. > > > > $shorewall show connections | grep src=192.168.10.2 > > tcp 6 431999 ESTABLISHED src=192.168.10.2 dst=192.168.10.100 > > sport=37309 dport=22 packets=10298 bytes=14682124 > > src=192.168.10.100 dst=192.168.10.2 sport=22 dport=37309 packets=5411 > > bytes=295808 [ASSURED] mark=0 use=91 > > > > The mark is still at mark=0 > > I sure wish that you would read http://www.shorewall.net/PacketMarking.html > carefully.I''ve re-read it a couple of time and I tried a few variations of it.> > a) Your tcrule *does not mark traffic from applications running on your > firewall*. I don''t know how I can make that any clearer. The only kind of rule > that deals with those packets is a rule that has $FW in the SOURCE column. I > didn''t design it this way -- I''m simply following the model that Netfilter > provides me; it handles OUTPUT and FORWARD traffic separately and with different > restrictions about what the rules may look like.I''ve changed it to 2 $FW 0.0.0.0/0 tcp 22,873 2 $FW 0.0.0.0/0 tcp - 22,873 shorewall show connections | grep 192.168.10.2 tcp 6 431999 ESTABLISHED src=192.168.10.2 dst=192.168.10.100 sport=53476 dport=22 packets=225 bytes=305772 src=192.168.10.100 dst=192.168.10.2 sport=22 dport=53476 packets=151 bytes=10788 [ASSURED] mark=0 use=51 On the flip side, seems like it is marking p2p packets (Properly when I revert to the original settings) cat /etc/tcrules 1 0.0.0.0/0 0.0.0.0/0 icmp echo-request 1 0.0.0.0/0 0.0.0.0/0 icmp echo-reply 2 0.0.0.0/0 0.0.0.0/0 tcp 22,873 2 $FW 0.0.0.0/0 tcp 22,873 2 0.0.0./0 0.0.0.0/0 tcp - 22,873 2 $FW 0.0.0.0/0 tcp - 22,873 3 0.0.0.0/0 0.0.0.0/0 tcp 80,443 3 $FW 0.0.0.0/0 tcp 80,443 3 0.0.0.0/0 0.0.0.0/0 tcp - 80,443 3 $FW 0.0.0.0/0 tcp - 80,443 RESTORE 0.0.0.0/0 0.0.0.0/0 all - - - 0 RESTORE $FW 0.0.0.0/0 all - - - 0 CONTINUE 0.0.0.0/0 0.0.0.0/0 all - - - !0 CONTINUE $FW 0.0.0.0/0 all - - - !0 4 0.0.0.0/0 0.0.0.0/0 ipp2p:all 4 $FW 0.0.0.0/0 ipp2p:all SAVE 0.0.0.0/0 0.0.0.0/0 all - - - !0 SAVE $FW 0.0.0.0/0 all - - - !0 tcp 6 274937 ESTABLISHED src=x.x.x.x dst=y.y.y.y sport=2791 dport=49519 packets=8 bytes=736 src=x.x.x.x dst=y.y.y.y sport=49519 dport=2791 packets=16 bytes=2664 [ASSURED] mark=4 use=1> b) Even if you get the rule right, "Obviously I''m still oblivious to the solution> shorewall show connections" is *not going to > show you packet marks* which is what your rule is setting. It displays the > *connection mark* (Hint: It''s showing you *connections*, not *packets*).Huh? So essentially the output from /proc/net/ip_conntrack and shorewall show connections are not going to let me see the packet marks?. I''m confused on the difference. (googling on connection marks vs packet marks turned out nothing until page 5) If I understand correctly, a Connection = A <-> B however, between A <-> B, there are > 1 packets (at least 3 for the handshake). It is these packets which are marked and not the connection. So, I will never see those/them marked when I look at shorewall show connections/ip_conntrack? Am I getting it right?? The Connection Mark will Always be either 0 or 4?? (0 = Not P2P Packets and 4=P2P packets, in my case) I just reread through the archives (searching for all traffic related posts since 2 years ago) and I came across this [quote] Subject : Re: [Shorewall-users] Bandwidth Shaping Date : Mon, 18 Apr 2005 11:08:58 -0700 (Tue, 02:08 MYT) ... I was in a PHD program intending to be a college Math Professor and reluctantly entered the nascent computer industry in969 only because at that time new PHDs in Mathematics were lucky to get a temporary chair in a small college for $6000/yr. So if you use my software, I want you to also learn something... ... [/quote] ------------------------------------------------------------------------- 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
2006-Nov-17 18:26 UTC
Re: TCclasses/Rules - Packets not marked correctly but seems to be in correct queues
Ow Mun Heng wrote:> On Fri, 2006-11-17 at 08:23 -0800, Tom Eastep wrote:>> a) Your tcrule *does not mark traffic from applications running on your >> firewall*. I don''t know how I can make that any clearer. The only kind of rule >> that deals with those packets is a rule that has $FW in the SOURCE column. I >> didn''t design it this way -- I''m simply following the model that Netfilter >> provides me; it handles OUTPUT and FORWARD traffic separately and with different >> restrictions about what the rules may look like. > > I''ve changed it to > 2 $FW 0.0.0.0/0 tcp 22,873 > 2 $FW 0.0.0.0/0 tcp - 22,873 > > shorewall show connections | grep 192.168.10.2 > tcp 6 431999 ESTABLISHED src=192.168.10.2 dst=192.168.10.100 > sport=53476 dport=22 packets=225 bytes=305772 src=192.168.10.100 > dst=192.168.10.2 sport=22 dport=53476 packets=151 bytes=10788 [ASSURED] > mark=0 use=51 > > On the flip side, seems like it is marking p2p packets (Properly when I > revert to the original settings) > > cat /etc/tcrules > 1 0.0.0.0/0 0.0.0.0/0 icmp echo-request > 1 0.0.0.0/0 0.0.0.0/0 icmp echo-reply > 2 0.0.0.0/0 0.0.0.0/0 tcp 22,873 > 2 $FW 0.0.0.0/0 tcp 22,873 > 2 0.0.0./0 0.0.0.0/0 tcp - 22,873 > 2 $FW 0.0.0.0/0 tcp - 22,873 > 3 0.0.0.0/0 0.0.0.0/0 tcp 80,443 > 3 $FW 0.0.0.0/0 tcp 80,443 > 3 0.0.0.0/0 0.0.0.0/0 tcp - 80,443 > 3 $FW 0.0.0.0/0 tcp - 80,443 > RESTORE 0.0.0.0/0 0.0.0.0/0 all - - - > 0 > RESTORE $FW 0.0.0.0/0 all - - - > 0 > CONTINUE 0.0.0.0/0 0.0.0.0/0 all - - > - !0 > CONTINUE $FW 0.0.0.0/0 all - - > - !0 > 4 0.0.0.0/0 0.0.0.0/0 ipp2p:all > 4 $FW 0.0.0.0/0 ipp2p:all > SAVE 0.0.0.0/0 0.0.0.0/0 all - - > - !0 > SAVE $FW 0.0.0.0/0 all - - > - !0 > > tcp 6 274937 ESTABLISHED src=x.x.x.x dst=y.y.y.y sport=2791 > dport=49519 packets=8 bytes=736 src=x.x.x.x dst=y.y.y.y sport=49519 > dport=2791 packets=16 bytes=2664 [ASSURED] mark=4 use=1Please rewrite your rules this way so you can look at them and have some chance of understanding them: # # Traffic originating on the firewall # 2 $FW 0.0.0.0/0 tcp 22,873 2 $FW 0.0.0.0/0 tcp - 22,873 3 $FW 0.0.0.0/0 tcp 80,443 3 $FW 0.0.0.0/0 tcp - 80,443 RESTORE $FW 0.0.0.0/0 all - - - 0 CONTINUE $FW 0.0.0.0/0 all - - - !0 4 $FW 0.0.0.0/0 ipp2p:all SAVE $FW 0.0.0.0/0 all - - - !0 # # Traffic being forwarded through the firewall # 1 0.0.0.0/0 0.0.0.0/0 icmp echo-request 1 0.0.0.0/0 0.0.0.0/0 icmp echo-reply 2 0.0.0.0/0 0.0.0.0/0 tcp 22,873 3 0.0.0.0/0 0.0.0.0/0 tcp 80,443 3 0.0.0.0/0 0.0.0.0/0 tcp - 80,443 RESTORE 0.0.0.0/0 0.0.0.0/0 all - - - 0 CONTINUE 0.0.0.0/0 0.0.0.0/0 all - - - !0 4 0.0.0.0/0 0.0.0.0/0 ipp2p:all SAVE 0.0.0.0/0 0.0.0.0/0 all - - - !0> >> b) Even if you get the rule right, " > > Obviously I''m still oblivious to the solutionSolution to what?> >> shorewall show connections" is *not going to >> show you packet marks* which is what your rule is setting. It displays the >> *connection mark* (Hint: It''s showing you *connections*, not *packets*). > > Huh? So essentially the output from /proc/net/ip_conntrack and shorewall > show connections are not going to let me see the packet marks?.How could you possibly see the mark on each of the 1,000s of packets flying through your firewall?> > I''m confused on the difference. (googling on connection marks vs packet > marks turned out nothing until page 5) > If I understand correctly, > > a Connection = A <-> B > however, between A <-> B, there are > 1 packets (at least 3 for the > handshake). It is these packets which are marked and not the connection. > So, I will never see those/them marked when I look at shorewall show > connections/ip_conntrack?From http://www.shorewall.net/PacketMarking.html: "Each active connection (even those that are not yet in ESTABLISHED state) has a mark value that is distinct from the packet marks. Connection mark values can be seen using the shorewall show connections command." The flip side of that is that there is no way to see the mark on each of the 1,000s of packets flying through your firewall.> > Am I getting it right??Mostly -- again, each individual packet going through your firewall has it''s own mark which is not visible by any outside means. But looking at the output of "shorewall show mangle", you can see how many packets matched each of your rules.> The Connection Mark will Always be either 0 or > 4?? (0 = Not P2P Packets and 4=P2P packets, in my case)Yes. In both of your SAVE rules above, the packets matching those rules will always have a value of 4. So in your case, connection marks are always either 0 (non-p2p) or 4 (p2p). -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
Brian J. Murrell
2006-Nov-17 18:33 UTC
Re: TCclasses/Rules - Packets not marked correctly but seems to be in correct queues
A tool that might help with this kind of query is "sch_log" http://kernel.umbrella.ro/net/. It will allow you to create a virtual network interface to your qdisc so that you can, for example, tcpdump a qdisc and see exactly what packets are being scheduled for a qdisc. You could of course use this to audit the marking and classification of your packets to see if anything is leaking your expected classifications. Cheers, b. -- My other computer is your Microsoft Windows server. Brian J. Murrell ------------------------------------------------------------------------- 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
Ow Mun Heng
2006-Nov-19 04:09 UTC
Re: TCclasses/Rules - Packets not marked correctly but seems to be in correct queues
On Fri, 2006-11-17 at 10:26 -0800, Tom Eastep wrote:> Ow Mun Heng wrote: > > The Connection Mark will Always be either 0 or > > 4?? (0 = Not P2P Packets and 4=P2P packets, in my case) > > Yes. In both of your SAVE rules above, the packets matching those rules will > always have a value of 4. So in your case, connection marks are always either 0 > (non-p2p) or 4 (p2p).Finally.. I comprehend. :-) I guess(I am!) I was barking up the wrong tree. Thanks for all the help and sorry for the noise The ruleset is working fine. ------------------------------------------------------------------------- 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
2006-Nov-19 04:27 UTC
Re: TCclasses/Rules - Packets not marked correctly but seems to be in correct queues
Ow Mun Heng wrote:> On Fri, 2006-11-17 at 10:26 -0800, Tom Eastep wrote: >> Ow Mun Heng wrote: >>> The Connection Mark will Always be either 0 or >>> 4?? (0 = Not P2P Packets and 4=P2P packets, in my case) >> Yes. In both of your SAVE rules above, the packets matching those rules will >> always have a value of 4. So in your case, connection marks are always either 0 >> (non-p2p) or 4 (p2p). > > Finally.. I comprehend. :-) > I guess(I am!) I was barking up the wrong tree. > > Thanks for all the help and sorry for the noise > > The ruleset is working fine.Great! -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