4.5.17 RC 1 is now available for testing.
Changes since Beta 3:
1) A ''local'' zone now works correctly with
''destonly'' specified on the
loopback device.
2) Previously, trivial exclusion matches appeared at the end of an
iptables rule rather than in their logical order. This has been
corrected.
3) The fw2fw (fw-fw) chain is now omitted when there is a
''local''
zone.
Thank you for testing,
-Tom
--
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________
------------------------------------------------------------------------------
Try New Relic Now & We''ll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
Tom Eastep wrote:> 4.5.17 RC 1 is now available for testing. > > Changes since Beta 3: > > 1) A ''local'' zone now works correctly with ''destonly'' specified on the > loopback device. >That doesn''t seem to work - see my previous email on the subject. I now can''t specify "local" as an option in my interfaces file.> 2) Previously, trivial exclusion matches appeared at the end of an > iptables rule rather than in their logical order. This has been > corrected. >That is now fixed.> 3) The fw2fw (fw-fw) chain is now omitted when there is a ''local'' > zone. >That is now gone. One optimisation bug: rules ~~~~~ ACCEPT $FW:+set1 net:+set2 ; user:root, switch:allow_set2=0 produces -A fw2net -m set --match-set set1 src -m set --match-set set2 dst -m owner --uid-owner 0 -m condition --condition allow_set2 -j ACCEPT It makes sense for the "condition" match, as well as owner and possibly any other match, bar nfacct matches, to have higher priority and be placed before the ipset matches, since they 1. could be checked quicker than ipset matches; and 2. there is no point checking the set matches if the "condition" match isn''t satisfied. ipset matches are the most resource-consuming operations, so it makes sense to place them last, whenever possible (accounting matches excluded, of course). In other words, do this: -A fw2net -m condition --condition allow_set2 --uid-owner 0 -m set --match-set set1 src -m set --match-set set2 dst -m owner -j ACCEPT This will speed up the traversal of rules. Currently, it seems that ipset matches "enjoy" the highest priority and are placed first in a given iptables rule. I think they need to be defined to have less priority than that of "owner" and "condition" matches to start with. ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
On 5/25/13 11:00 AM, "Dash Four" <mr.dash.four@googlemail.com> wrote:> >Tom Eastep wrote: >> 4.5.17 RC 1 is now available for testing. >> >> Changes since Beta 3: >> >> 1) A ''local'' zone now works correctly with ''destonly'' specified on the >> loopback device. >> >That doesn''t seem to work - see my previous email on the subject. I now >can''t specify "local" as an option in my interfaces file.Please refer to the Beta 3 release announcement - ''local'' is now a zone type rather than an interface option.> >> 2) Previously, trivial exclusion matches appeared at the end of an >> iptables rule rather than in their logical order. This has been >> corrected. >> >That is now fixed.Thanks.>> 3) The fw2fw (fw-fw) chain is now omitted when there is a ''local'' >> zone. >> >That is now gone.Thanks.> > >One optimisation bug: > >rules >~~~~~ >ACCEPT $FW:+set1 net:+set2 ; user:root, switch:allow_set2=0 > >produces > >-A fw2net -m set --match-set set1 src -m set --match-set set2 dst -m >owner --uid-owner 0 -m condition --condition allow_set2 -j ACCEPT > >It makes sense for the "condition" match, as well as owner and possibly >any other match, bar nfacct matches, to have higher priority and be >placed before the ipset matches, since they 1. could be checked quicker >than ipset matches; and 2. there is no point checking the set matches if >the "condition" match isn''t satisfied. > >ipset matches are the most resource-consuming operations, so it makes >sense to place them last, whenever possible (accounting matches >excluded, of course). In other words, do this: > >-A fw2net -m condition --condition allow_set2 --uid-owner 0 -m set >--match-set set1 src -m set --match-set set2 dst -m owner -j ACCEPT > >This will speed up the traversal of rules. Currently, it seems that >ipset matches "enjoy" the highest priority and are placed first in a >given iptables rule. I think they need to be defined to have less >priority than that of "owner" and "condition" matches to start with.I''ll take a look. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
Tom Eastep wrote:> 4.5.17 RC 1 is now available for testing. > > Changes since Beta 3: > > 1) A ''local'' zone now works correctly with ''destonly'' specified on the > loopback device. >ERROR: The local zone may only me assigned to ''lo'' /etc/shorewall/interfaces Says who, exactly? I should be able to assign the local zone to whichever network adapter I damn well please! ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
On 5/25/13 6:35 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote:> >Tom Eastep wrote: >> 4.5.17 RC 1 is now available for testing. >> >> Changes since Beta 3: >> >> 1) A ''local'' zone now works correctly with ''destonly'' specified on the >> loopback device. >> >ERROR: The local zone may only me assigned to ''lo'' >/etc/shorewall/interfaces > >Says who, exactly? I should be able to assign the local zone to >whichever network adapter I damn well please!As the Rolling Stones say, you can''t always get what you want. Especially when you ask like that. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
On 05/25/2013 11:57 AM, Tom Eastep wrote:> On 5/25/13 11:00 AM, "Dash Four" <mr.dash.four@googlemail.com> wrote:>> One optimisation bug: >> >> rules >> ~~~~~ >> ACCEPT $FW:+set1 net:+set2 ; user:root, switch:allow_set2=0 >> >> produces >> >> -A fw2net -m set --match-set set1 src -m set --match-set set2 dst -m >> owner --uid-owner 0 -m condition --condition allow_set2 -j ACCEPT >> >> It makes sense for the "condition" match, as well as owner and possibly >> any other match, bar nfacct matches, to have higher priority and be >> placed before the ipset matches, since they 1. could be checked quicker >> than ipset matches; and 2. there is no point checking the set matches if >> the "condition" match isn''t satisfied. >> >> ipset matches are the most resource-consuming operations, so it makes >> sense to place them last, whenever possible (accounting matches >> excluded, of course). In other words, do this: >> >> -A fw2net -m condition --condition allow_set2 --uid-owner 0 -m set >> --match-set set1 src -m set --match-set set2 dst -m owner -j ACCEPT >> >> This will speed up the traversal of rules. Currently, it seems that >> ipset matches "enjoy" the highest priority and are placed first in a >> given iptables rule. I think they need to be defined to have less >> priority than that of "owner" and "condition" matches to start with. > > I''ll take a look.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 \________________________________________________ ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
Tom Eastep wrote:> On 5/25/13 6:35 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote: > >> Tom Eastep wrote: >> >>> 4.5.17 RC 1 is now available for testing. >>> >>> Changes since Beta 3: >>> >>> 1) A ''local'' zone now works correctly with ''destonly'' specified on the >>> loopback device. >>> >>> >> ERROR: The local zone may only me assigned to ''lo'' >> /etc/shorewall/interfaces >> >> Says who, exactly? I should be able to assign the local zone to >> whichever network adapter I damn well please! >> > > As the Rolling Stones say, you can''t always get what you want. Especially > when you ask like that. >Well, in this case, I will have to use start/started to manually delete all the <all>2local and local2<all> crap shorewall placed in my own firewall and be done with it and not bother with this next-to-useless "local" zone option at all. If it was just the loopback interface your recent changes have targeted, then, maybe, just maybe, you should have called this option "loopback" instead to make it clearer. Personally, I won''t be using this, as your "local" solution is neither here nor there - my intention was, and always has been, to isolate the local zone from all other zones I have defined (be it based on the loopback interface or lo:X interfaces, or some other interfaces bound to the 127.x.x.x address I have defined in advance) and exercise a degree of control over its traffic. Currently, your "local" solution falls well short of that. ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
On 05/26/2013 08:22 AM, Dash Four wrote:> > > Tom Eastep wrote: >> On 5/25/13 6:35 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote: >> >>> Tom Eastep wrote: >>> >>>> 4.5.17 RC 1 is now available for testing. >>>> >>>> Changes since Beta 3: >>>> >>>> 1) A ''local'' zone now works correctly with ''destonly'' specified on the >>>> loopback device. >>>> >>>> >>> ERROR: The local zone may only me assigned to ''lo'' >>> /etc/shorewall/interfaces >>> >>> Says who, exactly? I should be able to assign the local zone to >>> whichever network adapter I damn well please! >>> >> >> As the Rolling Stones say, you can''t always get what you want. Especially >> when you ask like that. >> > Well, in this case, I will have to use start/started to manually delete > all the <all>2local and local2<all> crap shorewall placed in my own > firewall and be done with it and not bother with this next-to-useless > "local" zone option at all. > > If it was just the loopback interface your recent changes have targeted, > then, maybe, just maybe, you should have called this option "loopback" > instead to make it clearer. > > Personally, I won''t be using this, as your "local" solution is neither > here nor there - my intention was, and always has been, to isolate the > local zone from all other zones I have defined (be it based on the > loopback interface or lo:X interfaces, or some other interfaces bound to > the 127.x.x.x address I have defined in advance) and exercise a degree > of control over its traffic. Currently, your "local" solution falls well > short of that.The lo:X thingies are not interfaces; they are simply labeled addresses on interface ''lo''. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
On 05/26/2013 08:25 AM, Tom Eastep wrote:> On 05/26/2013 08:22 AM, Dash Four wrote: >> >> >> Tom Eastep wrote: >>> On 5/25/13 6:35 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote: >>> >>>> Tom Eastep wrote: >>>> >>>>> 4.5.17 RC 1 is now available for testing. >>>>> >>>>> Changes since Beta 3: >>>>> >>>>> 1) A ''local'' zone now works correctly with ''destonly'' specified on the >>>>> loopback device. >>>>> >>>>> >>>> ERROR: The local zone may only me assigned to ''lo'' >>>> /etc/shorewall/interfaces >>>> >>>> Says who, exactly? I should be able to assign the local zone to >>>> whichever network adapter I damn well please! >>>> >>> >>> As the Rolling Stones say, you can''t always get what you want. Especially >>> when you ask like that. >>> >> Well, in this case, I will have to use start/started to manually delete >> all the <all>2local and local2<all> crap shorewall placed in my own >> firewall and be done with it and not bother with this next-to-useless >> "local" zone option at all. >> >> If it was just the loopback interface your recent changes have targeted, >> then, maybe, just maybe, you should have called this option "loopback" >> instead to make it clearer. >> >> Personally, I won''t be using this, as your "local" solution is neither >> here nor there - my intention was, and always has been, to isolate the >> local zone from all other zones I have defined (be it based on the >> loopback interface or lo:X interfaces, or some other interfaces bound to >> the 127.x.x.x address I have defined in advance) and exercise a degree >> of control over its traffic. Currently, your "local" solution falls well >> short of that. > > The lo:X thingies are not interfaces; they are simply labeled addresses > on interface ''lo''. >My point is that the iptables match ''-i dev:1'' never matches, when ''dev:1'' is a ''virtual'' interface on interface ''dev''. What I can do is allow multiple local zones where nesting is allowed between local zones. That allows rather fine-grained control over $FW->$FW traffic based on zones. Example: The public IP addresses on my gateway are in 70.90.191.120/29. All policies involving fw and the local zones are ACCEPT and FASTACCEPT=Yes. /etc/shorewall/zones: local local local1:local local #local1 is nested in local /etc/shorewall/interfaces: local lo /etc/shorewall/hosts: local1 lo:70.90.191.120/29 This generates the following: :INPUT DROP [0:0] :OUTPUT DROP [0:0] ... :fw-local1 - [0:0] ... :lo_in - [0:0] :lo_out - [0:0] ... :local1-fw - [0:0] ... -A INPUT -i lo -j lo_in ... -A OUTPUT -o lo -j lo_out ... -A fw-local1 -m conntrack --ctstate RELATED -j +fw-local1 -A fw-local1 -j ACCEPT ... -A lo_in -s 70.90.191.120/29 -j local1-fw -A lo_in -m conntrack --ctstate RELATED -j +local-fw -A lo_in -m conntrack --ctstate UNTRACKED -j ~comb0 -A lo_in -j ACCEPT -A lo_out -d 70.90.191.120/29 -j fw-local1 -A lo_out -m conntrack --ctstate RELATED -j +fw-local -A lo_out -j ACCEPT ... -A local1-fw -m conntrack --ctstate RELATED -j +local1-fw -A local1-fw -m conntrack --ctstate UNTRACKED -j ~comb0 -A local1-fw -j ACCEPT So when I ''ping 70.90.191.121'' from the firewall itself, I see: Chain fw-local1 (1 references) pkts bytes target prot opt in out source destination 0 0 +fw-local1 all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED 1 84 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 Chain local1-fw (1 references) pkts bytes target prot opt in out source destination 0 0 +local1-fw all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED 0 0 ~comb0 all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate UNTRACKED 10 840 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
Tom Eastep wrote:> On 05/26/2013 08:25 AM, Tom Eastep wrote: > >> On 05/26/2013 08:22 AM, Dash Four wrote: >> >>> Tom Eastep wrote: >>> >>>> On 5/25/13 6:35 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote: >>>> >>>> >>>>> Tom Eastep wrote: >>>>> >>>>> >>>>>> 4.5.17 RC 1 is now available for testing. >>>>>> >>>>>> Changes since Beta 3: >>>>>> >>>>>> 1) A ''local'' zone now works correctly with ''destonly'' specified on the >>>>>> loopback device. >>>>>> >>>>>> >>>>>> >>>>> ERROR: The local zone may only me assigned to ''lo'' >>>>> /etc/shorewall/interfaces >>>>> >>>>> Says who, exactly? I should be able to assign the local zone to >>>>> whichever network adapter I damn well please! >>>>> >>>>> >>>> As the Rolling Stones say, you can''t always get what you want. Especially >>>> when you ask like that. >>>> >>>> >>> Well, in this case, I will have to use start/started to manually delete >>> all the <all>2local and local2<all> crap shorewall placed in my own >>> firewall and be done with it and not bother with this next-to-useless >>> "local" zone option at all. >>> >>> If it was just the loopback interface your recent changes have targeted, >>> then, maybe, just maybe, you should have called this option "loopback" >>> instead to make it clearer. >>> >>> Personally, I won''t be using this, as your "local" solution is neither >>> here nor there - my intention was, and always has been, to isolate the >>> local zone from all other zones I have defined (be it based on the >>> loopback interface or lo:X interfaces, or some other interfaces bound to >>> the 127.x.x.x address I have defined in advance) and exercise a degree >>> of control over its traffic. Currently, your "local" solution falls well >>> short of that. >>> >> The lo:X thingies are not interfaces; they are simply labeled addresses >> on interface ''lo''. >> >> > > My point is that the iptables match ''-i dev:1'' never matches, when > ''dev:1'' is a ''virtual'' interface on interface ''dev''. > > What I can do is allow multiple local zones where nesting is allowed > between local zones. That allows rather fine-grained control over > $FW->$FW traffic based on zones. >The point I was trying to make is for you to drop the restriction on ''lo''. As I already pointed out, I could have other "local" devices within the 127.x.x.x range, not just ''lo''. I don''t mind having to shoe-horn virtual devices (lo:X for example) into the same device/zone either - that''s fine by me, no problem. ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
> The point I was trying to make is for you to drop the restriction on > ''lo''. As I already pointed out, I could have other "local" devices > within the 127.x.x.x range, not just ''lo''. I don''t mind having to > shoe-horn virtual devices (lo:X for example) into the same device/zone > either - that''s fine by me, no problem.It also opens the possibility for me to use more than one device for the "local" zone as well - with just "lo" currently allowed, I cannot do that. ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
On 5/26/13 10:42 AM, "Dash Four" <mr.dash.four@googlemail.com> wrote:> >> The point I was trying to make is for you to drop the restriction on >> ''lo''. As I already pointed out, I could have other "local" devices >> within the 127.x.x.x range, not just ''lo''. I don''t mind having to >> shoe-horn virtual devices (lo:X for example) into the same device/zone >> either - that''s fine by me, no problem. >It also opens the possibility for me to use more than one device for the >"local" zone as well - with just "lo" currently allowed, I cannot do that.What''s the point? Are you going to modify the ''local'' routing table to use these other devices? How does that work? -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
Tom Eastep wrote:> On 5/26/13 10:42 AM, "Dash Four" <mr.dash.four@googlemail.com> wrote: > > >>> The point I was trying to make is for you to drop the restriction on >>> ''lo''. As I already pointed out, I could have other "local" devices >>> within the 127.x.x.x range, not just ''lo''. I don''t mind having to >>> shoe-horn virtual devices (lo:X for example) into the same device/zone >>> either - that''s fine by me, no problem. >>> >> It also opens the possibility for me to use more than one device for the >> "local" zone as well - with just "lo" currently allowed, I cannot do that. >> > > What''s the point? Are you going to modify the ''local'' routing table to use > these other devices? How does that work? >We''ve got three type of embedded devices, which attach themselves to a "main" machine (a PC or a server) via the usb port and are able to send/receive data in this way. The usb port acts as usbX interface and for all intents and purposes the whole thing is considered to be part of the "main" machine/server. The actual usbX devices are created/initiated via the standard Linux tools in existence (there is already a set of kernel modules for this type of device in the main Linux stack) and that is how we use these and have been doing for some time. ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
On 5/26/13 11:21 AM, "Dash Four" <mr.dash.four@googlemail.com> wrote:> >Tom Eastep wrote: >> On 5/26/13 10:42 AM, "Dash Four" <mr.dash.four@googlemail.com> wrote: >> >> >>>> The point I was trying to make is for you to drop the restriction on >>>> ''lo''. As I already pointed out, I could have other "local" devices >>>> within the 127.x.x.x range, not just ''lo''. I don''t mind having to >>>> shoe-horn virtual devices (lo:X for example) into the same device/zone >>>> either - that''s fine by me, no problem. >>>> >>> It also opens the possibility for me to use more than one device for >>>the >>> "local" zone as well - with just "lo" currently allowed, I cannot do >>>that. >>> >> >> What''s the point? Are you going to modify the ''local'' routing table to >>use >> these other devices? How does that work? >> >We''ve got three type of embedded devices, which attach themselves to a >"main" machine (a PC or a server) via the usb port and are able to >send/receive data in this way. > >The usb port acts as usbX interface and for all intents and purposes the >whole thing is considered to be part of the "main" machine/server. The >actual usbX devices are created/initiated via the standard Linux tools >in existence (there is already a set of kernel modules for this type of >device in the main Linux stack) and that is how we use these and have >been doing for some time.Okay -- so it sounds like you really want the ''local'' interface option for these usbX interfaces to inhibit external interaction and nothing else, right? -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
Tom Eastep wrote:> On 5/26/13 11:21 AM, "Dash Four" <mr.dash.four@googlemail.com> wrote >> Tom Eastep wrote: >> >>> On 5/26/13 10:42 AM, "Dash Four" <mr.dash.four@googlemail.com> wrote: >>> >>> >>> >>>>> The point I was trying to make is for you to drop the restriction on >>>>> ''lo''. As I already pointed out, I could have other "local" devices >>>>> within the 127.x.x.x range, not just ''lo''. I don''t mind having to >>>>> shoe-horn virtual devices (lo:X for example) into the same device/zone >>>>> either - that''s fine by me, no problem. >>>>> >>>>> >>>> It also opens the possibility for me to use more than one device for >>>> the >>>> "local" zone as well - with just "lo" currently allowed, I cannot do >>>> that. >>>> >>>> >>> What''s the point? Are you going to modify the ''local'' routing table to >>> use >>> these other devices? How does that work? >>> >>> >> We''ve got three type of embedded devices, which attach themselves to a >> "main" machine (a PC or a server) via the usb port and are able to >> send/receive data in this way. >> >> The usb port acts as usbX interface and for all intents and purposes the >> whole thing is considered to be part of the "main" machine/server. The >> actual usbX devices are created/initiated via the standard Linux tools >> in existence (there is already a set of kernel modules for this type of >> device in the main Linux stack) and that is how we use these and have >> been doing for some time. >> > > Okay -- so it sounds like you really want the ''local'' interface option for > these usbX interfaces to inhibit external interaction and nothing else, > right? >As I already mentioned, I need the restriction to use only a "lo" interface for the "local" zones to go away. I need to be able to define *any* device (or devices) belonging to a particular zone with the "local" option. The meaning of the "local" option is to allow communication only from/to the firewall itself and nothing else (inter-zone communication cannot happen and shorewall should not be creating all these local2<all> and <all>2local chains). However, the local2local zone traffic should also be allowed, if more than one interface exists for a zone with that "local" option specified - what I have in mind is traffic between "lo" and "usbX" for example - this needs to be handled, I presume, in a local2local zone. ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
On 5/26/13 12:03 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote:> >Tom Eastep wrote: >> On 5/26/13 11:21 AM, "Dash Four" <mr.dash.four@googlemail.com> wrote >>> Tom Eastep wrote: >>> >>>> On 5/26/13 10:42 AM, "Dash Four" <mr.dash.four@googlemail.com> wrote: >>>> >>>> >>>> >>>>>> The point I was trying to make is for you to drop the restriction on >>>>>> ''lo''. As I already pointed out, I could have other "local" devices >>>>>> within the 127.x.x.x range, not just ''lo''. I don''t mind having to >>>>>> shoe-horn virtual devices (lo:X for example) into the same >>>>>>device/zone >>>>>> either - that''s fine by me, no problem. >>>>>> >>>>>> >>>>> It also opens the possibility for me to use more than one device for >>>>> the >>>>> "local" zone as well - with just "lo" currently allowed, I cannot do >>>>> that. >>>>> >>>>> >>>> What''s the point? Are you going to modify the ''local'' routing table to >>>> use >>>> these other devices? How does that work? >>>> >>>> >>> We''ve got three type of embedded devices, which attach themselves to a >>> "main" machine (a PC or a server) via the usb port and are able to >>> send/receive data in this way. >>> >>> The usb port acts as usbX interface and for all intents and purposes >>>the >>> whole thing is considered to be part of the "main" machine/server. The >>> actual usbX devices are created/initiated via the standard Linux tools >>> in existence (there is already a set of kernel modules for this type of >>> device in the main Linux stack) and that is how we use these and have >>> been doing for some time. >>> >> >> Okay -- so it sounds like you really want the ''local'' interface option >>for >> these usbX interfaces to inhibit external interaction and nothing else, >> right? >> >As I already mentioned, I need the restriction to use only a "lo" >interface for the "local" zones to go away. I need to be able to define >*any* device (or devices) belonging to a particular zone with the >"local" option. > >The meaning of the "local" option is to allow communication only from/to >the firewall itself and nothing else (inter-zone communication cannot >happen and shorewall should not be creating all these local2<all> and ><all>2local chains). > >However, the local2local zone traffic should also be allowed, if more >than one interface exists for a zone with that "local" option specified >- what I have in mind is traffic between "lo" and "usbX" for example - >this needs to be handled, I presume, in a local2local zone.There can be no interaction between a local zone defined on ''lo'' and a local zone on another interface; there are no routing scenarios where traffic flows through ''lo'' and in or out of another interface. That is why I want to have separate abstractions for the two cases. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
Tom Eastep wrote:> On 5/26/13 12:03 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote: > >> Tom Eastep wrote: >> >>> On 5/26/13 11:21 AM, "Dash Four" <mr.dash.four@googlemail.com> wrote >>> >>>> Tom Eastep wrote: >>>> >>>> >>>>> On 5/26/13 10:42 AM, "Dash Four" <mr.dash.four@googlemail.com> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>>> The point I was trying to make is for you to drop the restriction on >>>>>>> ''lo''. As I already pointed out, I could have other "local" devices >>>>>>> within the 127.x.x.x range, not just ''lo''. I don''t mind having to >>>>>>> shoe-horn virtual devices (lo:X for example) into the same >>>>>>> device/zone >>>>>>> either - that''s fine by me, no problem. >>>>>>> >>>>>>> >>>>>>> >>>>>> It also opens the possibility for me to use more than one device for >>>>>> the >>>>>> "local" zone as well - with just "lo" currently allowed, I cannot do >>>>>> that. >>>>>> >>>>>> >>>>>> >>>>> What''s the point? Are you going to modify the ''local'' routing table to >>>>> use >>>>> these other devices? How does that work? >>>>> >>>>> >>>>> >>>> We''ve got three type of embedded devices, which attach themselves to a >>>> "main" machine (a PC or a server) via the usb port and are able to >>>> send/receive data in this way. >>>> >>>> The usb port acts as usbX interface and for all intents and purposes >>>> the >>>> whole thing is considered to be part of the "main" machine/server. The >>>> actual usbX devices are created/initiated via the standard Linux tools >>>> in existence (there is already a set of kernel modules for this type of >>>> device in the main Linux stack) and that is how we use these and have >>>> been doing for some time. >>>> >>>> >>> Okay -- so it sounds like you really want the ''local'' interface option >>> for >>> these usbX interfaces to inhibit external interaction and nothing else, >>> right? >>> >>> >> As I already mentioned, I need the restriction to use only a "lo" >> interface for the "local" zones to go away. I need to be able to define >> *any* device (or devices) belonging to a particular zone with the >> "local" option. >> >> The meaning of the "local" option is to allow communication only from/to >> the firewall itself and nothing else (inter-zone communication cannot >> happen and shorewall should not be creating all these local2<all> and >> <all>2local chains). >> >> However, the local2local zone traffic should also be allowed, if more >> than one interface exists for a zone with that "local" option specified >> - what I have in mind is traffic between "lo" and "usbX" for example - >> this needs to be handled, I presume, in a local2local zone. >> > > There can be no interaction between a local zone defined on ''lo'' and a > local zone on another interface; there are no routing scenarios where > traffic flows through ''lo'' and in or out of another interface. That is why > I want to have separate abstractions for the two cases. >Well, in that case you need to call the first option "loopback" (because that''s what this really is, it isn''t "local") and the second "local". Both should only have fw2<X> and <X>2fw chains (X being the loopback and local zones) and in addition, for the local zone, there should also be local2local chain in case where there is more than one interface defined for that local zone. ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
On 5/26/13 1:39 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote:> >Tom Eastep wrote: >> On 5/26/13 12:03 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote: >> >>> Tom Eastep wrote: >>> >>>> On 5/26/13 11:21 AM, "Dash Four" <mr.dash.four@googlemail.com> wrote >>>> >>>>> Tom Eastep wrote: >>>>> >>>>> >>>>>> On 5/26/13 10:42 AM, "Dash Four" <mr.dash.four@googlemail.com> >>>>>>wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>> The point I was trying to make is for you to drop the restriction >>>>>>>>on >>>>>>>> ''lo''. As I already pointed out, I could have other "local" devices >>>>>>>> within the 127.x.x.x range, not just ''lo''. I don''t mind having to >>>>>>>> shoe-horn virtual devices (lo:X for example) into the same >>>>>>>> device/zone >>>>>>>> either - that''s fine by me, no problem. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> It also opens the possibility for me to use more than one device >>>>>>>for >>>>>>> the >>>>>>> "local" zone as well - with just "lo" currently allowed, I cannot >>>>>>>do >>>>>>> that. >>>>>>> >>>>>>> >>>>>>> >>>>>> What''s the point? Are you going to modify the ''local'' routing table >>>>>>to >>>>>> use >>>>>> these other devices? How does that work? >>>>>> >>>>>> >>>>>> >>>>> We''ve got three type of embedded devices, which attach themselves to >>>>>a >>>>> "main" machine (a PC or a server) via the usb port and are able to >>>>> send/receive data in this way. >>>>> >>>>> The usb port acts as usbX interface and for all intents and purposes >>>>> the >>>>> whole thing is considered to be part of the "main" machine/server. >>>>>The >>>>> actual usbX devices are created/initiated via the standard Linux >>>>>tools >>>>> in existence (there is already a set of kernel modules for this type >>>>>of >>>>> device in the main Linux stack) and that is how we use these and have >>>>> been doing for some time. >>>>> >>>>> >>>> Okay -- so it sounds like you really want the ''local'' interface option >>>> for >>>> these usbX interfaces to inhibit external interaction and nothing >>>>else, >>>> right? >>>> >>>> >>> As I already mentioned, I need the restriction to use only a "lo" >>> interface for the "local" zones to go away. I need to be able to define >>> *any* device (or devices) belonging to a particular zone with the >>> "local" option. >>> >>> The meaning of the "local" option is to allow communication only >>>from/to >>> the firewall itself and nothing else (inter-zone communication cannot >>> happen and shorewall should not be creating all these local2<all> and >>> <all>2local chains). >>> >>> However, the local2local zone traffic should also be allowed, if more >>> than one interface exists for a zone with that "local" option specified >>> - what I have in mind is traffic between "lo" and "usbX" for example - >>> this needs to be handled, I presume, in a local2local zone. >>> >> >> There can be no interaction between a local zone defined on ''lo'' and a >> local zone on another interface; there are no routing scenarios where >> traffic flows through ''lo'' and in or out of another interface. That is >>why >> I want to have separate abstractions for the two cases. >> >Well, in that case you need to call the first option "loopback" (because >that''s what this really is, it isn''t "local") and the second "local". > >Both should only have fw2<X> and <X>2fw chains (X being the loopback and >local zones) and in addition, for the local zone, there should also be >local2local chain in case where there is more than one interface defined >for that local zone.We''re on the same page. I''ve just about finished implementing exactly what you describe. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
Tom Eastep wrote:>> Well, in that case you need to call the first option "loopback" (because >> that''s what this really is, it isn''t "local") and the second "local". >> >> Both should only have fw2<X> and <X>2fw chains (X being the loopback and >> local zones) and in addition, for the local zone, there should also be >> local2local chain in case where there is more than one interface defined >> for that local zone. >> > > We''re on the same page. I''ve just about finished implementing exactly what > you describe. >Forgot to add something which should be pretty obvious given what was discussed earlier - neither options should have the lo-only restriction. ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
On 5/26/13 3:16 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote:> >Tom Eastep wrote: >>> Well, in that case you need to call the first option "loopback" >>>(because >>> that''s what this really is, it isn''t "local") and the second "local". >>> >>> Both should only have fw2<X> and <X>2fw chains (X being the loopback >>>and >>> local zones) and in addition, for the local zone, there should also be >>> local2local chain in case where there is more than one interface >>>defined >>> for that local zone. >>> >> >> We''re on the same page. I''ve just about finished implementing exactly >>what >> you describe. >> >Forgot to add something which should be pretty obvious given what was >discussed earlier - neither options should have the lo-only restriction.Loopback will still have that restriction. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
Tom Eastep wrote:> On 5/26/13 3:16 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote: > > >> Tom Eastep wrote: >> >>>> Well, in that case you need to call the first option "loopback" >>>> (because >>>> that''s what this really is, it isn''t "local") and the second "local". >>>> >>>> Both should only have fw2<X> and <X>2fw chains (X being the loopback >>>> and >>>> local zones) and in addition, for the local zone, there should also be >>>> local2local chain in case where there is more than one interface >>>> defined >>>> for that local zone. >>>> >>>> >>> We''re on the same page. I''ve just about finished implementing exactly >>> what >>> you describe. >>> >>> >> Forgot to add something which should be pretty obvious given what was >> discussed earlier - neither options should have the lo-only restriction. >> > > Loopback will still have that restriction. >What happens when I only have one device in a zone called "local" with the "local" option set? If I am to assume that shorewall will do the right thing and eliminate the local2local chain, then what would be the difference between that zone and the "loopback" zone? ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
On 5/26/13 4:15 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote:> > >Tom Eastep wrote: >> On 5/26/13 3:16 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote: >> >> >>> Tom Eastep wrote: >>> >>>>> Well, in that case you need to call the first option "loopback" >>>>> (because >>>>> that''s what this really is, it isn''t "local") and the second "local". >>>>> >>>>> Both should only have fw2<X> and <X>2fw chains (X being the loopback >>>>> and >>>>> local zones) and in addition, for the local zone, there should also >>>>>be >>>>> local2local chain in case where there is more than one interface >>>>> defined >>>>> for that local zone. >>>>> >>>>> >>>> We''re on the same page. I''ve just about finished implementing exactly >>>> what >>>> you describe. >>>> >>>> >>> Forgot to add something which should be pretty obvious given what was >>> discussed earlier - neither options should have the lo-only >>>restriction. >>> >> >> Loopback will still have that restriction. >> >What happens when I only have one device in a zone called "local" with >the "local" option set? If I am to assume that shorewall will do the >right thing and eliminate the local2local chain, then what would be the >difference between that zone and the "loopback" zone?If you also have ''local1'' of type local, then you will have ''local12local'' and local2local1'' (since local zones can communicate with each other). They cannot, however, communicate with a loopback zone; only the firewall and vserver zones can do that (since vserver zones are sub-zones of $FW). -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
Tom Eastep wrote:> On 5/26/13 4:15 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote: > > >> Tom Eastep wrote: >> >>> On 5/26/13 3:16 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote: >>> >>> >>> >>>> Tom Eastep wrote: >>>> >>>> >>>>>> Well, in that case you need to call the first option "loopback" >>>>>> (because >>>>>> that''s what this really is, it isn''t "local") and the second "local". >>>>>> >>>>>> Both should only have fw2<X> and <X>2fw chains (X being the loopback >>>>>> and >>>>>> local zones) and in addition, for the local zone, there should also >>>>>> be >>>>>> local2local chain in case where there is more than one interface >>>>>> defined >>>>>> for that local zone. >>>>>> >>>>>> >>>>>> >>>>> We''re on the same page. I''ve just about finished implementing exactly >>>>> what >>>>> you describe. >>>>> >>>>> >>>>> >>>> Forgot to add something which should be pretty obvious given what was >>>> discussed earlier - neither options should have the lo-only >>>> restriction. >>>> >>>> >>> Loopback will still have that restriction. >>> >>> >> What happens when I only have one device in a zone called "local" with >> the "local" option set? If I am to assume that shorewall will do the >> right thing and eliminate the local2local chain, then what would be the >> difference between that zone and the "loopback" zone? >> > > If you also have ''local1'' of type local, then you will have ''local12local'' > and local2local1'' (since local zones can communicate with each other). >That''s not what I asked, is it? So I''ll repeat it again (cut-and-paste from my post above): What happens when I only have one device in a zone called "local" with the "local" option set? If I am to assume that shorewall will do the right thing and eliminate the local2local chain (question one), then what would be the difference between that zone and the "loopback" zone (question two)? ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
On 5/26/13 4:48 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote:> > >Tom Eastep wrote: >> On 5/26/13 4:15 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote: >> >> >>> Tom Eastep wrote: >>> >>>> On 5/26/13 3:16 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote: >>>> >>>> >>>> >>>>> Tom Eastep wrote: >>>>> >>>>> >>>>>>> Well, in that case you need to call the first option "loopback" >>>>>>> (because >>>>>>> that''s what this really is, it isn''t "local") and the second >>>>>>>"local". >>>>>>> >>>>>>> Both should only have fw2<X> and <X>2fw chains (X being the >>>>>>>loopback >>>>>>> and >>>>>>> local zones) and in addition, for the local zone, there should also >>>>>>> be >>>>>>> local2local chain in case where there is more than one interface >>>>>>> defined >>>>>>> for that local zone. >>>>>>> >>>>>>> >>>>>>> >>>>>> We''re on the same page. I''ve just about finished implementing >>>>>>exactly >>>>>> what >>>>>> you describe. >>>>>> >>>>>> >>>>>> >>>>> Forgot to add something which should be pretty obvious given what was >>>>> discussed earlier - neither options should have the lo-only >>>>> restriction. >>>>> >>>>> >>>> Loopback will still have that restriction. >>>> >>>> >>> What happens when I only have one device in a zone called "local" with >>> the "local" option set? If I am to assume that shorewall will do the >>> right thing and eliminate the local2local chain, then what would be the >>> difference between that zone and the "loopback" zone? >>> >> >> If you also have ''local1'' of type local, then you will have >>''local12local'' >> and local2local1'' (since local zones can communicate with each other). >> >That''s not what I asked, is it? So I''ll repeat it again (cut-and-paste >from my post above): > >What happens when I only have one device in a zone called "local" with >the "local" option set? If I am to assume that shorewall will do the >right thing and eliminate the local2local chain (question one), then >what would be the difference between that zone and the "loopback" zone >(question two)?All traffic sent from the firewall to the loopback zone will also be sent from the loopback zone to the firewall. In all of that traffic, the SOURCE and DESTINATION IP addresses will be addresses defined on interfaces on the firewall itself. That is a unique characteristic of the loopback device which is not shared by other interfaces. So the loopback zone has unique characteristics not shared by other ipvX zones. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may