I had problems yesterday when two servers went down in a data centre due to power problems. The servers are both KVM hosts which run shorewall to direct traffic to the VMs. In each case. traffic did not get to the VMs after the restart. One server runs version shorewall 4.4.26.1 on Ubuntu 12.04.4 and the other runs shorewall version 4.5.21.6 on Ubuntu 14.04 LTS I was able to do a couple of reboots on the server running shorewall 4.4.26.1 this morning and what I've seen is that when shorewall starts in run level S (which is Ubuntu standard) then running iptables -L after a restart seems to show the desired confguration - however, you cannot connect to the VMs from the outside world. When I moved the shorewall start script to run level 2, behaviour is as expected and desired. Capturing the output of iptables -L in both cases, I found the following extra rules when shorewall started in run level S Chain INPUT (policy DROP) target prot opt source destination ACCEPT udp -- anywhere anywhere udp dpt:domain ACCEPT tcp -- anywhere anywhere tcp dpt:domain ACCEPT udp -- anywhere anywhere udp dpt:bootps ACCEPT tcp -- anywhere anywhere tcp dpt:bootps Chain FORWARD (policy DROP) target prot opt source destination ACCEPT all -- anywhere 192.168.1.0/24 state RELATED,ESTABLISHED ACCEPT all -- 192.168.1.0/24 anywhere ACCEPT all -- anywhere anywhere REJECT all -- anywhere anywhere reject-with icmp-port-unreachable REJECT all -- anywhere anywhere reject-with icmp-port-unreachable As the VMs run with 192.168.1.0/24 addresses these rules in FORWARD are less than helpful. Any ideas as to why they are appearing there when run in run level S but not when run in run level 2? Kindest regards, Niall O Broin ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk