The first bug fix below should receive wider testing. So I have uploaded
4.5.14 RC 2. I went ahead and included a simple new feature (see below),
but I neglected to include the change that allows generating ''-m
multiport --ports <port list>'' by placing ''=''
SOURCE PORT(S) columns.
Given that it won''t affect existing configurations, I will add that
feature to 4.5.14 final (or to RC 3 if required).
Problems Corrected since 4.5.14 RC 1:
1) ''blackhole'' routes are now copied to provider tables when
USE_DEFAULT_RT=No. Previously, these routes were not copied with
the result that packets could be routed to blackholed addresses.
2) Duplicate interface names could previously appear in a case
statement in the generated script. These duplicates are now
suppressed.
3) Previously, a duplicate ''echo'' command could appear in the
generated script. Now only a single command appears.
New Feature:
1) ''blackhole'' routes may now be defined in
/etc/shorewall[6]/routes.
Simply place ''blackhole'' in the GATEWAY column and leave
the DEVICE
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 \________________________________________________
------------------------------------------------------------------------------
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
> The first bug fix below should receive wider testing. So I have uploaded > 4.5.14 RC 2. I went ahead and included a simple new feature (see below), > but I neglected to include the change that allows generating ''-m > multiport --ports <port list>'' by placing ''='' SOURCE PORT(S) columns. >I am not sure I understand this - care to elaborate?> Given that it won''t affect existing configurations, I will add that > feature to 4.5.14 final (or to RC 3 if required). > > Problems Corrected since 4.5.14 RC 1: > > 1) ''blackhole'' routes are now copied to provider tables when > USE_DEFAULT_RT=No. Previously, these routes were not copied with > the result that packets could be routed to blackholed addresses. > > 2) Duplicate interface names could previously appear in a case > statement in the generated script. These duplicates are now > suppressed. > > 3) Previously, a duplicate ''echo'' command could appear in the > generated script. Now only a single command appears. > > New Feature: > > 1) ''blackhole'' routes may now be defined in /etc/shorewall[6]/routes. > Simply place ''blackhole'' in the GATEWAY column and leave the DEVICE > column empty. >Good on all counts as far as I can see. The fictitious interface name in "providers" is fixed as well, though when I add "lo" (loopback) (loopback is in a state of "ignore" in my "interfaces" - just FYI) I get a few funnies generated which should not be there, like: run_ip route replace <default gateway address> src $SW_LO_ADDRESS dev lo run_ip route replace <default gateway address> src $SW_LO_ADDRESS dev lo table XX run_ip route add default via <default gateway address> src $SW_LO_ADDRESS dev lo table XX Would there be a way for me to manipulate the blackhole routes in my main table or is this for another day? ------------------------------------------------------------------------------ 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/7/13 4:26 PM, "Mr Dash Four" <mr.dash.four@googlemail.com> wrote:> >> The first bug fix below should receive wider testing. So I have uploaded >> 4.5.14 RC 2. I went ahead and included a simple new feature (see below), >> but I neglected to include the change that allows generating ''-m >> multiport --ports <port list>'' by placing ''='' SOURCE PORT(S) columns. >> >I am not sure I understand this - care to elaborate?Here''s an example from the accounting file: #ACTION CHAIN SOURCE DEST PROTO DEST SOURCE # PORT(S) PORT(S) COUNT - br0 - tcp 80 This rule matches all TCP packets entering through br0 where either the source port or the destination port is 80.>Good on all counts as far as I can see.Good - thanks.> >The fictitious interface name in "providers" is fixed as well, though >when I add "lo" (loopback) (loopback is in a state of "ignore" in my >"interfaces" - just FYI) I get a few funnies generated which should not >be there, like: > >run_ip route replace <default gateway address> src $SW_LO_ADDRESS dev lo >run_ip route replace <default gateway address> src $SW_LO_ADDRESS dev lo >table XX >run_ip route add default via <default gateway address> src >$SW_LO_ADDRESS dev lo table XXWhere else to you mention ''lo'' in your configuration. I have an entry like yours in my interfaces file and I don''t have that issue.> >Would there be a way for me to manipulate the blackhole routes in my >main table or is this for another day?It is going to have to wait until Beta 1. There are some issues to resolve. -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 Thursday 07 Mar 2013 16:27:21 Tom Eastep wrote:> The first bug fix below should receive wider testing. So I have uploaded > 4.5.14 RC 2. I went ahead and included a simple new feature (see below), > but I neglected to include the change that allows generating ''-m > multiport --ports <port list>'' by placing ''='' SOURCE PORT(S) columns. > Given that it won''t affect existing configurations, I will add that > feature to 4.5.14 final (or to RC 3 if required).Tom After the application of the MULTIPORT patch the following netmap entry: DNAT:O 192.168.168.0/24 eth1 10.199.0.0/16 88.88.88.88 tcp 102,103 201,301 Generates the following iptables rule: -A eth1_out -p 6 -s 88.88.88.88 -d 192.168.168.0/24 -m multiport -m multiport --dports 102,103 -m multiport --sports 201,301 -j RAWDNAT --to-dest 10.199.0.0/16 Which produces the following error message: iptables-restore v1.4.18: multiport expection an option Steven. ------------------------------------------------------------------------------ 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
>> I am not sure I understand this - care to elaborate? >> > > Here''s an example from the accounting file: > > #ACTION CHAIN SOURCE DEST PROTO DEST SOURCE > # PORT(S) PORT(S) > COUNT - br0 - tcp 80 > > This rule matches all TCP packets entering through br0 where either > the source port or the destination port is 80. >Ah, I get it! Is this just for "accounting" or is this valid everywhere else?> Good - thanks. >No problem.>> run_ip route replace <default gateway address> src $SW_LO_ADDRESS dev lo >> run_ip route replace <default gateway address> src $SW_LO_ADDRESS dev lo >> table XX >> run_ip route add default via <default gateway address> src >> $SW_LO_ADDRESS dev lo table XX >> > > Where else to you mention ''lo'' in your configuration. I have an entry like > yours in my interfaces file and I don''t have that issue. >Grep tells me the "interfaces" file is the only place I have it. I do have a local zone, but it is nothing to do with "lo". The only place I use "lo" is in "started" to (re)set my arp tables.> It is going to have to wait until Beta 1. There are some issues to resolve. >OK, then. I''ll get to test it when you''re ready. ------------------------------------------------------------------------------ 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
>>> run_ip route replace <default gateway address> src $SW_LO_ADDRESS >>> dev lo >>> run_ip route replace <default gateway address> src $SW_LO_ADDRESS >>> dev lo >>> table XX >>> run_ip route add default via <default gateway address> src >>> $SW_LO_ADDRESS dev lo table XX >>> >> >> Where else to you mention ''lo'' in your configuration. I have an entry >> like >> yours in my interfaces file and I don''t have that issue. >> > Grep tells me the "interfaces" file is the only place I have it. I do > have a local zone, but it is nothing to do with "lo". The only place I > use "lo" is in "started" to (re)set my arp tables.Sorry, forgot to mention something which should be pretty obvious: I get these entries when I place "lo" in the INTERFACE column in "providers". ------------------------------------------------------------------------------ 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/7/13 5:13 PM, "Steven Jan Springl" <steven@springl.ukfsn.org> wrote:>On Thursday 07 Mar 2013 16:27:21 Tom Eastep wrote: >> The first bug fix below should receive wider testing. So I have uploaded >> 4.5.14 RC 2. I went ahead and included a simple new feature (see below), >> but I neglected to include the change that allows generating ''-m >> multiport --ports <port list>'' by placing ''='' SOURCE PORT(S) columns. >> Given that it won''t affect existing configurations, I will add that >> feature to 4.5.14 final (or to RC 3 if required). > >Tom > >After the application of the MULTIPORT patch the following netmap entry: > >DNAT:O 192.168.168.0/24 eth1 10.199.0.0/16 88.88.88.88 tcp 102,103 > >201,301 > >Generates the following iptables rule: > >-A eth1_out -p 6 -s 88.88.88.88 -d 192.168.168.0/24 -m multiport -m >multiport >--dports 102,103 -m multiport --sports 201,301 -j RAWDNAT --to-dest >10.199.0.0/16 > >Which produces the following error message: > >iptables-restore v1.4.18: multiport expection an optionSteven, If you reverse the MULTIPORT patch, what iptables rule is generated? Thanks, -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/7/13 5:15 PM, "Mr Dash Four" <mr.dash.four@googlemail.com> wrote:> >>> I am not sure I understand this - care to elaborate? >>> >> >> Here''s an example from the accounting file: >> >> #ACTION CHAIN SOURCE DEST PROTO DEST SOURCE >> # PORT(S) PORT(S) >> COUNT - br0 - tcp 80 >> >> This rule matches all TCP packets entering through br0 where either >> the source port or the destination port is 80. >> >Ah, I get it! Is this just for "accounting" or is this valid everywhere >else?It''s good for any file that has a SOURCE PORT(S) column. -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/7/13 5:19 PM, "Mr Dash Four" <mr.dash.four@googlemail.com> wrote:> >>>> run_ip route replace <default gateway address> src $SW_LO_ADDRESS >>>> dev lo >>>> run_ip route replace <default gateway address> src $SW_LO_ADDRESS >>>> dev lo >>>> table XX >>>> run_ip route add default via <default gateway address> src >>>> $SW_LO_ADDRESS dev lo table XX >>>> >>> >>> Where else to you mention ''lo'' in your configuration. I have an entry >>> like >>> yours in my interfaces file and I don''t have that issue. >>> >> Grep tells me the "interfaces" file is the only place I have it. I do >> have a local zone, but it is nothing to do with "lo". The only place I >> use "lo" is in "started" to (re)set my arp tables. >Sorry, forgot to mention something which should be pretty obvious: I get >these entries when I place "lo" in the INTERFACE column in "providers".This happens when you also have the ''ignore'' interfaces entry? -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
> This happens when you also have the ''ignore'' interfaces entry? >Yes. ------------------------------------------------------------------------------ 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 Friday 08 Mar 2013 01:25:39 Tom Eastep wrote:> On 3/7/13 5:13 PM, "Steven Jan Springl" <steven@springl.ukfsn.org> wrote: > >On Thursday 07 Mar 2013 16:27:21 Tom Eastep wrote: > >> The first bug fix below should receive wider testing. So I have uploaded > >> 4.5.14 RC 2. I went ahead and included a simple new feature (see below), > >> but I neglected to include the change that allows generating ''-m > >> multiport --ports <port list>'' by placing ''='' SOURCE PORT(S) columns. > >> Given that it won''t affect existing configurations, I will add that > >> feature to 4.5.14 final (or to RC 3 if required). > > > >Tom > > > >After the application of the MULTIPORT patch the following netmap entry: > > > >DNAT:O 192.168.168.0/24 eth1 10.199.0.0/16 88.88.88.88 tcp 102,103 > > > >201,301 > > > >Generates the following iptables rule: > > > >-A eth1_out -p 6 -s 88.88.88.88 -d 192.168.168.0/24 -m multiport -m > >multiport > >--dports 102,103 -m multiport --sports 201,301 -j RAWDNAT --to-dest > >10.199.0.0/16 > > > >Which produces the following error message: > > > >iptables-restore v1.4.18: multiport expection an option > > Steven, > > If you reverse the MULTIPORT patch, what iptables rule is generated? >Tom The following rule is generated: -A eth1_out -p 6 -s 88.88.88.88 -d 192.168.168.0/24 -m multiport --dports 102,103 -m multiport --sports 201,301 -j RAWDNAT --to-dest 10.199.0.0/16 Steven. ------------------------------------------------------------------------------ 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/7/13 5:30 PM, "Steven Jan Springl" <steven@springl.ukfsn.org> wrote:>On Friday 08 Mar 2013 01:25:39 Tom Eastep wrote: >> On 3/7/13 5:13 PM, "Steven Jan Springl" <steven@springl.ukfsn.org> >>wrote: >> >On Thursday 07 Mar 2013 16:27:21 Tom Eastep wrote: >> >> The first bug fix below should receive wider testing. So I have >>uploaded >> >> 4.5.14 RC 2. I went ahead and included a simple new feature (see >>below), >> >> but I neglected to include the change that allows generating ''-m >> >> multiport --ports <port list>'' by placing ''='' SOURCE PORT(S) columns. >> >> Given that it won''t affect existing configurations, I will add that >> >> feature to 4.5.14 final (or to RC 3 if required). >> > >> >Tom >> > >> >After the application of the MULTIPORT patch the following netmap >>entry: >> > >> >DNAT:O 192.168.168.0/24 eth1 10.199.0.0/16 88.88.88.88 tcp >>102,103 >> > >> >201,301 >> > >> >Generates the following iptables rule: >> > >> >-A eth1_out -p 6 -s 88.88.88.88 -d 192.168.168.0/24 -m multiport -m >> >multiport >> >--dports 102,103 -m multiport --sports 201,301 -j RAWDNAT --to-dest >> >10.199.0.0/16 >> > >> >Which produces the following error message: >> > >> >iptables-restore v1.4.18: multiport expection an option >> >> Steven, >> >> If you reverse the MULTIPORT patch, what iptables rule is generated? >> > >Tom > >The following rule is generated: > >-A eth1_out -p 6 -s 88.88.88.88 -d 192.168.168.0/24 -m multiport --dports >102,103 -m multiport --sports 201,301 -j RAWDNAT --to-dest 10.199.0.0/16Thanks Steven. I think this will fix it. -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 Friday 08 Mar 2013 01:50:24 Tom Eastep wrote:> On 3/7/13 5:30 PM, "Steven Jan Springl" <steven@springl.ukfsn.org> wrote: > >On Friday 08 Mar 2013 01:25:39 Tom Eastep wrote: > >> On 3/7/13 5:13 PM, "Steven Jan Springl" <steven@springl.ukfsn.org> > >> > >>wrote: > >> >On Thursday 07 Mar 2013 16:27:21 Tom Eastep wrote: > >> >> The first bug fix below should receive wider testing. So I have > >> > >>uploaded > >> > >> >> 4.5.14 RC 2. I went ahead and included a simple new feature (see > >> > >>below), > >> > >> >> but I neglected to include the change that allows generating ''-m > >> >> multiport --ports <port list>'' by placing ''='' SOURCE PORT(S) columns. > >> >> Given that it won''t affect existing configurations, I will add that > >> >> feature to 4.5.14 final (or to RC 3 if required). > >> > > >> >Tom > >> > > >> >After the application of the MULTIPORT patch the following netmap > >> > >>entry: > >> >DNAT:O 192.168.168.0/24 eth1 10.199.0.0/16 88.88.88.88 tcp > >> > >>102,103 > >> > >> >201,301 > >> > > >> >Generates the following iptables rule: > >> > > >> >-A eth1_out -p 6 -s 88.88.88.88 -d 192.168.168.0/24 -m multiport -m > >> >multiport > >> >--dports 102,103 -m multiport --sports 201,301 -j RAWDNAT --to-dest > >> >10.199.0.0/16 > >> > > >> >Which produces the following error message: > >> > > >> >iptables-restore v1.4.18: multiport expection an option > >> > >> Steven, > >> > >> If you reverse the MULTIPORT patch, what iptables rule is generated? > > > >Tom > > > >The following rule is generated: > > > >-A eth1_out -p 6 -s 88.88.88.88 -d 192.168.168.0/24 -m multiport --dports > >102,103 -m multiport --sports 201,301 -j RAWDNAT --to-dest 10.199.0.0/16 > > Thanks Steven. > > I think this will fix it. > > -Tom > You do not need a parachute to skydive. You only need a parachute to > skydive twice.Tom Confirmed, the patch fixes the problem. Thanks. Steven. ------------------------------------------------------------------------------ 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/7/13 6:06 PM, "Steven Jan Springl" <steven@springl.ukfsn.org> wrote:>Confirmed, the patch fixes the problem.Thanks Steven, -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
>> This happens when you also have the ''ignore'' interfaces entry? >> > Yes.I don''t know how relevant this is, but though to mention it anyway: since the upgrade, when I try to start shorewall I am getting "sh: brctl: command not found" messages (about 6-7 of these messages appear in the log). Shorewall seems fine though - up an running... ------------------------------------------------------------------------------ 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/7/13 6:54 PM, "Mr Dash Four" <mr.dash.four@googlemail.com> wrote:> >>> This happens when you also have the ''ignore'' interfaces entry? >>> >> Yes. >I don''t know how relevant this is, but though to mention it anyway: >since the upgrade, when I try to start shorewall I am getting "sh: >brctl: command not found" messages (about 6-7 of these messages appear >in the log). Shorewall seems fine though - up an running...In which log does this appear? Looking at the 4.5.13->4.5.14 diff, I see only: eastep@gateway:~/shorewall/build/4.5.14$ fgrep brctl patch-4.5.14 - which ''brctl'' && qt( "brctl show | tail -n+2 | grep -q ''^$_[0]\[\[:space:\]\]''" ); + qt which ''brctl'' && qt( "brctl show | tail -n+2 | grep -q ''^$_[0]\[\[:space:\]\]''" ); teastep@gateway:~/shorewall/build/4.5.14$ Adding ''qt '' (quiet) should result in fewer such messages since it redirects STDERR to /dev/null. -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
Tom Rule: ACCEPT fw lan tcp 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16 Generates the following iptables rule: -A fw-lan -p 6 -m multiport --ports 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16 -j ACCEPT Which produces the following error message: iptables-restore v1.4.18: too many ports specified Steven. ------------------------------------------------------------------------------ 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/07/2013 05:03 PM, Tom Eastep wrote:> On 3/7/13 4:26 PM, "Mr Dash Four" <mr.dash.four@googlemail.com> wrote: > >> >>> The first bug fix below should receive wider testing. So I have uploaded >>> 4.5.14 RC 2. I went ahead and included a simple new feature (see below), >>> but I neglected to include the change that allows generating ''-m >>> multiport --ports <port list>'' by placing ''='' SOURCE PORT(S) columns. >>> >> I am not sure I understand this - care to elaborate? > > Here''s an example from the accounting file: > > #ACTION CHAIN SOURCE DEST PROTO DEST SOURCE > # PORT(S) PORT(S) > COUNT - br0 - tcp 80 > > This rule matches all TCP packets entering through br0 where either > the source port or the destination port is 80. > > > >> Good on all counts as far as I can see. > > Good - thanks. > >> >> The fictitious interface name in "providers" is fixed as well, though >> when I add "lo" (loopback) (loopback is in a state of "ignore" in my >> "interfaces" - just FYI) I get a few funnies generated which should not >> be there, like: >> >> run_ip route replace <default gateway address> src $SW_LO_ADDRESS dev lo >> run_ip route replace <default gateway address> src $SW_LO_ADDRESS dev lo >> table XX >> run_ip route add default via <default gateway address> src >> $SW_LO_ADDRESS dev lo table XX > > Where else to you mention ''lo'' in your configuration. I have an entry like > yours in my interfaces file and I don''t have that issue. >> >> Would there be a way for me to manipulate the blackhole routes in my >> main table or is this for another day? > > It is going to have to wait until Beta 1. There are some issues to resolve.I woke up this morning with an easy solution to those issues. Patch is 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
On 03/08/2013 05:49 AM, Steven Jan Springl wrote:> Rule: > > ACCEPT fw lan tcp 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16 > > Generates the following iptables rule: > > -A fw-lan -p 6 -m multiport --ports 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16 -j > ACCEPT > > Which produces the following error message: > > iptables-restore v1.4.18: too many ports specified >The attached patch causes long --ports lists to be be split into multiple rules. Thanks Steven, -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 Friday 08 Mar 2013 15:29:24 Tom Eastep wrote:> On 03/08/2013 05:49 AM, Steven Jan Springl wrote: > > Rule: > > > > ACCEPT fw lan tcp 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16 > > > > Generates the following iptables rule: > > > > -A fw-lan -p 6 -m multiport --ports > > 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16 -j ACCEPT > > > > Which produces the following error message: > > > > iptables-restore v1.4.18: too many ports specified > > The attached patch causes long --ports lists to be be split into > multiple rules. > > Thanks Steven, > -TomTom Confirmed, the patch fixes the issue. Thanks. Steven. ------------------------------------------------------------------------------ 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/08/2013 08:19 AM, Steven Jan Springl wrote:> > Confirmed, the patch fixes the issue. >Thanks, Steven. -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
Just reminded me I planned to write a message yesturday and mention, I got the idea to use the new notation to consolidate the prioritizing rules for both NTP and DNS which currently is a seperate rule for outgoing queries and for outgoing replies from the local servers figuring less rules being easier to read and for iptables to process. Didn''t consider it would be an issue until running shorewall check and it complained the = was unexpected. I''m guessing that it was simply not intended to be used in the tcrules file as there was no other error messages to indicate that I broke anything, just wanted to mention it as without checking the finalized documentation I can''t be certain whether you meant that to work or not and I figured waiting on that could well be leaving it too late. On 07/03/13 16:27, Tom Eastep wrote:> The first bug fix below should receive wider testing. So I have uploaded > 4.5.14 RC 2. I went ahead and included a simple new feature (see below), > but I neglected to include the change that allows generating ''-m > multiport --ports <port list>'' by placing ''='' SOURCE PORT(S) columns. > Given that it won''t affect existing configurations, I will add that > feature to 4.5.14 final (or to RC 3 if required). > > Problems Corrected since 4.5.14 RC 1: > > 1) ''blackhole'' routes are now copied to provider tables when > USE_DEFAULT_RT=No. Previously, these routes were not copied with > the result that packets could be routed to blackholed addresses. > > 2) Duplicate interface names could previously appear in a case > statement in the generated script. These duplicates are now > suppressed. > > 3) Previously, a duplicate ''echo'' command could appear in the > generated script. Now only a single command appears. > > New Feature: > > 1) ''blackhole'' routes may now be defined in /etc/shorewall[6]/routes. > Simply place ''blackhole'' in the GATEWAY column and leave the DEVICE > column empty. > > -Tom > > > ------------------------------------------------------------------------------ > 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 > > > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------------------------------ 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
> In which log does this appear? Looking at the 4.5.13->4.5.14 diff, I see > only: > > eastep@gateway:~/shorewall/build/4.5.14$ fgrep brctl patch-4.5.14 > - which ''brctl'' && qt( "brctl show | tail -n+2 | grep -q > ''^$_[0]\[\[:space:\]\]''" ); > + qt which ''brctl'' && qt( "brctl show | tail -n+2 | grep -q > ''^$_[0]\[\[:space:\]\]''" ); > teastep@gateway:~/shorewall/build/4.5.14$ >I haven''t seen this before the upgrade, though in all fairness I''ve been experimenting with various shorewall versions on that machine prior to this. ------------------------------------------------------------------------------ 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
> I woke up this morning with an easy solution to those issues. Patch is > attached. >I''ll have the chance to test this tonight and will report back then. ------------------------------------------------------------------------------ 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/08/2013 09:03 AM, Mr Dash Four wrote:> >> I woke up this morning with an easy solution to those issues. Patch is >> attached. >> > I''ll have the chance to test this tonight and will report back then. >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/08/2013 08:57 AM, Matt Joyce wrote:> Just reminded me I planned to write a message yesturday and mention, I > got the idea to use the new notation to consolidate the prioritizing > rules for both NTP and DNS which currently is a seperate rule for > outgoing queries and for outgoing replies from the local servers > figuring less rules being easier to read and for iptables to process. > Didn''t consider it would be an issue until running shorewall check and > it complained the = was unexpected. I''m guessing that it was simply not > intended to be used in the tcrules file as there was no other error > messages to indicate that I broke anything, just wanted to mention it as > without checking the finalized documentation I can''t be certain whether > you meant that to work or not and I figured waiting on that could well > be leaving it too late. >What rule failed to work? I just testing this entry in /etc/shorewall/rules: ACCEPT net fw tcp 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15 Note that there is another patch (which I just posted on the development list) that is required for port lists longer than 15. -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
>> I''ll have the chance to test this tonight and will report back then. >> >> > > Thanks. >Looking at this patch, I am not sure I understand how do I select these routes - should I just put "main" in the PROVIDER column in "routes" or is there another way? ------------------------------------------------------------------------------ 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/08/2013 09:03 AM, Mr Dash Four wrote:> >> In which log does this appear? Looking at the 4.5.13->4.5.14 diff, I see >> only: >> >> eastep@gateway:~/shorewall/build/4.5.14$ fgrep brctl patch-4.5.14 >> - which ''brctl'' && qt( "brctl show | tail -n+2 | grep -q >> ''^$_[0]\[\[:space:\]\]''" ); >> + qt which ''brctl'' && qt( "brctl show | tail -n+2 | grep -q >> ''^$_[0]\[\[:space:\]\]''" ); >> teastep@gateway:~/shorewall/build/4.5.14$ >> > I haven''t seen this before the upgrade, though in all fairness I''ve been > experimenting with various shorewall versions on that machine prior to this.And you are seeing these in your system log? -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/08/2013 09:10 AM, Mr Dash Four wrote:> >>> I''ll have the chance to test this tonight and will report back then. >>> >>> >> >> Thanks. >> > Looking at this patch, I am not sure I understand how do I select these > routes - should I just put "main" in the PROVIDER column in "routes" or > is there another way?Just put ''main'' in the PROVIDER column. The compiler has always accepted ''main'', but prior to this patch it has generated bad shell code. -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
> And you are seeing these in your system log? >I''ve noticed these messages after the upgrade. Don''t remember seeing them with previous versions, but can''t be 100% sure - will re-check when I get back tonight as I keep my syslogs for quite a long period of time, so if they appear there it should be easy to spot. I''ll let you know though. ------------------------------------------------------------------------------ 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
> Just put ''main'' in the PROVIDER column. The compiler has always accepted > ''main'', but prior to this patch it has generated bad shell code. >Got it, 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
>> Just put ''main'' in the PROVIDER column. The compiler has always accepted >> ''main'', but prior to this patch it has generated bad shell code. >> > Got it, thanks!Sorry, one more query regarding this - I take it the routes defined in "routes" for the main table are in addition of any existing ones I already have in place, right? In other words, the routes already present when the device was brought up (taken from sysconfig/network-scripts/route-XXX for example) are not wiped out by shorewall, is that correct? ------------------------------------------------------------------------------ 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
Going to have to apologize here, I just tried it again and it is now working, I can only think that I must have made some other typo that triggered it to fail, miss-placed - perhaps because it had previously had issues with the exact same rule I just added so given the only change here is that I only just typed it in again the cause would seem most likely user typed it in wrong first time. Never saw anything when I checked it over though, guess easy enough to miss a single character though especially with the danger of reading what you expect not what''s actually there. *Wanders off feeling rather stupid for that one* On 08/03/13 17:05, Tom Eastep wrote:> On 03/08/2013 08:57 AM, Matt Joyce wrote: >> Just reminded me I planned to write a message yesturday and mention, I >> got the idea to use the new notation to consolidate the prioritizing >> rules for both NTP and DNS which currently is a seperate rule for >> outgoing queries and for outgoing replies from the local servers >> figuring less rules being easier to read and for iptables to process. >> Didn''t consider it would be an issue until running shorewall check and >> it complained the = was unexpected. I''m guessing that it was simply not >> intended to be used in the tcrules file as there was no other error >> messages to indicate that I broke anything, just wanted to mention it as >> without checking the finalized documentation I can''t be certain whether >> you meant that to work or not and I figured waiting on that could well >> be leaving it too late. >> > What rule failed to work? I just testing this entry in /etc/shorewall/rules: > > ACCEPT net fw tcp 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15 > > Note that there is another patch (which I just posted on the development > list) that is required for port lists longer than 15. > > -Tom > > > ------------------------------------------------------------------------------ > 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 > > > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------------------------------ 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/08/2013 09:21 AM, Mr Dash Four wrote:> >>> Just put ''main'' in the PROVIDER column. The compiler has always accepted >>> ''main'', but prior to this patch it has generated bad shell code. >>> >> Got it, thanks! > Sorry, one more query regarding this - I take it the routes defined in > "routes" for the main table are in addition of any existing ones I > already have in place, right? In other words, the routes already present > when the device was brought up (taken from > sysconfig/network-scripts/route-XXX for example) are not wiped out by > shorewall, is that correct?That is correct. -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/08/2013 09:16 AM, Mr Dash Four wrote:> >> And you are seeing these in your system log? >> > I''ve noticed these messages after the upgrade. Don''t remember seeing > them with previous versions, but can''t be 100% sure - will re-check when > I get back tonight as I keep my syslogs for quite a long period of time, > so if they appear there it should be easy to spot. I''ll let you know though.Also, please try the attached patch and see if the problem goes away. 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/07/2013 05:19 PM, Mr Dash Four wrote:> Sorry, forgot to mention something which should be pretty obvious: I get > these entries when I place "lo" in the INTERFACE column in "providers". >Does the providers entry specify the ''tproxy'' option? 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/08/2013 11:29 AM, Tom Eastep wrote:> On 03/07/2013 05:19 PM, Mr Dash Four wrote: > >> Sorry, forgot to mention something which should be pretty obvious: I get >> these entries when I place "lo" in the INTERFACE column in "providers". >> > > Does the providers entry specify the ''tproxy'' option? >And if not, for what purpose are you trying to use ''lo'' as a provider interface? 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
>> Does the providers entry specify the ''tproxy'' option? >>No.> And if not, for what purpose are you trying to use ''lo'' as a provider > interface? >Testing. I wanted to see what shorewall will do if I include an interface which has the "ignore" option (and therefore is not usually checked by shorewall whether it is up or down). Shorewall should, I think, issue an error, or a warning at least in such cases. ------------------------------------------------------------------------------ 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
>> I''ve noticed these messages after the upgrade. Don''t remember seeing >> them with previous versions, but can''t be 100% sure - will re-check when >> I get back tonight as I keep my syslogs for quite a long period of time, >> so if they appear there it should be easy to spot. I''ll let you know though. >> > > Also, please try the attached patch and see if the problem goes away. >100% certain this message started appearing during the latest RC testing. The attached patch fixes it though. ------------------------------------------------------------------------------ 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
>> It is going to have to wait until Beta 1. There are some issues to resolve. >> > > I woke up this morning with an easy solution to those issues. Patch is > attached. >OK, the patch works, though I found a few other "interesting" issues: When I completely disable the blackhole routes in shorewall.conf, then put "-" in my DUPLICATE column in "providers" (instead of "main" as was the case - the idea being - tell shorewall "do not duplicate anything"), bearing in mind that I also have "none" in COPY, I get the following message: ERROR: A non-empty COPY column requires that a routing table be specified in the DUPLICATE column. OK, I then placed "none" in DUPLICATE and this time I''ve got something else: Error: argument "none" is wrong: table id value is invalid though shorewall was happy with this as it processed everything else and started successfully, not copying anything I didn''t specify into my new provider table - all routes which appear there are as expected. ------------------------------------------------------------------------------ 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/8/13 5:24 PM, "Mr Dash Four" <mr.dash.four@googlemail.com> wrote:> >>> Does the providers entry specify the ''tproxy'' option? >>> >No. > >> And if not, for what purpose are you trying to use ''lo'' as a provider >> interface? >> >Testing. I wanted to see what shorewall will do if I include an >interface which has the "ignore" option (and therefore is not usually >checked by shorewall whether it is up or down). Shorewall should, I >think, issue an error, or a warning at least in such cases.You should probably review the definition of ''ignore''. The choice of keyword is probably unfortunate, but the scope of the option is pretty limited. -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/8/13 5:25 PM, "Mr Dash Four" <mr.dash.four@googlemail.com> wrote:> >>> I''ve noticed these messages after the upgrade. Don''t remember seeing >>> them with previous versions, but can''t be 100% sure - will re-check >>>when >>> I get back tonight as I keep my syslogs for quite a long period of >>>time, >>> so if they appear there it should be easy to spot. I''ll let you know >>>though. >>> >> >> Also, please try the attached patch and see if the problem goes away. >> >100% certain this message started appearing during the latest RC >testing. The attached patch fixes it though.Okay, thanks. The patch will be included in 4.5.14. -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/8/13 5:25 PM, "Mr Dash Four" <mr.dash.four@googlemail.com> wrote:> >>> It is going to have to wait until Beta 1. There are some issues to >>>resolve. >>> >> >> I woke up this morning with an easy solution to those issues. Patch is >> attached. >> >OK, the patch works, though I found a few other "interesting" issues: >When I completely disable the blackhole routes in shorewall.conf, then >put "-" in my DUPLICATE column in "providers" (instead of "main" as was >the case - the idea being - tell shorewall "do not duplicate anything"), >bearing in mind that I also have "none" in COPY, I get the following >message: > >ERROR: A non-empty COPY column requires that a routing table be >specified in the DUPLICATE column.That problem is resolved by the attached patch.> >OK, I then placed "none" in DUPLICATE and this time I''ve got something >else: > >Error: argument "none" is wrong: table id value is invalid > >though shorewall was happy with this as it processed everything else and >started successfully, not copying anything I didn''t specify into my new >provider table - all routes which appear there are as expected.I''m not sure that this issue is completely solvable. Suppose that your /etc/shorewall/init file populates table 46. Then you place 46 in the DUPLICATE column. With the current code, that will work; any change I make to reject ''46'' at compile time will break this scenario. How about a warning that says that the content of the DUPLICATE column is not a recognized standard routing table? -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/8/13 5:25 PM, "Mr Dash Four" <mr.dash.four@googlemail.com> wrote:> >>> It is going to have to wait until Beta 1. There are some issues to >>>resolve. >>> >> >> I woke up this morning with an easy solution to those issues. Patch is >> attached. >> >OK, the patch works, though I found a few other "interesting" issues: >When I completely disable the blackhole routes in shorewall.conf, then >put "-" in my DUPLICATE column in "providers" (instead of "main" as was >the case - the idea being - tell shorewall "do not duplicate anything"), >bearing in mind that I also have "none" in COPY, I get the following >message: > >ERROR: A non-empty COPY column requires that a routing table be >specified in the DUPLICATE column.That problem is resolved by the attached patch.> >OK, I then placed "none" in DUPLICATE and this time I''ve got something >else: > >Error: argument "none" is wrong: table id value is invalid > >though shorewall was happy with this as it processed everything else and >started successfully, not copying anything I didn''t specify into my new >provider table - all routes which appear there are as expected.I''m not sure that this issue is completely solvable. Suppose that your /etc/shorewall/init file populates table 46. Then you place 46 in the DUPLICATE column. With the current code, that will work; any change I make to reject ''46'' at compile time will break this scenario. How about a warning that says that the content of the DUPLICATE column is not a recognized standard routing table? -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
> I''m not sure that this issue is completely solvable. Suppose that your > /etc/shorewall/init file populates table 46. Then you place 46 in the > DUPLICATE column. With the current code, that will work; any change I make > to reject ''46'' at compile time will break this scenario. How about a > warning that says that the content of the DUPLICATE column is not a > recognized standard routing table? >I haven''t tested this yet - just want to make sure that understand the whole thing. The purpose of DUPLICATE is to copy across all routes (incl. blackhole ones) for the specified INTERFACE to the new PROVIDER table, including also all routes for interfaces specified in the COPY column (the dash ("-") in DUPLICATE/COPY being a special case, so I won''t deal with this scenario right now), is that right? If so, then by looking at your patch, if "none" is specified, then no copy takes place (then, I assume the COPY *should* also contain "none", right?). However, if a value is specified (either a number or a name), then that (existing) table is used as source. Have I got this right? If so, if the value specified in DUPLICATE is wrong (in other words, that table isn''t specified in "providers" and does not exist in /etc/iproute2/rt_tables either), in which case shorewall can''t copy anything, then why not issue an error and stop processing? have I missed anything? ------------------------------------------------------------------------------ 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/08/2013 07:37 PM, Mr Dash Four wrote:> I haven''t tested this yet - just want to make sure that understand the > whole thing. > > The purpose of DUPLICATE is to copy across all routes (incl. blackhole > ones) for the specified INTERFACE to the new PROVIDER table, including > also all routes for interfaces specified in the COPY column (the dash > ("-") in DUPLICATE/COPY being a special case, so I won''t deal with this > scenario right now), is that right?Yes.> > If so, then by looking at your patch, if "none" is specified, then no > copy takes place (then, I assume the COPY *should* also contain "none", > right?).My patch allows ''none'' in the COPY column when ''-'' appears in the DUPLICATE column.> However, if a value is specified (either a number or a name), > then that (existing) table is used as source. Have I got this right?Yes.> > If so, if the value specified in DUPLICATE is wrong (in other words, > that table isn''t specified in "providers" and does not exist in > /etc/iproute2/rt_tables either), in which case shorewall can''t copy > anything, then why not issue an error and stop processing? have I missed > anything?When compiling for export, the remote firewall''s /etc/iproute2/rt_tables isn''t available at compile time, so no check is possible in that case. Also, the /etc/iproute2/rt_tables file is shared by IPv4 and IPv6. Here''s the one from my firewall: # # reserved values # 255 local 254 main 253 default 250 balance 0 unspec # # local # 1 ComcastB 2 ComcastC 3 TProxy 4 HE2 5 HE1 6 6to4 Tables 1 - 3 are IPv4 while tables 4-6 are IPv6. So if I place HE2 in the DUPLICATE column of /etc/shorewall/providers, a check against /etc/iproute2/rt_tables will succeed but no routes will ever be copied. So I still favor issuing a warning if the DUPLICATE column contains anything but ''-'', ''main'' or a provider name/number that appears in an earlier entry. -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
> My patch allows ''none'' in the COPY column when ''-'' appears in the > DUPLICATE column. >Yep, just tested it - nothing is then copied from "main", which is what was supposed to happen.> When compiling for export, the remote firewall''s /etc/iproute2/rt_tables > isn''t available at compile time, so no check is possible in that case. > > Also, the /etc/iproute2/rt_tables file is shared by IPv4 and IPv6. > Here''s the one from my firewall: > > # > # reserved values > # > 255 local > 254 main > 253 default > 250 balance > 0 unspec > # > # local > # > 1 ComcastB > 2 ComcastC > 3 TProxy > 4 HE2 > 5 HE1 > 6 6to4 > > Tables 1 - 3 are IPv4 while tables 4-6 are IPv6. So if I place HE2 in > the DUPLICATE column of /etc/shorewall/providers, a check against > /etc/iproute2/rt_tables will succeed but no routes will ever be copied. >Got it, thanks.> So I still favor issuing a warning if the DUPLICATE column contains > anything but ''-'', ''main'' or a provider name/number that appears in an > earlier entry. >Makes perfect sense to me, though I can''t judge this if there is a mixture of ipv4 and ipv6 interfaces on the same system - don''t really know what the contents of main would be then. ------------------------------------------------------------------------------ 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/9/13 9:17 AM, "Mr Dash Four" <mr.dash.four@googlemail.com> wrote:>Makes perfect sense to me, though I can''t judge this if there is a >mixture of ipv4 and ipv6 interfaces on the same system - don''t really >know what the contents of main would be then.Each address family has its own ''main'' table: 67.170.120.1 dev eth0 scope link src 67.170.121.6 4.2.2.2 via 70.90.191.126 dev eth1 216.218.226.238 via 70.90.191.126 dev eth1 172.20.1.44 dev br0 scope link 70.90.191.126 dev eth1 scope link src 70.90.191.121 70.90.191.124 dev br0 scope link 70.90.191.125 dev br0 scope link 70.90.191.122 dev br0 scope link 172.20.0.2 dev tun0 proto kernel scope link src 172.20.0.1 70.90.191.120/29 dev eth1 proto kernel scope link src 70.90.191.121 172.20.0.0/25 via 172.20.0.2 dev tun0 172.20.2.0/24 dev br0 proto kernel scope link src 172.20.2.254 10.1.10.0/24 dev eth1 proto kernel scope link src 10.1.10.11 172.20.1.0/24 dev eth2 proto kernel scope link src 172.20.1.254 67.170.120.0/21 dev eth0 proto kernel scope link src 67.170.121.6 metric 1 blackhole 192.168.0.0/16 blackhole 172.16.0.0/12 blackhole 10.0.0.0/8 root@gateway:~# ip -6 -o route ls table main | fgrep -v cache 2001:470:a:227::1 dev sit1 metric 1024 mtu 1480 advmss 1420 hoplimit 4294967295 2001:470:a:227::/64 via :: dev sit1 proto kernel metric 256 mtu 1480 advmss 1420 hoplimit 4294967295 2001:470:a:787::1 dev sit2 metric 1024 mtu 1480 advmss 1420 hoplimit 4294967295 2001:470:a:787::/64 via :: dev sit2 proto kernel metric 256 mtu 1480 advmss 1420 hoplimit 4294967295 2001:470:b:227::40/124 dev br0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 4294967295 2001:470:b:227::/64 dev br0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 4294967295 2001:470:b:787::/64 dev eth2 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 4294967295 fe80::/64 dev eth2 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 4294967295 fe80::/64 dev ifb0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 4294967295 fe80::/64 dev br0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 4294967295 fe80::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 4294967295 fe80::/64 via :: dev sit1 proto kernel metric 256 mtu 1480 advmss 1420 hoplimit 4294967295 fe80::/64 via :: dev sit2 proto kernel metric 256 mtu 1480 advmss 1420 hoplimit 4294967295 root@gateway:~# -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
> Each address family has its own ''main'' table: >So, you have different "main" tables for ipv4 and ipv6, though they are both called "main" and appear under the same name in /etc/iproute2/rt_tables, is that right? If so, when you define a table (say, "dmz"), how does ip know what is it for: ipv4 or ipv6? Or is it a case of first-come, first-serve basis? In other words, if I define a custom table called "dmz" and then place ipv4 route in it, I can''t then use it for adding ipv6 routes after that and vice-versa? Is that how it works? ------------------------------------------------------------------------------ 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/9/13 9:47 AM, "Mr Dash Four" <mr.dash.four@googlemail.com> wrote:> >> Each address family has its own ''main'' table: >> >So, you have different "main" tables for ipv4 and ipv6, though they are >both called "main" and appear under the same name in >/etc/iproute2/rt_tables, is that right?/etc/iproute2/rt_tables simply maps names to numbers and vice versa. That''s its sole purpose; it doesn¹t ''define'' tables. You can freely add routes to a table that has no entry in /etc/iproute2/rt_tables.> >If so, when you define a table (say, "dmz"), how does ip know what is it >for: ipv4 or ipv6? Or is it a case of first-come, first-serve basis? In >other words, if I define a custom table called "dmz" and then place ipv4 >route in it, I can''t then use it for adding ipv6 routes after that and >vice-versa? Is that how it works?Both IPv4 and IPv6 can have a table 4. So if your /etc/iproute2/rt_tables contains: dmz 4 then it is okay for both families to have routes in ''dmz''. -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