I have the following in /etc/shorewall/accounting: #"Red" interface traffic red:COUNT - eth1 - red:COUNT - - eth1 DONE red The goal is to be tallying all traffic that hits my "red" (i.e. external) interface, whether Shorewall ends up dropping, rejecting, or accepting it. However, this seems to only be counting traffic that is actually accepted (including traffic that is forwarded through the firewall, both directions, obviously). Is there some modification I can make to this set of rules to track all traffic that reaches the interface? Or, maybe more ideally, is there a way to write accounting rules that include only dropped or rejected traffic? Or am I just flat wrong and this actually IS doing what I want it to already? -- "The reader is entertained by the journey of another, but the writer is the changer of worlds." - D''ni Proverb 0100111001000101010100100100010000100001 ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerry® mobile platform with sessions, labs & more. See new tools and technologies. Register for BlackBerry® DevCon today! http://p.sf.net/sfu/rim-devcon-copy1
On Wed, 2011-09-14 at 12:01 -0800, Travis Veazey wrote:> I have the following in /etc/shorewall/accounting: > > #"Red" interface traffic > red:COUNT - eth1 - > red:COUNT - - eth1 > DONE red > > The goal is to be tallying all traffic that hits my "red" (i.e. > external) interface, whether Shorewall ends up dropping, rejecting, or > accepting it. However, this seems to only be counting traffic that is > actually accepted (including traffic that is forwarded through the > firewall, both directions, obviously). > > Is there some modification I can make to this set of rules to track > all traffic that reaches the interface? Or, maybe more ideally, is > there a way to write accounting rules that include only dropped or > rejected traffic? Or am I just flat wrong and this actually IS doing > what I want it to already? >Accounting occurs before any filtering rules are processed. As a result, it accounts for all packets, whether actually passed or not. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerry® mobile platform with sessions, labs & more. See new tools and technologies. Register for BlackBerry® DevCon today! http://p.sf.net/sfu/rim-devcon-copy1
On Wed, Sep 14, 2011 at 12:37 PM, Tom Eastep <teastep@shorewall.net> wrote:> On Wed, 2011-09-14 at 12:01 -0800, Travis Veazey wrote: >> I have the following in /etc/shorewall/accounting: >> >> #"Red" interface traffic >> red:COUNT - eth1 - >> red:COUNT - - eth1 >> DONE red >> >> The goal is to be tallying all traffic that hits my "red" (i.e. >> external) interface, whether Shorewall ends up dropping, rejecting, or >> accepting it. However, this seems to only be counting traffic that is >> actually accepted (including traffic that is forwarded through the >> firewall, both directions, obviously). >> >> Is there some modification I can make to this set of rules to track >> all traffic that reaches the interface? Or, maybe more ideally, is >> there a way to write accounting rules that include only dropped or >> rejected traffic? Or am I just flat wrong and this actually IS doing >> what I want it to already? >> > > > Accounting occurs before any filtering rules are processed. As a result, > it accounts for all packets, whether actually passed or not. > > -TomHa! Well, doesn''t that just make things so very easy? And just to clarify, this does not apply -- at least not in the same way -- to accounting rules that look at packets which e.g. enter on eth0 and leave on eth1, right? For example, the rule: traffic:COUNT - eth1 eth0 would only count packets that actually get routed through (i.e. get accepted and routed), and would not count packets that hit eth1 but are then dropped or rejected, right? ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerry® mobile platform with sessions, labs & more. See new tools and technologies. Register for BlackBerry® DevCon today! http://p.sf.net/sfu/rim-devcon-copy1
On Wed, 2011-09-14 at 12:51 -0800, Travis Veazey wrote:> > Ha! Well, doesn''t that just make things so very easy? > > And just to clarify, this does not apply -- at least not in the same > way -- to accounting rules that look at packets which e.g. enter on > eth0 and leave on eth1, right? For example, the rule: > > traffic:COUNT - eth1 eth0 > > would only count packets that actually get routed through (i.e. get > accepted and routed), and would not count packets that hit eth1 but > are then dropped or rejected, right?It counts *all* packets that enter via eth1 and get routed out of eth0, regardless of their subsequent disposition. One more time - Accounting occurs *before any filtering*. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerry® mobile platform with sessions, labs & more. See new tools and technologies. Register for BlackBerry® DevCon today! http://p.sf.net/sfu/rim-devcon-copy1
On Wed, Sep 14, 2011 at 1:03 PM, Tom Eastep <teastep@shorewall.net> wrote:> On Wed, 2011-09-14 at 12:51 -0800, Travis Veazey wrote: > >> >> Ha! Well, doesn''t that just make things so very easy? >> >> And just to clarify, this does not apply -- at least not in the same >> way -- to accounting rules that look at packets which e.g. enter on >> eth0 and leave on eth1, right? For example, the rule: >> >> traffic:COUNT - eth1 eth0 >> >> would only count packets that actually get routed through (i.e. get >> accepted and routed), and would not count packets that hit eth1 but >> are then dropped or rejected, right? > > It counts *all* packets that enter via eth1 and get routed out of eth0, > regardless of their subsequent disposition. One more time - Accounting > occurs *before any filtering*. > > -TomSorry to keep beating a dead horse here, but I don''t understand: unless a packet matches a DNAT rule, or is part of an already established connection, or else is being masqueraded and forwarded on, how would it enter eth1 and get routed out of eth0? Or is the default case that all packets arriving at the external (i.e. non-masqueraded) interface get routed to the internal one, get counted via accounting rules, and *then* we look at which ones actually should get passed through? Or am I just completely misunderstanding what you mean when you say "filtering"? ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerry® mobile platform with sessions, labs & more. See new tools and technologies. Register for BlackBerry® DevCon today! http://p.sf.net/sfu/rim-devcon-copy1
Travis Veazey wrote:>Sorry to keep beating a dead horse here, but I don''t understand: >unless a packet matches a DNAT rule, or is part of an already >established connection, or else is being masqueraded and forwarded on, >how would it enter eth1 and get routed out of eth0?I think what Tom is saying is that the routing is decided before any filtering is applied - and accounting is also done prior to filtering. So packet arrives on eth1, the route is decided - ie it will go out via eth0. At this point, it is accounted for, and only then do the filtering rules get applied to decide if it will be passed or not. So it may well get counted - but then dropped. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerry® mobile platform with sessions, labs & more. See new tools and technologies. Register for BlackBerry® DevCon today! http://p.sf.net/sfu/rim-devcon-copy1
On Wed, 2011-09-14 at 13:14 -0800, Travis Veazey wrote:> Sorry to keep beating a dead horse here, but I don''t understand: > unless a packet matches a DNAT rule, or is part of an already > established connection, or else is being masqueraded and forwarded on, > how would it enter eth1 and get routed out of eth0? Or is the default > case that all packets arriving at the external (i.e. non-masqueraded) > interface get routed to the internal one, get counted via accounting > rules, and *then* we look at which ones actually should get passed > through? > > Or am I just completely misunderstanding what you mean when you say "filtering"?Please refer to http://www.shorewall.net/NetfilterOverview.html. Packets enter the firewall from the network and pass through PREROUTING and ingress traffic shaping (traffic policing, actually). It is in PREROUTING where DNAT occurs, either from DNAT rules or because the packet is part of an established connection. From there, then go to the blue box where they are routed (there output interface and next hop gateway, if any, are determined. The ''Routing Decision'' depends on whether the packet is to be processed by the Shorewall box itself (routing defined no output interface) or if it is to be forwarded to another host. From there, packets are sent to either INPUT or FORWARD. They go through the associated ''mangle'' chain (where tc marks and such are handled), then on to the Filter table INPUT or FORWARD chain. The *first thing* that happens to them there is Accounting. *After* that, they may be DROPped or REJECTed but they have already been counted. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerry® mobile platform with sessions, labs & more. See new tools and technologies. Register for BlackBerry® DevCon today! http://p.sf.net/sfu/rim-devcon-copy1
On Wed, Sep 14, 2011 at 1:34 PM, Tom Eastep <teastep@shorewall.net> wrote:> > Please refer to http://www.shorewall.net/NetfilterOverview.html. > > Packets enter the firewall from the network and pass through PREROUTING > and ingress traffic shaping (traffic policing, actually). It is in > PREROUTING where DNAT occurs, either from DNAT rules or because the > packet is part of an established connection. From there, then go to the > blue box where they are routed (there output interface and next hop > gateway, if any, are determined. > > The ''Routing Decision'' depends on whether the packet is to be processed > by the Shorewall box itself (routing defined no output interface) or if > it is to be forwarded to another host. From there, packets are sent to > either INPUT or FORWARD. They go through the associated ''mangle'' chain > (where tc marks and such are handled), then on to the Filter table INPUT > or FORWARD chain. The *first thing* that happens to them there is > Accounting. *After* that, they may be DROPped or REJECTed but they have > already been counted. > > -TomOkay, I think I understand now. Thanks for putting up with my inane questioning, and thanks also for such an awesome program -- I don''t know where I would be without Shorewall! ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerry® mobile platform with sessions, labs & more. See new tools and technologies. Register for BlackBerry® DevCon today! http://p.sf.net/sfu/rim-devcon-copy1