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. 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. 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. 4. "all+ all+ DROP" generates a "fw2fw" chain, bound to my "lo" interface no less - that should not happen. 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. 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). ------------------------------------------------------------------------------ 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
