After the changes from bug 288992, shorewall no longer successfully starts on boot with masq (NAT) configured. When I reboot my router (which runs shorewall and uses the masq file to define the NAT) shorewall fails to start. This causes a loss of ALL internet access from every PC on my network and requires me to log into the router via the console (to restart shorewall). Checking the console on the router shows this message: "ERROR: Unable to determine the routes through interface eth_lan" From the shorewall documentation: "ERROR: Unable to determine the routes through interface <interface> You have specified <interface> in the SUBNET column of /etc/shorewall/masq which means that Shorewall is supposed to determine the network(s) routed through that interface. To do that, Shorewall issues the command ip addr ls dev <interface> and that command failed. This usually means that you are trying to start Shorewall before the <interface> is brought up." Reproducible: Always Steps to Reproduce: 1. Install net-firewall/shorewall-perl-4.2.11.1 2. Configure masq in /etc/shorewall/masq 3. Add shorewall to default run level 4. Reboot 5. Observe console for error Actual Results: Shorewall fails to start on boot with masq (NAT) configured because the network devices have not come up yet. Expected Results: Shorewall should start, even if this means waiting for network devices to come up. This is a serious issue that affects anyone using shorewall to do NAT; I can not update any routers to recent version of shorewall without this issue being resolved.
From http://www1.shorewall.net/pub/shorewall/4.4/shorewall-4.4.11/releasenotes.txt : "Shorewall 4.4.10 includes a new 'Shorewall Init' package." This should address your issue but requires emerging ~.
This happened to me also. Additionally it took me nearly two hours to find the solution and describe it to the guy having physical access to the machine. Would it be possible to mark this package as unstable or even mask it? When installing a stable package I normally expect no errors like this or at least no errors which make a remote system completely unusable. From shorewall upgrade perspective their is no chance to find out about this error.
The bug for me was related to net-firewall/shorewall-common-4.2.11-r1 net-firewall/shorewall-perl-4.2.11.1
I hit the same problem. A workaround is to replace the SOURCE interface name (second column) of /etc/shorewall/masq with a network address and netmask (e.g. 192.168.1.0/24). It's also possible to use a comma-separated list if you have several subnets that need masquerading.
(In reply to comment #2) > This happened to me also. Additionally it took me nearly two hours to find the > solution and describe it to the guy having physical access to the machine. > > Would it be possible to mark this package as unstable or even mask it? When > installing a stable package I normally expect no errors like this or at least > no errors which make a remote system completely unusable. This would've been the right thing to do (and saved me a trip to the colo). I don't understand why after a critical regression is discovered nothing is done about it? Especially a regression with a firewall? > From shorewall upgrade perspective their is no chance to find out about this > error. Comes up pretty fast after a reboot.
Does this problem still exist with the newer versions?
