RC 2 is now available for testing. This version corrects a problem with INLINE handling in the accounting and tcrules files as well as centralizing the validation and registration of nfacct object names. Thank you for testing, -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 \________________________________________________ ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
Tom Eastep wrote:> RC 2 is now available for testing. > > This version corrects a problem with INLINE handling in the accounting > and tcrules files as well as centralizing the validation and > registration of nfacct object names. >I am enclosing another minor (cosmetic) patch - see attached. I also have a question: Lets assume that I have the following: actions ~~~~~~~ FLOG action.FLOG ~~~~~~~~~~~ ?IF $1 ?SET @chain $2 ? $2 : " " ?SET @disposition $3 ? $3 : " " LOG:info(tcp_options,ip_options,macdecode,tcp_sequence,uid) ?END IF ?IF $4 $4 ?END IF rules ~~~~~ SECTION NEW FLOG(log,@chain,ACCEPT,ACCEPT) $FW net:+dmz-net With the above setup, FLOG is not inline and shorewall creates a new chain (called FLOG) and then executes everything there. So far, so good. However, the "@chain" variable, which I passed as a parameter to FLOG is *not*, as I expected, set to "fw2net", but assumes a value of "FLOG" (the chain in which FLOG executes). It is obvious that shorewall does not differentiate between the "@chain" passed as a parameter to a specific action in "rules", "blrules" and the like, and the "@chain" parameter value inside that action. The two are very different. I presume the exact same thing exists with @disposition as well. Is it possible to get shorewall to recognise the "@chain" variable to assume a value of the chain in which the statement occurs ("fw2net" in the above case), instead of assuming the value of the chain in which the actual action executes? I know there are currently 2 workarounds to this: either use an inline "wrapper" action, which calls FLOG, or, hardcode the chain value and then call FLOG (i.e. "FLOG(log,fw2net,ACCEPT,ACCEPT) $FW net"), but I don''t like any of these. ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
On Friday 26 Apr 2013 23:55:56 Tom Eastep wrote:> RC 2 is now available for testing. > > This version corrects a problem with INLINE handling in the accounting > and tcrules files as well as centralizing the validation and > registration of nfacct object names. > > Thank you for testing, > -TomTom I can confirm the issue I raised with RC1 is fixed. Thanks. Steven. ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
Dash Four wrote:> Is it possible to get shorewall to recognise the "@chain" variable to > assume a value of the chain in which the statement occurs ("fw2net" in > the above case), instead of assuming the value of the chain in which > the actual action executes?I just wanted to clarify this further: the @chain variable inside a specific action should be set as the chain in which that action executes. That is what shorewall currently does - no problem there. The "@chain", when specified in "rules", "blrules" etc, should assume the value of the chain in which the statement occurs (i.e. before the action is called) - the two are very different, but what shorewall currently does is treat them the same, which is wrong. ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
On 04/26/2013 06:08 PM, Dash Four wrote:> > > Tom Eastep wrote: >> RC 2 is now available for testing. >> >> This version corrects a problem with INLINE handling in the accounting >> and tcrules files as well as centralizing the validation and >> registration of nfacct object names. >> > I am enclosing another minor (cosmetic) patch - see attached.Thanks. Applied in a slightly-modified form.> I also have a question: > > Lets assume that I have the following: > > actions > ~~~~~~~ > FLOG > > action.FLOG > ~~~~~~~~~~~ > ?IF $1 > ?SET @chain $2 ? $2 : " " > ?SET @disposition $3 ? $3 : " " > LOG:info(tcp_options,ip_options,macdecode,tcp_sequence,uid) > ?END IF > ?IF $4 > $4 > ?END IF > > rules > ~~~~~ > SECTION NEW > FLOG(log,@chain,ACCEPT,ACCEPT) $FW net:+dmz-net > > With the above setup, FLOG is not inline and shorewall creates a new > chain (called FLOG) and then executes everything there. So far, so good. > > However, the "@chain" variable, which I passed as a parameter to FLOG is > *not*, as I expected, set to "fw2net", but assumes a value of "FLOG" > (the chain in which FLOG executes). It is obvious that shorewall does > not differentiate between the "@chain" passed as a parameter to a > specific action in "rules", "blrules" and the like, and the "@chain" > parameter value inside that action. The two are very different. I > presume the exact same thing exists with @disposition as well. > > Is it possible to get shorewall to recognise the "@chain" variable to > assume a value of the chain in which the statement occurs ("fw2net" in > the above case), instead of assuming the value of the chain in which the > actual action executes?It''s not. @chain cannot be expanded by the pre-processor when it appears outside of an action body, so it can only be used in very limited contexts. But I invented a way to accomplish what you want (but I neglected to document it until this morning). There is a variable named @caller which expands to the name of the chain which invoked an action. In an inline action, it expands to the same thing as @chain. In a non-inlined action, it expands to the name of the chain that invoked the action. Please give it a try. -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 \________________________________________________ ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
Tom Eastep wrote:> Thanks. Applied in a slightly-modified form. >No problem.>> I also have a question: >> >> Lets assume that I have the following: >> >> actions >> ~~~~~~~ >> FLOG >> >> action.FLOG >> ~~~~~~~~~~~ >> ?IF $1 >> ?SET @chain $2 ? $2 : " " >> ?SET @disposition $3 ? $3 : " " >> LOG:info(tcp_options,ip_options,macdecode,tcp_sequence,uid) >> ?END IF >> ?IF $4 >> $4 >> ?END IF >> >> rules >> ~~~~~ >> SECTION NEW >> FLOG(log,@chain,ACCEPT,ACCEPT) $FW net:+dmz-net >> >> With the above setup, FLOG is not inline and shorewall creates a new >> chain (called FLOG) and then executes everything there. So far, so good. >> >> However, the "@chain" variable, which I passed as a parameter to FLOG is >> *not*, as I expected, set to "fw2net", but assumes a value of "FLOG" >> (the chain in which FLOG executes). It is obvious that shorewall does >> not differentiate between the "@chain" passed as a parameter to a >> specific action in "rules", "blrules" and the like, and the "@chain" >> parameter value inside that action. The two are very different. I >> presume the exact same thing exists with @disposition as well. >> >> Is it possible to get shorewall to recognise the "@chain" variable to >> assume a value of the chain in which the statement occurs ("fw2net" in >> the above case), instead of assuming the value of the chain in which the >> actual action executes? >> > > It''s not. @chain cannot be expanded by the pre-processor when it appears > outside of an action body, so it can only be used in very limited > contexts. But I invented a way to accomplish what you want (but I > neglected to document it until this morning). > > There is a variable named @caller which expands to the name of the chain > which invoked an action. In an inline action, it expands to the same > thing as @chain. In a non-inlined action, it expands to the name of the > chain that invoked the action. >Given my example above, how would you create the rules statement: "FLOG(log,@caller,ACCEPT,ACCEPT) $FW net:+dmz-net" or just use "@caller" inside the action body, in which case the whole thing becomes: ?IF $1 ?SET @chain $2 ? @caller : " " ?SET @disposition $3 ? $3 : " " LOG:info(tcp_options,ip_options,macdecode,tcp_sequence,uid) ?END IF ?IF $4 $4 ?END IF and then call it with "FLOG(log,caller,ACCEPT,ACCEPT) $FW net:+dmz-net" I also vaguely remember that you had a $0 parameter, which also expanded to the chain name, though I am not sure whether they were exact equivalents (@chain and $0, that is). Is all this documented anywhere - I looked through the "Actions" web page on your site, but could not find anything relevant.> Please give it a try. >Is this in RC2 already? ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
Dash Four wrote:> ?SET @chain $2 ? @caller : " "Or maybe this: ?SET @chain $2 ? (($2 == ''caller'') ? @caller : $2) : " " So that I keep the ability to set the chain to what I want to (different from "@caller")? ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
On Fri, 26 Apr 2013 15:55:56 -0700 Tom Eastep <teastep@shorewall.net> wrote:> RC 2 is now available for testing.No regressions found. -- Tuomo Soini <tis@foobar.fi> Foobar Linux services +358 40 5240030 Foobar Oy <http://foobar.fi/> ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
On 4/28/13 10:02 PM, "Tuomo Soini" <tis@foobar.fi> wrote:>On Fri, 26 Apr 2013 15:55:56 -0700 >Tom Eastep <teastep@shorewall.net> wrote: > >> RC 2 is now available for testing. > >No regressions found.Thanks Tuomo, -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
On 4/27/13 8:07 AM, "Dash Four" <mr.dash.four@googlemail.com> wrote:> > >Dash Four wrote: >> ?SET @chain $2 ? @caller : " " >Or maybe this: > >?SET @chain $2 ? (($2 == ''caller'') ? @caller : $2) : " " > >So that I keep the ability to set the chain to what I want to (different >from "@caller")?This is the correct approach. @caller has been supported since Shorewall 4.5.13. Action variables and Shorewall variables are documented at http://www.shorewall.net/configuration_file_basics.htm#ActionVariables (and in the following section). -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
Tom Eastep wrote:>> Or maybe this: >> >> ?SET @chain $2 ? (($2 == ''caller'') ? @caller : $2) : " " >> >> So that I keep the ability to set the chain to what I want to (different >> from "@caller")? >> > > This is the correct approach. @caller has been supported since Shorewall > 4.5.13. > > Action variables and Shorewall variables are documented at > http://www.shorewall.net/configuration_file_basics.htm#ActionVariables > (and in the following section). >Yeah, I successfully implemented that over the weekend, thanks Tom. I have a few more queries though (in addition to the "providers->track option question" I posted on shorewall-users): 1. man shorewall-rtrules->PRIORITY: The explanation of this column makes a reference to "ISP interface rules" in the context of priority numbers 26000-26999: "...After ISP interface rules but before ''default'' rule". What is that, exactly? Could you clarify this definition please? Is this the ''main'' routing table? 2. The same man page->SOURCE: "Beginning with Shorewall 4.5.0, you may specify &interface in this column to indicate that the source is the primary IP address of the named interface". Again, what does that mean? With "&interface", if used, I am "indicating" an interface, not a "primary IP address", so how does that work then? 3. How do I add a "default" route in "routes"? 4. Similar to 3 above: how do I add, say "10.1.7.0/24 dev eth0 proto kernel scope link src 10.1.7.7 table dmz7" in routes (needed when a device is brought up, but that route is normally placed in ''main'' by the OS)? The reason I ask this is because I have a rule based on this interface source address (i.e. "ip rule add from 10.1.7.7 table dmz7") so I need to have this rule in my dmz7 table, not ''main''. ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
On 04/29/2013 09:26 AM, Dash Four wrote:> > Tom Eastep wrote: >>> Or maybe this: >>> >>> ?SET @chain $2 ? (($2 == ''caller'') ? @caller : $2) : " " >>> >>> So that I keep the ability to set the chain to what I want to (different >>> from "@caller")? >>> >> >> This is the correct approach. @caller has been supported since Shorewall >> 4.5.13. >> >> Action variables and Shorewall variables are documented at >> http://www.shorewall.net/configuration_file_basics.htm#ActionVariables >> (and in the following section). >> > Yeah, I successfully implemented that over the weekend, thanks Tom. I > have a few more queries though (in addition to the "providers->track > option question" I posted on shorewall-users): > > 1. man shorewall-rtrules->PRIORITY: The explanation of this column makes > a reference to "ISP interface rules" in the context of priority numbers > 26000-26999: "...After ISP interface rules but before ''default'' rule". > What is that, exactly? Could you clarify this definition please? Is this > the ''main'' routing table?I should reword that. ''ISP interface rules'' are generated when ''loose'' is not specified. Those rules cause traffic originating on the firewall to be routed to providers based on the source address. In other words, if the packet''s SOURCE address is associated with a provider interface, then the packet should be routed out of that interface.> 2. The same man page->SOURCE: "Beginning with Shorewall 4.5.0, you may > specify &interface in this column to indicate that the source is the > primary IP address of the named interface". Again, what does that mean? > With "&interface", if used, I am "indicating" an interface, not a > "primary IP address", so how does that work then?See http://www.shorewall.net/configuration_file_basics.htm#AddressVariables.> 3. How do I add a "default" route in "routes"?You don''t -- Shorewall generates the default routes based on the provider GATEWAY (specified or detected).> 4. Similar to 3 above: how do I add, say "10.1.7.0/24 dev eth0 proto > kernel scope link src 10.1.7.7 table dmz7" in routes (needed when a > device is brought up, but that route is normally placed in ''main'' by the > OS)? The reason I ask this is because I have a rule based on this > interface source address (i.e. "ip rule add from 10.1.7.7 table dmz7") > so I need to have this rule in my dmz7 table, not ''main''.#PROVIDER DEST GATEWAY DEVICE dmz7 10.1.7.0/24 - eth0 Shorewall will choose the primary IP address of eth0 as the route source. It shouldn''t be difficult to add a SOURCE column if that is needed, but I won''t do that until 4.5.17. -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 \________________________________________________ ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
Tom Eastep wrote:>> 1. man shorewall-rtrules->PRIORITY: The explanation of this column makes >> a reference to "ISP interface rules" in the context of priority numbers >> 26000-26999: "...After ISP interface rules but before ''default'' rule". >> What is that, exactly? Could you clarify this definition please? Is this >> the ''main'' routing table? >> > > I should reword that. ''ISP interface rules'' are generated when ''loose'' > is not specified. Those rules cause traffic originating on the firewall > to be routed to providers based on the source address. In other words, > if the packet''s SOURCE address is associated with a provider interface, > then the packet should be routed out of that interface. >OK, so I''ve got that right then, since I started my rules using numbers 26000+, though I have a few rules based on destination addresses - they start first though, followed up by my "general" rules based on the eth0 primary address (didn''t know that I could use "&interface" instead), as well as a separate rule involving the interface name (i.e. ip rule add oif eth0) and that is pretty much it.>> 2. The same man page->SOURCE: "Beginning with Shorewall 4.5.0, you may >> specify &interface in this column to indicate that the source is the >> primary IP address of the named interface". Again, what does that mean? >> With "&interface", if used, I am "indicating" an interface, not a >> "primary IP address", so how does that work then? >> > > See http://www.shorewall.net/configuration_file_basics.htm#AddressVariables. >Nice, thanks - never knew that before and used a separate "params" variable for this.>> 3. How do I add a "default" route in "routes"? >> > > You don''t -- Shorewall generates the default routes based on the > provider GATEWAY (specified or detected). >Got it now, thanks.>> 4. Similar to 3 above: how do I add, say "10.1.7.0/24 dev eth0 proto >> kernel scope link src 10.1.7.7 table dmz7" in routes (needed when a >> device is brought up, but that route is normally placed in ''main'' by the >> OS)? The reason I ask this is because I have a rule based on this >> interface source address (i.e. "ip rule add from 10.1.7.7 table dmz7") >> so I need to have this rule in my dmz7 table, not ''main''. >> > > #PROVIDER DEST GATEWAY DEVICE > dmz7 10.1.7.0/24 - eth0 > > Shorewall will choose the primary IP address of eth0 as the route > source. It shouldn''t be difficult to add a SOURCE column if that is > needed, but I won''t do that until 4.5.17. >I already tried that - the above translates to "10.1.7.0/24 dev eth0 scope link table dmz7" so I am not sure it is the same (if it doesn''t make any difference - all''s well!). As an aside: If/When the device goes down (eth0 in my case) are all of these routes restored (by shorewall-init?) when that device is brought up again? ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
Dash Four wrote:>>> 3. How do I add a "default" route in "routes"? >>> >> >> You don''t -- Shorewall generates the default routes based on the >> provider GATEWAY (specified or detected). >> > Got it now, thanks.One further clarification on this: I need to have 2 "default" routes (going via the same interface - eth0) - one in ''main'' and one in my ''provider'' table (dmz7). If I have, say, "dmz7 2 - main eth0 10.1.7.1 - none" would that do it or do I need to have something else in addition? Also, does shorewall wipe out existing routes when starting or are these left intact? Same question for shorewall-init (when the interface is brought back up). ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
On 04/29/2013 10:36 AM, Dash Four wrote:> > Dash Four wrote: >>>> 3. How do I add a "default" route in "routes"? >>>> >>> >>> You don''t -- Shorewall generates the default routes based on the >>> provider GATEWAY (specified or detected). >>> >> Got it now, thanks. > One further clarification on this: I need to have 2 "default" routes > (going via the same interface - eth0) - one in ''main'' and one in my > ''provider'' table (dmz7). If I have, say, "dmz7 2 - main eth0 10.1.7.1 - > none" would that do it or do I need to have something else in addition?Use the ''balance'' option on eth0 in /etc/shorewall/providers.> > Also, does shorewall wipe out existing routes when starting or are these > left intact? Same question for shorewall-init (when the interface is > brought back up).It wipes out the provider tables only during ''start''. -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 \________________________________________________ ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
Tom Eastep wrote:> On 04/29/2013 10:36 AM, Dash Four wrote: > >> Dash Four wrote: >> >>>>> 3. How do I add a "default" route in "routes"? >>>>> >>>>> >>>> You don''t -- Shorewall generates the default routes based on the >>>> provider GATEWAY (specified or detected). >>>> >>>> >>> Got it now, thanks. >>> >> One further clarification on this: I need to have 2 "default" routes >> (going via the same interface - eth0) - one in ''main'' and one in my >> ''provider'' table (dmz7). If I have, say, "dmz7 2 - main eth0 10.1.7.1 - >> none" would that do it or do I need to have something else in addition? >> > > Use the ''balance'' option on eth0 in /etc/shorewall/providers. >Nope. It turns out, that route "automagically" appears in both tables. I''ve looked at the generated firewall file and could not find any references to such statement, so it must be, somehow, added by the OS - I have no other explanation.>> Also, does shorewall wipe out existing routes when starting or are these >> left intact? Same question for shorewall-init (when the interface is >> brought back up). >> > > It wipes out the provider tables only during ''start''. >I am about to test this more thoroughly tomorrow. In the meantime, a couple of new (and quite annoying) bugs: 1. When I register a provider, like: providers ~~~~~~~~~ dmz7 2 - main eth0 10.1.7.1 - none and then rtrules ~~~~~~~ 10.1.7.7 - dmz7 26000 eth0 - dmz7 26001 In addition to the expected rules, I also get this little gem generated: find_interface_addresses eth0 | while read address; do qt $IP -4 rule del from $address run_ip rule add from $address pref 20000 table dmz7 echo "$IP -4 rule del from $address > /dev/null 2>&1" >> ${VARDIR}/undo_dmz7_routing rulenum=$(($rulenum + 1)) done Why? I haven''t specified, nor asked shorewall to assume my source address and generate this (I specified what I need to be created - see the 1st statement in rtrules above). 2. "iif" instead of "oif": rtrules ~~~~~~~ eth0 - dmz7 26001 generates: qt $IP -4 rule del iif eth0 to 0.0.0.0/0 priority 26001 run_ip rule add iif eth0 to 0.0.0.0/0 priority 26001 table dmz7 echo "$IP -4 rule del iif eth0 to 0.0.0.0/0 priority 26001 > /dev/null 2>&1" >> ${VARDIR}/undo_dmz7_routing which is wrong - "iif" should be "oif". 3. Specifying "blackhole" routes for a provider, as well as ''main'' generates an error: routes ~~~~~~ dmz7 62.252.0.0/14 blackhole main 62.252.0.0/14 blackhole during either cold start, or a reload, I get the following error: shorewall[7294]: Adding Providers... shorewall[7294]: RTNETLINK answers: File exists shorewall[7294]: ERROR: Command "ip -4 route add blackhole 62.252.0.0/14 table dmz7" Failed root: ERROR:Shorewall start failed This error is mystifying me, because in the generated .start file, there is only one reference to 62.252.0.0/14 so I have absolutely no idea why ip is moaning at me. When I execute this command from the shell, all is well - no problem! ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1
Dash Four wrote:> 3. Specifying "blackhole" routes for a provider, as well as ''main'' > generates an error: > > routes > ~~~~~~ > dmz7 62.252.0.0/14 blackhole > main 62.252.0.0/14 blackhole > > during either cold start, or a reload, I get the following error: > > shorewall[7294]: Adding Providers... > shorewall[7294]: RTNETLINK answers: File exists > shorewall[7294]: ERROR: Command "ip -4 route add blackhole > 62.252.0.0/14 table dmz7" Failed > root: ERROR:Shorewall start failed > > This error is mystifying me, because in the generated .start file, > there is only one reference to 62.252.0.0/14 so I have absolutely no > idea why ip is moaning at me. When I execute this command from the > shell, all is well - no problem!I think I found what is causing this - in the generated firewall file, I have: $IP -4 -o route show table main | while read net route; do case $net in default) ;; blackhole|prohibit|unreachable) run_ip route add table dmz7 $net $route ;; *) case $(find_device $route) in eth0) case $net in 255.255.255.255*) ;; *) run_ip route add table dmz7 $net $route ;; esac ;; esac ;; esac done The above may explain why adding the blackhole route fails, even though I have "none" in the COPY column in "providers". It also explains why the "src" link route is also copied over to the provider table. If the above is indeed the cause for this error, then perhaps you could add another set of options called "blackhole", "prohibit" and "unreachable" to the COPY column so that these routes are copied over - when "none" is specified, shorewall should, by definition, copy only the routes with regards to the interface specified (personally, I am against that as well - I think that "none" should really mean nothing is copied over, but this might break backwards compatibility). I also think that there should be an option for nothing at all to be copied over - currently I don''t see a way to do this. ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1
On 04/29/2013 07:49 PM, Dash Four wrote:> > > Dash Four wrote: >> 3. Specifying "blackhole" routes for a provider, as well as ''main'' >> generates an error: >> >> routes >> ~~~~~~ >> dmz7 62.252.0.0/14 blackhole >> main 62.252.0.0/14 blackhole >> >> during either cold start, or a reload, I get the following error: >> >> shorewall[7294]: Adding Providers... >> shorewall[7294]: RTNETLINK answers: File exists >> shorewall[7294]: ERROR: Command "ip -4 route add blackhole >> 62.252.0.0/14 table dmz7" Failed >> root: ERROR:Shorewall start failed >> >> This error is mystifying me, because in the generated .start file, >> there is only one reference to 62.252.0.0/14 so I have absolutely no >> idea why ip is moaning at me. When I execute this command from the >> shell, all is well - no problem! > I think I found what is causing this - in the generated firewall file, I > have: > > $IP -4 -o route show table main | while read net route; do > case $net in > default) > ;; > blackhole|prohibit|unreachable) > run_ip route add table dmz7 $net $route > ;; > *) > case $(find_device $route) in > eth0) > case $net in > 255.255.255.255*) > ;; > *) > run_ip route add table dmz7 $net $route > ;; > esac > ;; > esac > ;; > esac > done > > The above may explain why adding the blackhole route fails, even though > I have "none" in the COPY column in "providers". It also explains why > the "src" link route is also copied over to the provider table.That was added at your request -- you wanted the blackhole routes to appear in your provider tables. But I don''t understand why it isn''t working in your case.> > If the above is indeed the cause for this error, then perhaps you could > add another set of options called "blackhole", "prohibit" and > "unreachable" to the COPY column so that these routes are copied over - > when "none" is specified, shorewall should, by definition, copy only the > routes with regards to the interface specified (personally, I am against > that as well - I think that "none" should really mean nothing is copied > over, but this might break backwards compatibility). I also think that > there should be an option for nothing at all to be copied over - > currently I don''t see a way to do this.Leave the DUPLICATE column empty. -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 \________________________________________________ ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1
Tom Eastep wrote:> On 04/29/2013 07:49 PM, Dash Four wrote: > >> Dash Four wrote: >> >>> 3. Specifying "blackhole" routes for a provider, as well as ''main'' >>> generates an error: >>> >>> routes >>> ~~~~~~ >>> dmz7 62.252.0.0/14 blackhole >>> main 62.252.0.0/14 blackhole >>> >>> during either cold start, or a reload, I get the following error: >>> >>> shorewall[7294]: Adding Providers... >>> shorewall[7294]: RTNETLINK answers: File exists >>> shorewall[7294]: ERROR: Command "ip -4 route add blackhole >>> 62.252.0.0/14 table dmz7" Failed >>> root: ERROR:Shorewall start failed >>> >>> This error is mystifying me, because in the generated .start file, >>> there is only one reference to 62.252.0.0/14 so I have absolutely no >>> idea why ip is moaning at me. When I execute this command from the >>> shell, all is well - no problem! >>> >> I think I found what is causing this - in the generated firewall file, I >> have: >> >> $IP -4 -o route show table main | while read net route; do >> case $net in >> default) >> ;; >> blackhole|prohibit|unreachable) >> run_ip route add table dmz7 $net $route >> ;; >> *) >> case $(find_device $route) in >> eth0) >> case $net in >> 255.255.255.255*) >> ;; >> *) >> run_ip route add table dmz7 $net $route >> ;; >> esac >> ;; >> esac >> ;; >> esac >> done >> >> The above may explain why adding the blackhole route fails, even though >> I have "none" in the COPY column in "providers". It also explains why >> the "src" link route is also copied over to the provider table. >> > > That was added at your request -- you wanted the blackhole routes to > appear in your provider tables. But I don''t understand why it isn''t > working in your case. >Indeed it was, but, as I recall, this was done just before you introduced the blackhole-type route definitions in "routes". The problem is caused by the "blackhole|prohibit|unreachable" case branch I quoted above. When I define a blackhole routes in ''main'', as well as in the provider table using "routes", shorewall starts creating these as defined and then attempts to copy the blackhole routes over to my provider''s table, but since they already exist, that is why ip starts moaning (and rightly so) as the routes already exist. In my view, the appropriate course of action would be one of: 1. Take the "blackhole|prohibit|unreachable" case branch off completely and leave defining such routes up to the user (at the end of the day, this is what "routes" is for, right?); or 2. Modify that case branch slightly to be dependent on a (newly-defined) separate option for the "COPY" column (I already suggested "blackhole", "prohibit" or "unreachable") which copies, selectively, the desired routes across. In other words, if I have "blackhole" in COPY, then shorewall should copy the blackhole routes over from the table indicated in the DUPLICATE column to the provider table; or 3. Leave everything as is and let the user deal with the mess themselves. My personal preference is for option 2 above as it gives me a close control of everything, but I wouldn''t mind if both options 1 and 2 are implemented.>> If the above is indeed the cause for this error, then perhaps you could >> add another set of options called "blackhole", "prohibit" and >> "unreachable" to the COPY column so that these routes are copied over - >> when "none" is specified, shorewall should, by definition, copy only the >> routes with regards to the interface specified (personally, I am against >> that as well - I think that "none" should really mean nothing is copied >> over, but this might break backwards compatibility). I also think that >> there should be an option for nothing at all to be copied over - >> currently I don''t see a way to do this. >> > > Leave the DUPLICATE column empty. >I did consider this (although I did not try it), but the man page says to leave it empty if my USE_DEFAULT_RT=Yes: ''This column should contain a dash ("-'') when USE_DEFAULT_RT=Yes''. As you know, I have USE_DEFAULT_RT=No, so I wasn''t sure whether to use a dash or not. Maybe an update in the description of this column is in order. ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1