From: Matthias S. <mat...@gm...> - 2012-07-06 18:00:24
|
Hi Tom, after disentangling the output from stdout and STARTUP_LOG I just realized that not two instances of Shorewall were interfering with itself, but the Shorewall and Iptables init script actually stepped on each other's toes. As a matter of fact, on my Debian system there is a pre-configured iptables script in /etc/rc2.d/ loading the "active", but empty ruleset. This was basically resetting all my settings which were loaded in the shorewall script located in /etc/rcS.d/. After disabling the iptables script and rebooting everything works perfectly now. Thank you for your help! Cheers, Matthias On 07/06/2012 07:25 PM, Tom Eastep wrote: > On 07/06/2012 10:15 AM, Matthias Sitte wrote: > >> I'd be happy to share more details if you tell me what you need >> (versions of which packages etc) to see why it works. It's a clean >> system with nothing but Shorewall installed. The config files for >> Shorewall are pretty simple. >> > > If you are able to create connections from the container to other hosts > with Shorewall started, you are not experiencing the problem that others > have run into. > >>> >>>> Of course, Shorewall should automatically start when rebooting. >>>> Making the appropriate changes to shorewall.conf and >>>> /etc/default/shorewall it should all be fine -- but it ain't >>>> somehow. > >> >> Anyway, right after the system comes up, `iptables -L' gives me empty lists: >> >> # iptables -L >> Chain INPUT (policy ACCEPT) >> target prot opt source destination >> >> Chain FORWARD (policy ACCEPT) >> target prot opt source destination >> >> Chain OUTPUT (policy ACCEPT) >> target prot opt source destination >> >> Stopping/starting Shorewall as described above makes it work nicely, though. > > Try placing that command in /etc/shorewall/started and see if that still > gives the same output when shorewall runs at boot (output should be in > /var/log/shorewall-init.log so long as stdout is being directed there). > > -Tom > |