> > Resolution: > > > > Spotted reference in "Problems Corrected in 3.4.1" to: > > > > 3) Log messages specifying a log tag had two spaces appended to the > > log prefix. This could cause mysterious "log-prefix truncated" > > messages. > > > > I had been ignoring the above warning because it didn't make sense, and > > anyway, I didn't care that a log prefix was shortened as long as it > > appeared in the log, and the logging was working fine. > > > > I decided to take the troubleshooter stance that if something is broken, > > you view any anomaly, no matter how innocuous, as a potential indicator > > for the problem. I renamed the log rule for HTTPS as follows: > > > > LOG:$LOG:443out $FW all tcp 443 - - - - > > > > With this change, no warnings about Log Prefix truncation is emitted on > > a shorewall restart. > > > > HTTPS traffic from fw to net now works correctly. > > > > Summary: > > > > This is a flaw. I cannot say yet whether this appears in later versions > > of shorewall, but I also do not see any indications that such an issue has > > been fixed, though my search may not have been conclusive. > > Given the way that shorewall 3.0.4 worked, I find this problem report and > the resolution to be a complete mystery. I have confirmed that (other than > the missing space anomaly) that the problem doesn't occur in Shorewall 4.0.3 > with either the Perl or Shell compilers. But then, given that I can't > understand how it could have happened in 3.0.4, I'm not sure that there > isn't something else going on in your configuration that causes the problem > and might still cause the problem in later releases (even though log rule > generation was rewritten in 3.2.0). > > So if you could re-create the bug then capture the output of "shorewall > dump", I will be interested to take a look at it. > > Thanks, > -Tom
I have hosed myself. I didn't tar up the configuration once it started working, and I tried to reproduce the problem and now cannot get it back working, so indications are that the solution is a bit more than changing the LOG tag... The sad thing is I was very sure I had only changed/added log items and https rule to $FW all instead of $FW net when it started working. I have not yet figured out how to fix it, so anyway, if nothing else, it is an opportunity to log as a known issue. The attached configuration is broken. Failed attempts are SRC=192.168.128.7 DST=212.85.147.126 To try to make sure it wasn't a destination fault, after the failure, I did shorewall clear and retried. The https link succeeded, after which I immediately did a start. The https link attempt again fails even with the LOG rule not triggering the truncation warning. --- Kevin R. Bulgrien Design and Development Engineer VertexRSI This email message is for the sole use of the intended recipient(s) and may contain General Dynamics SATCOM Technologies confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message.
broken.status.txt.bz2
Description: Binary data
------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
