Remove default action specifications from actions.std

git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@4482 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb

Shorewall/actions.std

@@ -23,7 +23,7 @@
 #
 ###############################################################################
 #ACTION
-Drop:DROP	    # Common Action for DROP policy
+Drop		    # Default Action for DROP policy
-Reject:REJECT	    # Common Action for REJECT policy
+Reject		    # Default Action for REJECT policy
 Limit		    # Limit the rate of connections from each individual IP
 #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE

Shorewall/compiler

@@ -517,7 +517,13 @@ validate_policy()
 	esac
 
 	case ${policy%:*} in
-	    ACCEPT|REJECT|DROP|CONTINUE|QUEUE)
+	    ACCEPT|CONTINUE|QUEUE)
+		;;
+	    REJECT|DROP)
+		if [ -n "$default" ]; then
+		    error_message "WARNING: Policy has no default action or macro:  $client $server $policy $loglevel $synparams"
+		    error_message "         Please see http://www.shorewall.net/DefaultActionsandMacros.html"
+		fi
 		;;
 	    NONE)
 		[ "$client" = "$FW" -o "$server" = "$FW" ] && \

Shorewall/releasenotes.txt

@@ -42,7 +42,77 @@ Other changes in 3.3.1
 
 None. 
 
-Migration Considerations: 	 
+Migration Considerations:
+
+1)  Shorewall supports the notion of "default actions". A default
+    action defines a set of rules that are applied before a policy is
+    enforced. Default actions accomplish two goals:
+
+    a) Relieve log congestion. Default actions typically include rules
+       to silently drop or reject traffic that would otherwise be logged
+       when the policy is enforced.
+
+    b) Ensure correct operation. Default actions can also avoid common
+       pitfalls like dropping connection requests on port TCP port
+       113. If these connections are dropped (rather than rejected)
+       then you may encounter problems connecting to internet services
+       that utilize the AUTH protocol of client authentication.
+
+    In prior Shorewall versions, default actions (action.Drop and
+    action.Reject) were defined for DROP and REJECT policies in
+    /usr/share/shorewall/actions.std.
+
+    This approach has two drawbacks:
+
+    a) All DROP policies must use the same default action and all
+       REJECT policies must use the same default action.
+
+    b) Now that we have modularized action processing (see the New
+       Features section below), we need a way to define default rules
+       for a policy.
+
+    The solution is to extend the POLICY column in
+    /etc/shorewall/policy and to remove the specification of 
+    a default action in /etc/shorewall/actions.std.
+
+    When the POLICY is ACCEPT, DROP, REJECT or QUEUE then the policy
+    may be followed by ":" and one of the following:
+			
+	a) The word "None" or "none". This causes any default
+	   action define in /etc/shorewall/actions to be omitted for
+	   this policy.
+	b) The name of an action (requires that USE_ACTIONS=Yes
+	   in shorewall.conf). That action will be invoked 
+	   before the policy is enforced.
+	c) The name of a macro. The rules in that macro will
+	   be applied before the policy is enforced. This
+	   does not require USE_ACTIONS=Yes.
+
+    Example:
+
+	#SOURCE		DEST		POLICY		LOG
+	#						LEVEL
+	loc		net		ACCEPT
+	net		all		DROP:Drop	info
+	#
+	# THE FOLLOWING POLICY MUST BE LAST
+	#
+	all		all		REJECT:Reject	info
+
+    With USE_ACTIONS=Yes, the above will work the same way that the
+    pre-3.3 setup did. The 'Drop' and 'Reject' actions will be invoked
+    before the DROP and REJECT policies are enforced.
+
+    With USE_ACTION=No, there will be no Drop or Reject actions so 
+    Shorewall will look for macros by that name; as described in item
+    2) above, these macros are provided as part of the Shorewall 3.3
+    release.
+
+    If you are happy with the way that things worked in prior releases,
+    then simply add these two lines to your /etc/shorewall/actions:
+
+	 Drop:DROP
+	 Reject:REJECT
   	 
 New Features: