Tom The following bug is back: Both shorewall rules: DNAT wan lan tcp 80 DNAT wan lan:0.0.0.0/0 tcp 80 Generate the following iptables rule: -A wan_dnat -p 6 --dport 80 -j DNAT --to-destination 0.0.0.0/0 Which produces the following error message: iptables-restore v1.4.17: Bad IP address "0.0.0.0/0" Similarly with Shorewall6 rule: DNAT wan lan tcp 80 Generates ip6tables rule: -A PREROUTING -p 6 --dport 80 -i eth1 -j DNAT --to-destination [::/0] Which produces error message: ip6tables-restore v1.4.17: Bad IP address "::/0" Steven. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb
On 3/3/13 8:09 AM, "Steven Jan Springl" <steven@springl.ukfsn.org> wrote:>Tom > >The following bug is back: > >Both shorewall rules: > >DNAT wan lan tcp 80 > >DNAT wan lan:0.0.0.0/0 tcp 80 > >Generate the following iptables rule: > >-A wan_dnat -p 6 --dport 80 -j DNAT --to-destination 0.0.0.0/0 > >Which produces the following error message: > >iptables-restore v1.4.17: Bad IP address "0.0.0.0/0" > >Similarly with Shorewall6 rule: > >DNAT wan lan tcp 80 > >Generates ip6tables rule: > >-A PREROUTING -p 6 --dport 80 -i eth1 -j DNAT --to-destination [::/0] > >Which produces error message: > >ip6tables-restore v1.4.17: Bad IP address "::/0"Steven, You need to re-apply the patches. Those went in after I had already uploaded RC1. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb
> You need to re-apply the patches. Those went in after I had already > uploaded RC1. >The RC1 announcement wasn''t posted on the list either. I don''t know whether it is late in the cycle for this release or not, but the following problem, I think, merits some attention: 1. "providers" file and treatment of (custom-specified) blackhole rules: They are not captured either by the DUPLICATE or COPY columns, so they must always be copied (somehow manually?) regardless. Currently I can''t see a way of adding blackhole routes (there isn''t anything in either "rtrules" or "routes"), which means that if I have a custom-set blackhole routes (via the Linux network scripts or via "start"/"started"), they will not be copied over to the providers table(s) and there is no way to add them in either of these two files. Also worth reporting: 2. "firewall" script - ${VARDIR}/<iface>.status optimisation: providers ~~~~~~~~~ internal 7 - - eth2 10.1.7.13 produces: [...] find_interface_addresses eth2 | while read address; do qt $IP -4 rule del from $address run_ip rule add from $address pref 20000 table 7 echo "qt $IP -4 rule del from $address" >> ${VARDIR}/undo_internal_routing rulenum=$(($rulenum + 1)) done echo 0 > ${VARDIR}/eth2.status echo 0 > ${VARDIR}/eth2.status progress_message "Provider internal (2) Started" else echo 1 > ${VARDIR}/eth2.status fatal_error "Interface eth2 is not usable -- Provider internal (2) Cannot be Started" fi } # End of start_provider_internal(); [...] Note the double "echo 0 > ..." statement above. 3. The definition of DUPLICATE and COPY columns in "providers" is different in http://www.shorewall.net/MultiISP.html and http://www.shorewall.net/manpages/shorewall-providers.html. In MultiISP.html we have: "...When you specify an existing table in the DUPLICATE column, Shorewall copies all routes through the interface specified in the INTERFACE column plus the interfaces listed in this column. Normally, you will list all interfaces on your firewall in this column except those Internet interfaces specified in the INTERFACE column of entries in this file." So, according to this, if I have the above "providers" configuration (see 2 above), save for setting "main" in the DUPLICATE column, then only routes defined in the main table for "eth2" should be copied to the "internal" table. In reality, every subnet defined in the main table, regardless of which interface it is defined for, is copied. The providers man page describes the correct behaviour. In addition, if I specify "eth2" in the COPY column (continue to have "main" in DUPLICATE), then the following code is produced: [...] case $(find_device $route) in eth2|eth2) case $net in 255.255.255.255*) [...] "eth2|eth2)" is the equivalent of "eth2)", so this should be optimised. 4. Manpages -> rtrules is a dead link. ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev
On 03/06/2013 04:21 AM, Mr Dash Four wrote:> >> You need to re-apply the patches. Those went in after I had already >> uploaded RC1. >> > The RC1 announcement wasn''t posted on the list either.> I don''t know whether it is late in the cycle for this release or not, but the > following problem, I think, merits some attention: > > 1. "providers" file and treatment of (custom-specified) blackhole rules: > > They are not captured either by the DUPLICATE or COPY columns, so they > must always be copied (somehow manually?) regardless. > > Currently I can''t see a way of adding blackhole routes (there isn''t > anything in either "rtrules" or "routes"), which means that if I have a > custom-set blackhole routes (via the Linux network scripts or via > "start"/"started"), they will not be copied over to the providers > table(s) and there is no way to add them in either of these two files.I highly recommend USE_DEFAULT_RT=Yes. This causes the main routing table to be traversed prior to the provider tables and avoids all of the copying nonsense altogether. I really don''t want to put any effort into improving USE_DEFAULT_RT=No.> > Also worth reporting: > > 2. "firewall" script - ${VARDIR}/<iface>.status optimisation: > > providers > ~~~~~~~~~ > internal 7 - - eth2 10.1.7.13 > > produces: > > [...] > find_interface_addresses eth2 | while read address; do > qt $IP -4 rule del from $address > run_ip rule add from $address pref 20000 table 7 > echo "qt $IP -4 rule del from $address" >> > ${VARDIR}/undo_internal_routing > rulenum=$(($rulenum + 1)) > done > > echo 0 > ${VARDIR}/eth2.status > echo 0 > ${VARDIR}/eth2.status > progress_message "Provider internal (2) Started" > else > echo 1 > ${VARDIR}/eth2.status > fatal_error "Interface eth2 is not usable -- Provider internal > (2) Cannot be Started" > fi > } # End of start_provider_internal(); > [...] > > Note the double "echo 0 > ..." statement above.Patch attached.> > 3. The definition of DUPLICATE and COPY columns in "providers" is > different in http://www.shorewall.net/MultiISP.html and > http://www.shorewall.net/manpages/shorewall-providers.html. In > MultiISP.html we have: > > "...When you specify an existing table in the DUPLICATE column, > Shorewall copies all routes through the interface specified in the > INTERFACE column plus the interfaces listed in this column. Normally, > you will list all interfaces on your firewall in this column except > those Internet interfaces specified in the INTERFACE column of entries > in this file." > > So, according to this, if I have the above "providers" configuration > (see 2 above), save for setting "main" in the DUPLICATE column, then > only routes defined in the main table for "eth2" should be copied to the > "internal" table. In reality, every subnet defined in the main table, > regardless of which interface it is defined for, is copied. The > providers man page describes the correct behaviour.Thanks -- I''ll update the web page.> > In addition, if I specify "eth2" in the COPY column (continue to have > "main" in DUPLICATE), then the following code is produced: > > [...] > case $(find_device $route) in > eth2|eth2) > case $net in > 255.255.255.255*) > [...] > "eth2|eth2)" is the equivalent of "eth2)", so this should be optimisedPatch attached.> > 4. Manpages -> rtrules is a dead link.Corrected - thanks. -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 \________________________________________________ ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev
>> Currently I can''t see a way of adding blackhole routes (there isn''t >> anything in either "rtrules" or "routes"), which means that if I have a >> custom-set blackhole routes (via the Linux network scripts or via >> "start"/"started"), they will not be copied over to the providers >> table(s) and there is no way to add them in either of these two files. >> > > I highly recommend USE_DEFAULT_RT=Yes. This causes the main routing > table to be traversed prior to the provider tables and avoids all of the > copying nonsense altogether.No, that is not an option for me and is precisely why I had to use "providers", though, unaware of the fact that blackhole routes can''t be/won''t be copied over. Besides, I have routes in my "providers" file, which "puncture" holes in the routes defined as blackhole, so even if I follow your advice above, that won''t work - I need to copy the blackhole routes concerned, as well as those routes I am using in my "providers" file, together as a package, otherwise the whole thing won''t work. Currently, with a bit of hacking and by defining things in "start", "started" and also using "postcompile" I can survive (for now!), but that isn''t a solution.> I really don''t want to put any effort into improving USE_DEFAULT_RT=No. >At the end of the day, it is your call - I am just highlighting an issue. Whether you decide to address it or not is up to you, not me.>> Note the double "echo 0 > ..." statement above. >> > > Patch attached. >I''ll have a chance to test this tonight...>> "eth2|eth2)" is the equivalent of "eth2)", so this should be optimised >> > > Patch attached. >... and that one too. Thanks. ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev
On 03/06/2013 09:13 AM, Mr Dash Four wrote:> >>> Currently I can''t see a way of adding blackhole routes (there isn''t >>> anything in either "rtrules" or "routes"), which means that if I have a >>> custom-set blackhole routes (via the Linux network scripts or via >>> "start"/"started"), they will not be copied over to the providers >>> table(s) and there is no way to add them in either of these two files. >>> >> >> I highly recommend USE_DEFAULT_RT=Yes. This causes the main routing >> table to be traversed prior to the provider tables and avoids all of the >> copying nonsense altogether. > No, that is not an option for me and is precisely why I had to use > "providers", though, unaware of the fact that blackhole routes can''t > be/won''t be copied over. > > Besides, I have routes in my "providers" file, which "puncture" holes in > the routes defined as blackhole, so even if I follow your advice above, > that won''t work - I need to copy the blackhole routes concerned, as well > as those routes I am using in my "providers" file, together as a > package, otherwise the whole thing won''t work. > > Currently, with a bit of hacking and by defining things in "start", > "started" and also using "postcompile" I can survive (for now!), but > that isn''t a solution. > >> I really don''t want to put any effort into improving USE_DEFAULT_RT=No. >> > At the end of the day, it is your call - I am just highlighting an > issue. Whether you decide to address it or not is up to you, not me.Please try the attached patch. I believe that it is creating the correct shell code but I don''t have a convenient way to test it. Thanks, -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 \________________________________________________ ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev
On 03/06/2013 10:53 AM, Tom Eastep wrote:> On 03/06/2013 09:13 AM, Mr Dash Four wrote: >> >>>> Currently I can''t see a way of adding blackhole routes (there isn''t >>>> anything in either "rtrules" or "routes"), which means that if I have a >>>> custom-set blackhole routes (via the Linux network scripts or via >>>> "start"/"started"), they will not be copied over to the providers >>>> table(s) and there is no way to add them in either of these two files. >>>> >>> >>> I highly recommend USE_DEFAULT_RT=Yes. This causes the main routing >>> table to be traversed prior to the provider tables and avoids all of the >>> copying nonsense altogether. >> No, that is not an option for me and is precisely why I had to use >> "providers", though, unaware of the fact that blackhole routes can''t >> be/won''t be copied over. >> >> Besides, I have routes in my "providers" file, which "puncture" holes in >> the routes defined as blackhole, so even if I follow your advice above, >> that won''t work - I need to copy the blackhole routes concerned, as well >> as those routes I am using in my "providers" file, together as a >> package, otherwise the whole thing won''t work. >> >> Currently, with a bit of hacking and by defining things in "start", >> "started" and also using "postcompile" I can survive (for now!), but >> that isn''t a solution. >> >>> I really don''t want to put any effort into improving USE_DEFAULT_RT=No. >>> >> At the end of the day, it is your call - I am just highlighting an >> issue. Whether you decide to address it or not is up to you, not me. > > Please try the attached patch. I believe that it is creating the correct > shell code but I don''t have a convenient way to test it.And here''s one that allows adding blackhole routes via /etc/shorewall/routes. Just specify ''blackhole'' in the GATEWAY column and leave the DEVICE column empty. If the copy patch works okay, I''ll include it in 4.5.14. The attached one will not be released until 4.5.15 Beta 1. -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 \________________________________________________ ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev
>> Note the double "echo 0 > ..." statement above. >> > > Patch attached. >That now works as expected...>> "eth2|eth2)" is the equivalent of "eth2)", so this should be optimised >> > > Patch attached. >... and so is this, though I see that I am able to add any (non-existing/fictitious) interface in the COPY column and shorewall takes it without much fuss. Should that be allowed? ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev
> Please try the attached patch. I believe that it is creating the correct > shell code but I don''t have a convenient way to test it. >Nope, the BLACKHOLE.patch which was attached to this isn''t doing anything to the table I defined in providers. The pre-defined routes for the interface used in "providers" are copied over, but nothing else. My "providers" file (for testing this) is very simple: tbl 2 - main eth0 <gw_address> - none ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev
> And here''s one that allows adding blackhole routes via > /etc/shorewall/routes. Just specify ''blackhole'' in the GATEWAY column > and leave the DEVICE column empty. >That does it, though I have a couple of recommendations: I am a bit confused as to the functions of "routes" and "rtroutes" - it seems to me that most, if not all, of the functionality can be implemented by using just one file ("rtroutes" seems to have more options, though with "routes", it looks as though things are more straight-forward there). I think it is a good idea to be able to define blackhole routes for the "main" table (in other words, the default "provider") by using "routes" (haven''t tried that though!). In such scenarios, this should, in theory, supersede the NULL_ROUTE_RFC1918 config option and gives me more flexibility on what should be defined as a "blackhole" route. Why? Because on one of my machines (an embedded device which is *very* constrained, resource-wise) the main interface often goes up and down and in such cases, the routes I have defined there simply "disappear" as soon as the device goes down, which means that I cannot connect to it from the internal network simply because the blackhole routes are not tied up to a specific interface and stay "on" regardless of the state of any network device. In such case, I have to fiddle with my "postcompile" to remove the 10.0.0.0/8 blackhole route which is defined/included in the "firewall" script as soon as I turn that NULL_ROUTE_RFC1918 config option on. If I have more fine-grained control of the blackhole routes - either via "rtroutes" or "routes" (again, I am a bit mystified as to what is the difference between the two), that won''t be a problem for me because I''ll just disable NULL_ROUTE_RFC1918 and define my own blackhole routes the way I want it without much fuss.> If the copy patch works okay, I''ll include it in 4.5.14. The attached > one will not be released until 4.5.15 Beta 1. >That''s fair enough, though the patch looks pretty good to me and does its job. ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev
On 3/6/13 5:24 PM, "Mr Dash Four" <mr.dash.four@googlemail.com> wrote:> >>> Note the double "echo 0 > ..." statement above. >>> >> >> Patch attached. >> >That now works as expected... > >>> "eth2|eth2)" is the equivalent of "eth2)", so this should be optimised >>> >> >> Patch attached. >> >... and so is this, though I see that I am able to add any >(non-existing/fictitious) interface in the COPY column and shorewall >takes it without much fuss. Should that be allowed?Yep -- it isn''t working here either. About my bedtime so I''ll look at it again in the morning. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev
On 3/6/13 5:24 PM, "Mr Dash Four" <mr.dash.four@googlemail.com> wrote:> >> Please try the attached patch. I believe that it is creating the correct >> shell code but I don''t have a convenient way to test it. >> >Nope, the BLACKHOLE.patch which was attached to this isn''t doing >anything to the table I defined in providers. The pre-defined routes for >the interface used in "providers" are copied over, but nothing else. My >"providers" file (for testing this) is very simple: > >tbl 2 - main eth0 <gw_address> - noneThe attached patch on top of BLACKHOLE.patch works for me. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev
On 03/06/2013 05:24 PM, Mr Dash Four wrote:> >>> Note the double "echo 0 > ..." statement above. >>> >> >> Patch attached. >> > That now works as expected... > >>> "eth2|eth2)" is the equivalent of "eth2)", so this should be optimised >>> >> >> Patch attached. >> > ... and so is this, though I see that I am able to add any > (non-existing/fictitious) interface in the COPY column and shorewall > takes it without much fuss. Should that be allowed?Probably not. Patch attached. -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 \________________________________________________ ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev