On 05/16/2013 06:08 AM, Dash Four wrote: > > Tom Eastep wrote: >> Thank you for testing, >> > Some real nasties I found in this beta: > > 1. shorewall-init/shorewall compile issue: during bootup, my "firewall" > file is compiled by shorewall-init (no interfaces are up/running at this > point) and then the OS starts bringing up my network interfaces one by > one, thus, executing ifup-local, which uses the newly-compiled > "firewall". After that is complete, shorewall, as a service, does not > start as it "sees" that it has already started and running. So far, so > good. > > The problem with this is that I cannot route *any* traffic between > interfaces - I can pass traffic only on the interfaces which are > directly connected to each other. For example, if I have one interface > connected to my "green" subnet, I can send and receive traffic through > this net via the firewall - no problem, but when I try to reach a > different subnet, which is on another interface on the firewall, I can't > until I manually run "shorewall reload", at which point everything > appears normal. > > I checked the packet counts for the relevant FORWARD chain - nada, > nothing passes through. I checked the routing - again, there doesn't > seem to be a problem as the routing entries are *exactly* the same > before and after I run "shorewall reload". I also check the ARP entries > and there doesn't seem to be a problem there either. > > My gut feeling tells me that when shorewall is bringing up my firewall > interface by interface, it misses parts of the firewall script, which > would normally run when I execute "shorewall start/reload" and these > parts appear to be vital for the routing between interfaces.
I'll need to see 'shorewall dump' output before and after the 'reload'. Note that 'shorewall-lite restart' on the firewall itself is more efficient than 'shorewall reload' on the admin system. > > 2. -V0 vs -v0. There appears to be a conflict between the two options in > shorewall-init. The shorewall-init init.d script takes the OPTIONS > variable from /etc/sysconfig/shorewall-init and uses it to run > "shorewall compile -c". On the other hand, ifupdown also uses the same > OPTIONS variable, but for both "shorewall compile" and > "/var/lib/shorewall/firewall". Now, if I specify "-V0" for my OPTIONS > parameter, that gets the OK from "/var/lib/shorewall/firewall", but > fails when it comes to "shorewall compile" and everything is screwed up! > > I've managed to get one ugly hack to prevent this - I renamed all > references to "OPTIONS" in "shorewall compile" to "SHOREWALL_OPTIONS" (I > also added this variable in "/etc/sysconfig/shorewall-init") in my > shorewall-init startup script, as well as ifupdown, but I think a better > solution can be found. I believe that the attached v_vs_V.patch is a better solution. > > 3. When "providers" is empty, "routes" is completely ignored by > shorewall. For example, if I only have "main" entries in "routes", which > is completely legitimate, these are ignored by shorewall on startup. Patch STANDARDROUTES.patch attached. > > 4. "all+ all+ DROP" generates a "fw2fw" chain, bound to my "lo" > interface no less - that should not happen. Why should the firewall zone be different from any other zone? If you don't want that behavior, add this policy before the one you quote: $FW $FW ACCEPT > > 5. I started getting these annoying group of "xt_CT: helper XXX not > found" crap messages appearing again in this beta! And no, I already > have HELPERS=none, as well as AUTOHELPERS=No in my shorewall.conf before > anyone asks. There were no changes to the module-handling code in Beta 2. Note that the xt_CT: messages will appear when a 'show capabilities' or 'dump' command is executed. > > 6. "shorewall update -D" does not check all files in /etc/shorewall: > > Compiling /etc/shorewall/interfaces... > WARNING: 'FORMAT' is deprecated in favor of '?FORMAT' - consider > running 'shorewall update -D' /etc/shorewall/interfaces (line 17) > > -bash-4.1# shorewall update -D > Updating... > Processing /etc/shorewall/params ... > Processing /etc/shorewall/shorewall.conf... > No update required to configuration file /etc/shorewall/shorewall.conf; > /etc/shorewall/shorewall.conf.bak not saved > > "interfaces" is not changed (I had to do that manually). Works for me. root@gateway:~# shorewall update -D Updating... Processing /etc/shorewall/params ... Processing /etc/shorewall/shorewall.conf... No update required to configuration file /etc/shorewall/shorewall.conf; /etc/shorewall/shorewall.conf.bak not saved Loading Modules... Converting 'FORMAT' and 'COMMENT' lines to compiler directives... File /etc/shorewall/interfaces updated - old file renamed /etc/shorewall/interfaces.bak Running /etc/shorewall/compile... Checking /etc/shorewall/zones... Checking /etc/shorewall/interfaces... -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 \________________________________________________
diff --git a/Shorewall-core/lib.cli b/Shorewall-core/lib.cli
index d378a43..87a6779 100644
--- a/Shorewall-core/lib.cli
+++ b/Shorewall-core/lib.cli
@@ -3421,8 +3421,16 @@ shorewall_cli() {
g_fast=Yes
option=${option#f}
;;
- v*)
- option=${option#v}
+ [vV]*)
+ case $option in
+ v*)
+ option=${option#v}
+ ;;
+ *)
+ option=${option#V}
+ ;;
+ esac
+
case $option in
-1*)
g_use_verbosity=-1
diff --git a/Shorewall/Perl/Shorewall/Providers.pm b/Shorewall/Perl/Shorewall/Providers.pm
index 0f14943..dc60e7e 100644
--- a/Shorewall/Perl/Shorewall/Providers.pm
+++ b/Shorewall/Perl/Shorewall/Providers.pm
@@ -1558,8 +1558,23 @@ sub setup_providers() {
emit "\nundo_routing";
emit "restore_default_route $config{USE_DEFAULT_RT}";
+ my $standard_routes = @{$providers{$main}{routes}} || @{$providers{$default}{routes}};
+
if ( $config{NULL_ROUTE_RFC1918} ) {
setup_null_routing;
+ emit "\nrun_ip route flush cache" unless $standard_routes;
+ }
+
+ if ( $standard_routes ) {
+ for my $provider ( qw/main default/ ) {
+ emit '';
+ emit qq(> \${VARDIR}/undo_${provider}_routing );
+ emit '';
+ emit $_ for @{$providers{$provider}{routes}};
+ emit '';
+ emit $_ for @{$providers{$provider}{rules}};
+ }
+
emit "\nrun_ip route flush cache";
}
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d
_______________________________________________ Shorewall-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-devel
