I''ve set up a VMware image with Ubuntu 10.04 Server x64 to test out shorewall-init. It has a single NIC with 2 VLANs. Both VLANs are optional in /etc/shorewall/interfaces, eth0 isn''t configured. The idea is that if any interface on the firewall is working then I''d like it to bring up everything it can so that I can get in and fix whatever might not come up. The docs suggested I could leave startup=0 in /etc/default/shorewall, but when I do the firewall does not start on a reboot of the server. If I ifdown/ifup one of the VLANs then the firewall starts as expected. There are some workarounds that do make the firewall start on a reboot: Setting startup=1 in /etc/default/shorewall Setting REQUIRE_INTERFACE=Yes (this one seems appropriate for my situation) Setting either of the interfaces to required instead of optional Dump attached if you need it Brad C ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
On 7/21/10 2:22 PM, Brad Clarke wrote:> > > Dump attached if you need it >A Shorewall STARTUP_LOG covering the time of the failures would be much more useful. -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 \________________________________________________ ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
On Wed, Jul 21, 2010 at 4:36 PM, Tom Eastep <teastep@shorewall.net> wrote:> On 7/21/10 2:22 PM, Brad Clarke wrote: > >> >> >> Dump attached if you need it >> > > A Shorewall STARTUP_LOG covering the time of the failures would be much > more useful.attached the log of a single failure (the whole log was pretty big already) ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
On 7/21/10 3:05 PM, Brad Clarke wrote:> On Wed, Jul 21, 2010 at 4:36 PM, Tom Eastep <teastep@shorewall.net> wrote: >> On 7/21/10 2:22 PM, Brad Clarke wrote: >> >>> >>> >>> Dump attached if you need it >>> >> >> A Shorewall STARTUP_LOG covering the time of the failures would be much >> more useful. > > > attached the log of a single failure (the whole log was pretty big already)So what I see here is that: a) Shorewall was started successfully b) There were several up/down events that resulted in no change c) Shorewall was stopped. To help make events clearer in the log, I''ve prepared the attached patch. Please: a) Apply the patch to /usr/share/shorewall/Shorewall/Zones b) Create a failure c) Forward the relevant part of the log. Thanks, -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 \________________________________________________ ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
On Thu, Jul 22, 2010 at 10:43 AM, Tom Eastep <teastep@shorewall.net> wrote:> So what I see here is that: > > a) Shorewall was started successfully > b) There were several up/down events that resulted in no change > c) Shorewall was stopped. > > To help make events clearer in the log, I''ve prepared the attached > patch. Please: > > a) Apply the patch to /usr/share/shorewall/Shorewall/Zones > b) Create a failure > c) Forward the relevant part of the log.The "bad" log is the one you asked for. For comparison, the "good" is what I see when I set REQUIRE_INTERFACE=Yes to make it work. Thanks, Brad C ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
On 7/22/10 10:03 AM, Brad Clarke wrote:> > The "bad" log is the one you asked for. For comparison, the "good" is > what I see when I set REQUIRE_INTERFACE=Yes to make it work. >With the ''bad'' configuration, please: a) shorewall compile foo b) Send me foo (privately) Thanks, -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 \________________________________________________ ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
On 7/22/10 10:33 AM, Tom Eastep wrote:> On 7/22/10 10:03 AM, Brad Clarke wrote: > >> >> The "bad" log is the one you asked for. For comparison, the "good" is >> what I see when I set REQUIRE_INTERFACE=Yes to make it work. >> > > With the ''bad'' configuration, please: > > a) shorewall compile foo > b) Send me foo (privately) >We have determined that the failure is do to upstart (the init daemon on recent Ubuntu releases). Upstart is an event-driven system initialization daemon that, as far as I can tell, only supports 1-way dependencies (startup of objects is triggered by events). Bringing up hardware-based NICs is triggered by udevd. This makes it impossible to insure that the firewall is placed in a safe state before network interfaces are started. Here is a log produced during startup of an SMP Lucid system having a single NIC (eth1): eth1 came up first and caused Shorewall to start. Jul 23 07:00:23 Shorewall up triggered by eth1 Jul 23 07:00:23 Shorewall attempting start Jul 23 07:00:23 Initializing... Jul 23 07:00:23 Loading Modules... Jul 23 07:00:24 Setting up Route Filtering... Jul 23 07:00:24 Setting up Martian Logging... Jul 23 07:00:24 Setting up Traffic Control... Jul 23 07:00:24 TC Device eth1 defined. Jul 23 07:00:24 Preparing iptables-restore input... Jul 23 07:00:24 Running /usr/local/sbin/iptables-restore... Jul 23 07:00:24 IPv4 Forwarding Disabled! Then lo came up; since lo is not hardware-based, it is brought up in the usual way (''ifup -a'') triggered by the networking initialization ''job'' (That''s upstart-speak for ''init script''). Jul 23 00:07:18 Shorewall up triggered by lo Jul 23 00:07:18 up on interface lo ignored Finally, the shorewall-init script was executed and stopped Shorewall. Jul 23 00:07:20 Stopping Shorewall.... Jul 23 00:07:20 Running /usr/local/sbin/iptables-restore... Jul 23 00:07:21 IPv4 Forwarding Disabled! Jul 23 00:07:21 done. The bottom line here is that system boot with upstart and shorewall-init is as likely to leave your firewall in the stopped state as it is in the started state. The above testing was done with Shorewall 4.4.12 Beta 1 (not yet released) which ensures that only one event is processed at a time; with earlier releases, the situation is more chaotic as events are handled in parallel. As a workaround, I''m recommending that you use ''startup=1'' in /etc/default/shorewall* to ensure that the firewall is finally placed in a ''started'' state (assuming that required interfaces are available). -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 \________________________________________________ ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
On 7/23/10 7:34 AM, Tom Eastep wrote:> The above testing was done with Shorewall 4.4.12 Beta 1 (not yet > released) which ensures that only one event is processed at a time; with > earlier releases, the situation is more chaotic as events are handled in > parallel. > > As a workaround, I''m recommending that you use ''startup=1'' in > /etc/default/shorewall* to ensure that the firewall is finally placed in > a ''started'' state (assuming that required interfaces are available). >Beta 1 is now uploaded and contains additional fixes for use with Upstart. The firewall is not guaranteed to be stopped prior to interfaces coming up but the firewall should always end up in the started state after boot (providing that the required interface(s) is (are) available). -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 \________________________________________________ ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first