Tom Eastep wrote: > On 5/26/13 12:03 PM, "Dash Four" <[email protected]> wrote: > >> Tom Eastep wrote: >> >>> On 5/26/13 11:21 AM, "Dash Four" <[email protected]> wrote >>> >>>> Tom Eastep wrote: >>>> >>>> >>>>> On 5/26/13 10:42 AM, "Dash Four" <[email protected]> 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 _______________________________________________ Shorewall-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-devel
