On Jun 1, 2013, at 7:22 AM, Dash Four <[email protected]> wrote:
> > Tom Eastep wrote: >> >> No -- from 'man shorewall-interfaces': >> >> ignore[=1] >> >> When specified, causes the generated script to ignore up/down events >> from Shorewall-init for this device. Additionally, the option exempts >> the interface from hairpin filtering. When '=1' is omitted, the ZONE >> column must contain '-' and ignore must be the only OPTION. >> >> Beginning with Shorewall 4.5.5, may be specified as 'ignore=1' which >> only causes the generated script to ignore up/down events from >> Shorewall-init; hairpin filtering is still applied. In this case, the >> above restrictions on the ZONE and OPTIONS columns are lifted. >> > Right, so if I want shorewall to "ignore" a specific interface, I need > to explicitly set its policies to "ACCEPT", would that be sufficient? Yes. Simply insert '$FW $FW ACCEPT' before your all+ all+ rule. > >>> In addition, I am getting two separate sets of warnings during startup: >>> >>> rules >>> ~~~~~ >>> SECTION RELATED >>> # MUST be last as *_DISPOSITION does not accept custom actions >>> IFLOG(-,log1,-,drop,DROP) all all >>> >>> gives me: >>> >>> WARNING: The rule(s) generated by this entry are unreachable and have >>> been discarded /etc/shorewall/action.ILOG (line 38) >>> from /etc/shorewall/action.IFLOG (line 31) >>> from /etc/shorewall/rules (line 106) >>> [...ad nauseum ...] >>> >>> then... >>> >>> WARNING: The SOURCE zone is off-firewall and the DEST zone is 'loopback' >>> /etc/shorewall/action.IFLOG (line 29) >>> from /etc/shorewall/tunnels (line EOF) >>> WARNING: The SOURCE zone is off-firewall and the DEST zone is 'loopback' >>> /etc/shorewall/action.IFLOG (line 31) >>> from /etc/shorewall/tunnels (line EOF) >>> [...again, ad nauseum ...] >>> >>> My /etc/shorewall/tunnels is empty. >>> >> >> I'll make no progress on that one without seeing the action.IFLOG >> definition. >> > IFLOG is the "inline" equivalent of FLOG, which I have posted before: > > action.FLOG > ~~~~~~~~~~~ > ?IF $1 > NFLOG($1,0,1) > ?ENDIF > ?IF $2 > ?SET @chain $3 ? $3 : " " > ?SET @disposition $4 ? $4 : " " > LOG:info(tcp_options,ip_options,macdecode,tcp_sequence,uid) > ?END IF > ?IF $5 > $5 > ?END IF I'll take a look. > >>> Also, despite my best efforts, the xt_CT helper messages have *not* gone >>> away, even though I've set net.netfilter_nf_conntrack_helper to 0 in my >>> sysctl.conf (I even tried setting this as a kernel parameter). >>> >> >> Do you have any 'notrack' rules? If not, you could simply omit xt_CT >> from your kernel configuration. >> > My "conntrack" is empty and I have explicitly disabled all helpers in my > kernel - that's the first thing I did in order to get rid of these > obnoxious messages. Try hacking your shorewall-init SysV init script to set netfilter_nf_conntrack_helper to zero during 'start' and see if that does the trick. If so, I can provide an option to do the same. -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 \________________________________________________ ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 _______________________________________________ Shorewall-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-devel
