I've been running a Gentoo server with Shorewall on it for several years now (since version 1.2 if memory serves). Long story short I ended up finding that I had an /etc/shorewall/rfc1918 file leftover from 1.4, which I'll attach. It includes subnets that were generated from http://www.iana.org/assignments/ipv4-address-space that were marked as IANA reserved at the time. Obviously these have changed over the years, and the file was out of date. The real world issue that arose was that as subnets once reserved were allocated to the public IP space those users' packets were dropped as bogons. I've received infrequent reports from people unable to access sites on the machine over the past year or so, but wasn't able to get someone willing to help troubleshoot it (until now), and so wrote the reports off as local issues on the other end. Who knows how many users hit this issue but didn't report it. This issue is covered--and there is a warning about leaving an old /etc/shorewall/rfc1918 file--in the "Version >= 2.0.1" section here: http://www.shorewall.net/2.0/upgrade_issues.htm Clearly there is no issue with a clean install of the current Shorewall ebuilds, and so I wouldn't call this a bug in them per say, but perhaps it could be thought of as an upgrade issue with the 2.0.1 ebuild. As it has the potential to be so insidious on running production machine it would be nice if something could be done to help thwart it. As bogon subnets are now handled with a separate nobogons directive and matching file I would imagine user customization of rfc1918 would be very rare, and so perhaps it would be enough to print a warning if there is one in /etc/shorewall/? If nothing else this bug report can serve to document the issue for others. Thanks, Ian Reproducible: Always
Created attachment 115869 [details] The rfc1918 file left behind during the Shorewall upgrade path
(In reply to comment #0) > and so perhaps it would be enough > to print a warning if there is one in /etc/shorewall/? If nothing else this > bug report can serve to document the issue for others. Hmmm, the ebuild already does this... <snip> einfo "If you are upgrading to 3.2 you should at least:" einfo "* check that /etc/shorewall/rfc1918 does not contain non-RFC1918 private" einfo " addresses. If it does, rename it to rfc1918.old" </snip> Not really sure what else should we do.
