After version bump of package from 5.0.6.1 to 5.0.6.2 the upstream changes seem to generate a defective ruleset for the shorewall6 component disrupting successfully whole ipv6 connectivity dropping every incoming and outgoing ipv6 packet. Solved the situation for me via a local overlay package just renaming the current ebuild to version 5.0.6.1 and installing the former revision. No further investigation done, seems a classic regression error in upstream package...
So you don't get an error message on shorewall6 restart. You are saying it must be something with the rules. In that case we will need the following generated files from your shorewall-5.0.6.1 and shorewall-5.0.6.2 installation: - /var/lib/shorewall6/firewall - /var/lib/shorewall6/.ip6tables-restore-input (check the headers of these files first to make sure that these files are really generated by the correct shorewall version) Are you experiencing your problems in a dockers container? Please post the requested information and double check your configuration. At the moment it is very unlikely that you are experiencing a defect introduced with shorewall-5.0.6.2.
(In reply to Thomas D. from comment #1) > So you don't get an error message on shorewall6 restart. You are saying it > must be something with the rules. Compiler is perfectly happy, no reports or anything that could raise awareness something is wrong... > Are you experiencing your problems in a dockers container? no, just a bare metal box.. > Please post the requested information and double check your configuration. > At the moment it is very unlikely that you are experiencing a defect > introduced with shorewall-5.0.6.2. Seems like I am the lucky one, in the meantime I was able to track down the problem to an inline matching issue. This box has an older config migrated to Shorewall in the past. Following blacklist rule (blrules file) caused the trouble for version greater 5.0.6.1: # Filter all packets that have RH0 headers DROP all all ; -m rt --rt-type 0 this generated until 5.0.6.1 a rule -A ~blacklist1 -m rt --rt-type 0 -j DROP which is referenced correctly, everything works as expected version 5.0.6.2 and 5.0.7 generate new rules: a new chain fw-loc~ appears which is polpulated with fw-loc~ -m rt --rt-type 0 -j DROP inline part present, so far, ok. BUT ~blacklist1 is now polulated with -A ~blacklist1 -j DROP which is missing the inline match, generating a blackhole rule, ipv6 connectivity successfully terminated... After a fair amount of crossreading through the whole shorewall docs, because not in every place its crystal clear how inline matches are now have to be written down, I have updated the format of the blacklisting entry to post 5.0.3 favored to eliminate backward compatibility issues: INLINE(DROP):info all all ;; -m rt --rt-type 0 Same result... Inline match is missing, I consider this a big fat bug! ;-)
OK, there were 3 changes and one of them targeting inline matches: + # + # Clear inline matches + # + set_inline_matches( '' ); I'll post it upstream and see what Tom says. Thanks for the report.
Bug confirmed. Upstream released shorewall-5.0.7.1 which contains a fix. I'll replace shorewall-5.0.6.2 shortly. Again, thanks for the report!
shorewall-5.0.7.1 is now in tree: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7310cb5ad95bf3a820d43783e579d8119088240f Please re-open if you still encounter the problem.
