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. -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
