First, a solution to the problem is being posted herein, so I will not make an attempt to document the entire configuration, but rather only the important relevent portions of the configuration - unless someone requests more to test.
Second, a disclaimer. I am using: $ sudo shorewall version 3.0.4 I can't help this. I am using Mandriva Corporate Server 4.0 expressly because it allows me to keep a stable system with a 5-year security update plan. They rarely update packages until it becomes too hard to backport security patches. Third, even though this is an old version, I would like to ask this question in case it is relevant to newer versions, because resolving this has taken a very long time. Scenario: - The server needs to be able to use HTTPS to contact the net zone to perform an important maintenance function. - "ULOG" is used as the firewall log level to keep firewall messages from cluttering the system logs, and, use of "info" does not change the results (but does identify yet another bug). - Some traffic is always logged even if permitted because volume should be low and because it helps an administrator get a feel for what the users may be doing that might be a big higher risk. Problem: - The rules file is correctly configured to allow $FW to net tcp traffic on port 443 (HTTPS). - Attempts to use https from $FW to net fail WITH NO LOG EVENTS, but the log does work because other log/drop/reject events do show up. "Identically configured" port 80 (HTTP) allow from $FW to net does not fail. - The relevant parts of the configuration are: policy loc all CONTINUE net all CONTINUE $FW all REJECT $LOG rules LOG:$LOG:HTTPSout $FW all tcp 443 - - - - LOG:$LOG:WEBout $FW all tcp 80 - - - - ACCEPT $FW all tcp 80 - - - :root ACCEPT $FW net tcp 443 - - - :root Example: lynx http://www.mandriva.com Result: Success lynx: https://download.mandriva.com Result: Failed, no log entries, except HTTPSout LOG messages. Diagnostics: $ shorewall restart ... WARNING: Log Prefix shortened to "Shorewall:fw2net:LOG:HTTPSout" Rule "LOG:ULOG:HTTPSout fw net tcp 443 - - - -" added. ... Rule "ACCEPT fw net tcp 80 - - - :root" added. ... Rule "ACCEPT fw net tcp 443 - - - :root" added. ... Activating Rules... Processing /etc/shorewall/start ... Shorewall Restarted Processing /etc/shorewall/started ... An excerpt from the log shows: ULOG style log entry Aug 17 10:05:06 dnd Shorewall:fw2net:LOG:HTTPSout IN= OUT=eth0 MAC= SRC=192.168.128.7 DST=212.85.147.126 LEN=60 TOS=00 PREC=0x00 TTL=64 ID=9834 DF PROTO=TCP SPT=51040 DPT=443 SEQ=2207294271 ACK=0 WINDOW=5840 SYN URGP=0 info style log entry Aug 17 11:47:42 dnd kernel: Shorewall:fw2net:LOG:HTTPSoutIN= OUT=eth0 SRC=192.168.128.7 DST=212.85.147.126 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=59981 DF PROTO=TCP SPT=52385 DPT=443 WINDOW=5840 RES=0x00 SYN URGP=0 No other log entries exist in this time frame, yet the traffic is blocked. NOTE that there is an anomaly in the "info" log entry at "Shorewall:fw2net:LOG:HTTPSoutIN=". There should be a space between the tag and the IN= field. 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. The firewall should not block any traffic without logging the block if it has been configured to log all drops and rejects!!! Reconfiguring the logging to "info" instead of "ULOG" does not affect this issue. It occurs no matter what logger is used. Also note that the "info" style log entry is flawed. A space should be found between the log tag and the IN= field. --- Kevin R. Bulgrien Design and Development Engineer VertexRSI http://www.gdsatcom.com/ General Dynamics SATCOM Technologies Tel: 903-295-1480 x24109 1915 Harrison Road 903-381-4109 Longview, TX 75604-5438 Fax: 903-295-1479 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. ------------------------------------------------------------------------- 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
