On 5/9/11 5:10 AM, Mr Dash Four wrote: > >> It depends on whether you have Shorewall-init installed. Since you >> aren't beating on me about it's shortcomings, I assume that you have not >> installed that package. >> > Hehe, I am not that bad! You are right, though, I don't have it > installed - I just use shorewall. > >>> If I want to "cheat" (as I often do!) I could artificially "open" tun0, >>> start shorewall and then close that device. What would happen then (if >>> anything)? >>> >> >> Nothing, unless you are running Shorewall-init. >> > Maybe then shorewall shouldn't place such restrictions in this case - > the device traffic shaping rules are "ignored" by shorewall if the > device in question is not "present" (or up) and if that doesn't actually > matter (which I presumed was the case as I was able to "bypass" > shorewall completely and recreate those policies using iptables/tc > without the device being "present") this restriction should be removed. > > To "force" shorewall to apply my traffic shaping policies for this > device I currently have to run a separate program in rc.sysinit to bring > the tun0 device into existence (and up), then let shorewall do its work, > after which I close the device in rc.local. > > If there is no need for this restriction, then it should be removed.
Let's be clear about what Shorewall can and cannot do when a device is down (not an exhaustive list but it covers TC and policy routing). a) tcrules with the device specified in the DEST column *can* be applied. b) tcrules with the device specified in the SOURCE column *can* be applied *except* when the rule is in the POSTROUTING chain. That's because iptables/netfilter doesn't support -i in the POSTROUTING chain so Shorewall has to use the routing table to construct the corresponding -s list. c) tcdevices and tcclasses *cannot* be defined - tc/kernel restriction. d) Policy routing (providers file) *cannot* be defined - iproute/kernel restriction. So, contrary to your assertions, Shorewall does not impose capricious restrictions on such operations. These restrictions are, in fact, why shorewall-init was introduced. The general idea is this: a) You define these transient interfaces as 'optional' in /etc/shorewall/interfaces. b) You install and configure shorewall-init. Shorewall-init installs ifup/ifdown scripts which are triggered each time that an interface goes up or down. When an 'optional' interface goes up or down, a fast restart (/var/lib/shorewall/firewall restart) is done to adjust the configuration accordingly. There is also a 'required' interface option. When a 'required' interface comes up, an attempt is made to start the firewall (/var/lib/shorewall/firewall start). When a 'required' interface goes down, the firewall is stopped (/var/lib/shorewall/firewall stop). /var/lib/shorewall/firewall is the script which performed the last successful start/restart operation. Running that script directly bypasses the complation phase. -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 \________________________________________________
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
