On 5/26/13 1:39 PM, "Dash Four" <[email protected]> wrote:
> >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. 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 _______________________________________________ Shorewall-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-devel
