Beta 3 is now available for testing.
Changes since Beta 2:
1) The ''replace'' command is now used rather than
''add'' for creating
routes defined in /etc/shorewall[6]/routes.
2) The ${VARDIR}/undo_<provider>_routing scripts no longer invoke
a Shorewall internal function so that they may be processed
directly by a shell.
3) The compiler now detects multiple entries in
/etc/shorewall[6]/routes with the same PROVIDER and DEST and raises
an error. If an entry for the ''main'' table in
/etc/shorewall/routes
has one of the RFC1918 networks as the DEST and if
NULL_ROUTE_RFC1918=Yes, then a warning message is issued and the
entry in /etc/shorewall/routes is used.
4) Prior to now, the generated shell script has always used routing
table (provider) numbers rather than names. To make the script more
readable and to aid in debugging, a new USE_RT_NAMES option has
been added to shorewall[6].conf.
When set to ''Yes'', Shorewall will use routing table
(provider)
names in the generated script rather than table numbers. When set
to ''No'' (the default), routing table numbers will be used.
Caution
If you set USE_RT_NAMES=Yes and KEEP_RT_TABLES=Yes, then you must
insure that all of your providers have entries in
/etc/iproute2/rt_tables as well as the following entries:
255 local
254 main
253 default
250 balance
0 unspec
Without these entries, the firewall will fail to start.
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 \________________________________________________
------------------------------------------------------------------------------
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_mar
> 1) The ''replace'' command is now used rather than ''add'' for creating > routes defined in /etc/shorewall[6]/routes. >See my previous post on my thoughts on this.> 3) The compiler now detects multiple entries in > /etc/shorewall[6]/routes with the same PROVIDER and DEST and raises > an error. If an entry for the ''main'' table in /etc/shorewall/routes > has one of the RFC1918 networks as the DEST and if > NULL_ROUTE_RFC1918=Yes, then a warning message is issued and the > entry in /etc/shorewall/routes is used. >I''ll be able to test this if not tonight, then tomorrow when I get home.> 4) Prior to now, the generated shell script has always used routing > table (provider) numbers rather than names. To make the script more > readable and to aid in debugging, a new USE_RT_NAMES option has > been added to shorewall[6].conf. > > When set to ''Yes'', Shorewall will use routing table (provider) > names in the generated script rather than table numbers. When set > to ''No'' (the default), routing table numbers will be used. >I like that! ------------------------------------------------------------------------------ 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_mar
On 03/24/2013 01:56 PM, Mr Dash Four wrote:> >> 1) The ''replace'' command is now used rather than ''add'' for creating >> routes defined in /etc/shorewall[6]/routes. >> > See my previous post on my thoughts on this.I''ve reverted that change for RC 1.> >> 3) The compiler now detects multiple entries in >> /etc/shorewall[6]/routes with the same PROVIDER and DEST and raises >> an error. If an entry for the ''main'' table in /etc/shorewall/routes >> has one of the RFC1918 networks as the DEST and if >> NULL_ROUTE_RFC1918=Yes, then a warning message is issued and the >> entry in /etc/shorewall/routes is used. >> > I''ll be able to test this if not tonight, then tomorrow when I get home.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 \________________________________________________ ------------------------------------------------------------------------------ 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_mar
> 2) The ${VARDIR}/undo_<provider>_routing scripts no longer invoke > a Shorewall internal function so that they may be processed > directly by a shell. >I''ve just had an idea about this - can you integrate this into some sort of "shorewall <appropriate_undo_routing_command> <provider>" command - it would be easier to do than mess about it scripts (they are useful too though!)?> 3) The compiler now detects multiple entries in > /etc/shorewall[6]/routes with the same PROVIDER and DEST and raises > an error. If an entry for the ''main'' table in /etc/shorewall/routes > has one of the RFC1918 networks as the DEST and if > NULL_ROUTE_RFC1918=Yes, then a warning message is issued and the > entry in /etc/shorewall/routes is used. >I''ll get this a more thorough testing tomorrow as I ran out of time...> 4) Prior to now, the generated shell script has always used routing > table (provider) numbers rather than names. To make the script more > readable and to aid in debugging, a new USE_RT_NAMES option has > been added to shorewall[6].conf. > > When set to ''Yes'', Shorewall will use routing table (provider) > names in the generated script rather than table numbers. When set > to ''No'' (the default), routing table numbers will be used. > > Caution > > If you set USE_RT_NAMES=Yes and KEEP_RT_TABLES=Yes, then you must > insure that all of your providers have entries in > /etc/iproute2/rt_tables as well as the following entries: > > 255 local > 254 main > 253 default > 250 balance > 0 unspec > > Without these entries, the firewall will fail to start. >On a first "pass", I found the following (KEEP_RT_TABLES=No, USE_RT_NAMES=Yes, executing "shorewall compile"): [...] > ${VARDIR}/undo_main_routing run_ip route replace blackhole 10.0.0.0/8 table 254 echo "$IP -4 route del blackhole 10.0.0.0/8 table 254 > /dev/null 2>&1" >> ${VARDIR}/undo_main_routing run_ip route replace blackhole 172.16.0.0/12 table 254 echo "$IP -4 route del blackhole 172.16.0.0/12 table 254 > /dev/null 2>&1" >> ${VARDIR}/undo_main_routing run_ip route replace blackhole 192.168.0.0/16 table 254 echo "$IP -4 route del blackhole 192.168.0.0/16 table 254 > /dev/null 2>&1" >> ${VARDIR}/undo_main_routing > ${VARDIR}/undo_default_routing start_provider_dmz [...] # # And delete any routes in the ''balance'' table # qt $IP -4 route del default table 250 [...] start_provider_dmz() { qt ip -4 route flush table 2 [...] run_ip route add table 2 $net $route Notice all numbers in the "table XX" statements above. Again, I''ll give it a more thorough look tomorrow... ------------------------------------------------------------------------------ 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_mar
>> See my previous post on my thoughts on this. >> > > I''ve reverted that change for RC 1. >Thanks! If you send me the appropriate patch(es), I''ll test this tomorrow as well when I get back. ------------------------------------------------------------------------------ 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_mar
On 3/24/13 8:24 PM, "Mr Dash Four" <mr.dash.four@googlemail.com> wrote:> >> 2) The ${VARDIR}/undo_<provider>_routing scripts no longer invoke >> a Shorewall internal function so that they may be processed >> directly by a shell. >> >I''ve just had an idea about this - can you integrate this into some sort >of "shorewall <appropriate_undo_routing_command> <provider>" command - >it would be easier to do than mess about it scripts (they are useful too >though!)?shorewall disable {interface|provider}> >> 3) The compiler now detects multiple entries in >> /etc/shorewall[6]/routes with the same PROVIDER and DEST and raises >> an error. If an entry for the ''main'' table in /etc/shorewall/routes >> has one of the RFC1918 networks as the DEST and if >> NULL_ROUTE_RFC1918=Yes, then a warning message is issued and the >> entry in /etc/shorewall/routes is used. >> >I''ll get this a more thorough testing tomorrow as I ran out of time...Thanks -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_mar
On 03/24/2013 08:25 PM, Mr Dash Four wrote:> >>> See my previous post on my thoughts on this. >>> >> >> I''ve reverted that change for RC 1. >> > Thanks! If you send me the appropriate patch(es), I''ll test this > tomorrow as well when I get back.The patch is at http://sourceforge.net/p/shorewall/code/ci/6e5f00062cc1ef81bcafd9d9704bb0b9a6509475/ Byt it also reverts the updates to the MultiISP documentation. -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 \________________________________________________ ------------------------------------------------------------------------------ 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_mar
On 03/24/2013 08:51 PM, Tom Eastep wrote:> On 03/24/2013 08:25 PM, Mr Dash Four wrote: >> >>>> See my previous post on my thoughts on this. >>>> >>> >>> I''ve reverted that change for RC 1. >>> >> Thanks! If you send me the appropriate patch(es), I''ll test this >> tomorrow as well when I get back. > > The patch is at > http://sourceforge.net/p/shorewall/code/ci/6e5f00062cc1ef81bcafd9d9704bb0b9a6509475/ > > Byt it also reverts the updates to the MultiISP documentation.Here''s the patch extracted from that web page. Also attached is a patch that cleans up a few more cases of table numbers/names and ''route replace''. -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 \________________________________________________ ------------------------------------------------------------------------------ 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_mar
> Here''s the patch extracted from that web page. > > Also attached is a patch that cleans up a few more cases of table > numbers/names and ''route replace''. >Hmm, I found a few annoying bits (following last) and one problem for which I can''t figure out the cause (and I''ve been banging my head for the past hour). Here it is: providers ~~~~~~~ dmz 2 - main eth0 <gw_address> - none This produces, among other things, the following set of statements: start_provider_dmz() { [...] run_ip route replace <gw_address> src $SW_ETH0_ADDRESS dev eth0 run_ip route add <gw_address> src $SW_ETH0_ADDRESS dev eth0 table dmz run_ip route add default via <gw_address> src $SW_ETH0_ADDRESS dev eth0 table dmz Now, during "start" (I tried "reload" first though) I get this message: Mar 26 01:53:59 test1 shorewall[13102]: Adding Providers... Mar 26 01:53:59 test1 shorewall[13102]: RTNETLINK answers: File exists Mar 26 01:53:59 test1 shorewall[13102]: ERROR: Command "ip -4 route add <gw_address> src <eth0_address> dev eth0 table dmz" Failed Mar 26 01:53:59 test1 root: ERROR:Shorewall restart failed I may be mistaken, but from the above 3 statements the last two are identical I think, yet I get the error message from ip about the second, not the 3rd statement. What is more puzzling is that when I attempt to execute that statement from the command line, it succeeds. OK, now for the leftovers...in a few places table numbers are still appearing instead of names: start_provider_dmz() { [...] $IP -4 -o route show table main | while read net route; do case $net in default) ;; blackhole) => run_ip route add table 2 blackhole $route ;; *) case $(find_device $route) in eth0) case $net in 255.255.255.255*) ;; *) => run_ip route add table 2 $net $route ;; esac ;; esac ;; esac done Also, when I have NULL_ROUTE_RFC1918=Yes, I get "run_ip route replace ..." statements. Is that how it is supposed to be (with "replace")? When I have statements of the sort of: routes ~~~~ main 10.0.0.0/8 blackhole main 172.16.0.0/12 blackhole main 192.168.0.0/16 blackhole That seems to be translated to: run_ip route add blackhole 10.0.0.0/8 table 254 echo "$IP -4 route del blackhole 10.0.0.0/8 table 254 > /dev/null 2>&1" >> ${VARDIR}/undo_main_routing run_ip route add blackhole 172.16.0.0/12 table 254 echo "$IP -4 route del blackhole 172.16.0.0/12 table 254 > /dev/null 2>&1" >> ${VARDIR}/undo_main_routing run_ip route add blackhole 192.168.0.0/16 table 254 echo "$IP -4 route del blackhole 192.168.0.0/16 table 254 > /dev/null 2>&1" >> ${VARDIR}/undo_main_routing (note table numbers instead of names). ------------------------------------------------------------------------------ Own the Future-Intel® Level Up Game Demo Contest 2013 Rise to greatness in Intel''s independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
On 03/25/2013 07:41 PM, Mr Dash Four wrote:> >> Here''s the patch extracted from that web page. >> >> Also attached is a patch that cleans up a few more cases of table >> numbers/names and ''route replace''. >> > Hmm, I found a few annoying bits (following last) and one problem for > which I can''t figure out the cause (and I''ve been banging my head for > the past hour). Here it is: > > > providers > ~~~~~~~ > dmz 2 - main eth0 <gw_address> - none > > > This produces, among other things, the following set of statements: > > start_provider_dmz() { > [...] > run_ip route replace <gw_address> src $SW_ETH0_ADDRESS dev eth0 > run_ip route add <gw_address> src $SW_ETH0_ADDRESS dev eth0 > table dmz > run_ip route add default via <gw_address> src $SW_ETH0_ADDRESS > dev eth0 table dmz > > > Now, during "start" (I tried "reload" first though) I get this message: > > Mar 26 01:53:59 test1 shorewall[13102]: Adding Providers... > Mar 26 01:53:59 test1 shorewall[13102]: RTNETLINK answers: File exists > Mar 26 01:53:59 test1 shorewall[13102]: ERROR: Command "ip -4 route > add <gw_address> src <eth0_address> dev eth0 table dmz" Failed > Mar 26 01:53:59 test1 root: ERROR:Shorewall restart failed > > > I may be mistaken, but from the above 3 statements the last two are > identical I think,No. The 2nd adds a host route to the gateway while the 3rd adds a default route via that gateway.> yet I get the error message from ip about the second, not the 3rd > statement. What is more puzzling is that when I attempt to execute > that statement from the command line, it succeeds.The problem here is that you have USE_DEFAULT_RT=No and copy routes from the main table to the provider cable. The main table had that route and it has been copied into the ''dmz'' table. That was a bug in the CLEANUP.patch I sent. The attached DUPLICATE.patch should eliminate the problem.> > > OK, now for the leftovers...in a few places table numbers are still > appearing instead of names: > > start_provider_dmz() { > [...] > $IP -4 -o route show table main | while read net route; do > case $net in > default) > ;; > blackhole) > => run_ip route add table 2 blackhole $route > ;; > *) > case $(find_device $route) in > eth0) > case $net in > 255.255.255.255*) > ;; > *) > => run_ip route add table 2 $net $route > ;; > esac > ;; > esac > ;; > esac > done > > Also, when I have NULL_ROUTE_RFC1918=Yes, I get "run_ip route replace > ..." statements. Is that how it is supposed to be (with "replace")?Yes, I think I want to leave it that way in case the user is actually routing an entire RFC1918 network in the main table.> > When I have statements of the sort of: > > routes > ~~~~ > main 10.0.0.0/8 blackhole > main 172.16.0.0/12 blackhole > main 192.168.0.0/16 blackhole > > That seems to be translated to: > > run_ip route add blackhole 10.0.0.0/8 table 254 > echo "$IP -4 route del blackhole 10.0.0.0/8 table 254 > > /dev/null 2>&1" >> ${VARDIR}/undo_main_routing > run_ip route add blackhole 172.16.0.0/12 table 254 > echo "$IP -4 route del blackhole 172.16.0.0/12 table 254 > > /dev/null 2>&1" >> ${VARDIR}/undo_main_routing > run_ip route add blackhole 192.168.0.0/16 table 254 > echo "$IP -4 route del blackhole 192.168.0.0/16 table 254 > > /dev/null 2>&1" >> ${VARDIR}/undo_main_routing > > (note table numbers instead of names).BUILTINTABLES.patch corrects this problem. -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 \________________________________________________ ------------------------------------------------------------------------------ Own the Future-Intel® Level Up Game Demo Contest 2013 Rise to greatness in Intel''s independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
> The problem here is that you have USE_DEFAULT_RT=No and copy routes from > the main table to the provider cable. The main table had that route and > it has been copied into the ''dmz'' table. That was a bug in the > CLEANUP.patch I sent. The attached DUPLICATE.patch should eliminate the > problem. >Nope, the same thing is still there.>> When I have statements of the sort of: >> >> routes >> ~~~~ >> main 10.0.0.0/8 blackhole >> main 172.16.0.0/12 blackhole >> main 192.168.0.0/16 blackhole >> >> That seems to be translated to: >> >> run_ip route add blackhole 10.0.0.0/8 table 254 >> echo "$IP -4 route del blackhole 10.0.0.0/8 table 254 > >> /dev/null 2>&1" >> ${VARDIR}/undo_main_routing >> run_ip route add blackhole 172.16.0.0/12 table 254 >> echo "$IP -4 route del blackhole 172.16.0.0/12 table 254 > >> /dev/null 2>&1" >> ${VARDIR}/undo_main_routing >> run_ip route add blackhole 192.168.0.0/16 table 254 >> echo "$IP -4 route del blackhole 192.168.0.0/16 table 254 > >> /dev/null 2>&1" >> ${VARDIR}/undo_main_routing >> >> (note table numbers instead of names). >> > > BUILTINTABLES.patch corrects this problem. >This has indeed been fixed. ------------------------------------------------------------------------------ Own the Future-Intel® Level Up Game Demo Contest 2013 Rise to greatness in Intel''s independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
On 03/26/2013 08:16 PM, Mr Dash Four wrote:> >> The problem here is that you have USE_DEFAULT_RT=No and copy routes from >> the main table to the provider cable. The main table had that route and >> it has been copied into the ''dmz'' table. That was a bug in the >> CLEANUP.patch I sent. The attached DUPLICATE.patch should eliminate the >> problem. >> > Nope, the same thing is still there.The attached patch fixes it (I reproduced the problem on one of my systems). -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 \________________________________________________ ------------------------------------------------------------------------------ Own the Future-Intel® Level Up Game Demo Contest 2013 Rise to greatness in Intel''s independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
> The attached patch fixes it (I reproduced the problem on one of my systems). >That 2nd hunk is a funny one... I''ll give it a whirl tonight when I get back and let you know. ------------------------------------------------------------------------------ Own the Future-Intel® Level Up Game Demo Contest 2013 Rise to greatness in Intel''s independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
On 03/27/2013 07:59 AM, Mr Dash Four wrote:> >> The attached patch fixes it (I reproduced the problem on one of my >> systems). >> > That 2nd hunk is a funny one...It is purely cosmetic.> I''ll give it a whirl tonight when I get back and let you know.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 \________________________________________________ ------------------------------------------------------------------------------ Own the Future-Intel® Level Up Game Demo Contest 2013 Rise to greatness in Intel''s independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
>> I''ll give it a whirl tonight when I get back and let you know. >> > > Thanks, >All seems to be in working order now. ------------------------------------------------------------------------------ Own the Future-Intel® Level Up Game Demo Contest 2013 Rise to greatness in Intel''s independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
On 3/27/13 7:47 PM, "Mr Dash Four" <mr.dash.four@googlemail.com> wrote:> >>> I''ll give it a whirl tonight when I get back and let you know. >>> >> >> Thanks, >> >All seems to be in working order now.Thanks. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Own the Future-Intel® Level Up Game Demo Contest 2013 Rise to greatness in Intel''s independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d