forked from extern/shorewall_code
Change USE_DEFAULT_RT default to 'Yes'.
Signed-off-by: Tom Eastep <teastep@shorewall.net>
This commit is contained in:
parent
733a17470e
commit
cea237620a
@ -5626,7 +5626,7 @@ sub get_configuration( $$$$$ ) {
|
||||
require_capability 'COMMENTS', 'TRACK_RULES=Yes', 's' if $config{TRACK_RULES};
|
||||
|
||||
default_yes_no 'MANGLE_ENABLED' , have_capability( 'MANGLE_ENABLED' ) ? 'Yes' : '';
|
||||
default_yes_no 'USE_DEFAULT_RT' , '';
|
||||
default_yes_no 'USE_DEFAULT_RT' , 'Yes';
|
||||
default_yes_no 'RESTORE_DEFAULT_ROUTE' , 'Yes';
|
||||
default_yes_no 'AUTOMAKE' , '';
|
||||
default_yes_no 'WIDE_TC_MARKS' , '';
|
||||
|
@ -224,7 +224,7 @@ TRACK_PROVIDERS=Yes
|
||||
|
||||
TRACK_RULES=No
|
||||
|
||||
USE_DEFAULT_RT=No
|
||||
USE_DEFAULT_RT=Yes
|
||||
|
||||
USE_PHYSICAL_NAMES=No
|
||||
|
||||
|
@ -235,7 +235,7 @@ TRACK_PROVIDERS=Yes
|
||||
|
||||
TRACK_RULES=No
|
||||
|
||||
USE_DEFAULT_RT=No
|
||||
USE_DEFAULT_RT=Yes
|
||||
|
||||
USE_PHYSICAL_NAMES=No
|
||||
|
||||
|
@ -233,7 +233,7 @@ TRACK_PROVIDERS=Yes
|
||||
|
||||
TRACK_RULES=No
|
||||
|
||||
USE_DEFAULT_RT=No
|
||||
USE_DEFAULT_RT=Yes
|
||||
|
||||
USE_PHYSICAL_NAMES=No
|
||||
|
||||
|
@ -236,7 +236,7 @@ TRACK_PROVIDERS=Yes
|
||||
|
||||
TRACK_RULES=No
|
||||
|
||||
USE_DEFAULT_RT=No
|
||||
USE_DEFAULT_RT=Yes
|
||||
|
||||
USE_PHYSICAL_NAMES=No
|
||||
|
||||
|
@ -224,7 +224,7 @@ TRACK_PROVIDERS=No
|
||||
|
||||
TRACK_RULES=No
|
||||
|
||||
USE_DEFAULT_RT=No
|
||||
USE_DEFAULT_RT=Yes
|
||||
|
||||
USE_PHYSICAL_NAMES=No
|
||||
|
||||
|
@ -324,7 +324,7 @@
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
<para> If this variable is not set or is given the empty value then
|
||||
<para>If this variable is not set or is given the empty value then
|
||||
ADMINISABSENTMINDED=No is assumed.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -2766,12 +2766,12 @@ INLINE - - - ; -j REJECT
|
||||
|
||||
<listitem>
|
||||
<para>When set to 'Yes', this option causes the Shorewall multi-ISP
|
||||
feature to create a different set of routing rules which are
|
||||
resilient to changes in the main routing table. Such changes can
|
||||
occur for a number of reasons, VPNs going up and down being an
|
||||
example. The idea is to send packets through the main table prior to
|
||||
applying any of the Shorewall-generated routing rules. So changes to
|
||||
the main table will affect the routing of packets by default.</para>
|
||||
feature to create a set of routing rules which are resilient to
|
||||
changes in the main routing table. Such changes can occur for a
|
||||
number of reasons, VPNs going up and down being an example. The idea
|
||||
is to send packets through the main table prior to applying any of
|
||||
the Shorewall-generated routing rules. So changes to the main table
|
||||
will affect the routing of packets by default.</para>
|
||||
|
||||
<para>When USE_DEFAULT_RT=Yes:</para>
|
||||
|
||||
@ -2820,8 +2820,10 @@ INLINE - - - ; -j REJECT
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
<para>If USE_DEFAULT_RT is not set or if it is set to the empty
|
||||
string then USE_DEFAULT_RT=No is assumed.</para>
|
||||
<para>Prior to Shorewall 4.6.0, if USE_DEFAULT_RT was not set or if
|
||||
it was set to the empty string then USE_DEFAULT_RT=No was assumed.
|
||||
Beginning with Shorewall 4.6.0, the default is USE_DEFAULT_RT=Yes
|
||||
and use of USE_DEFAULT_RT=No is discouraged.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
@ -197,7 +197,7 @@ TRACK_PROVIDERS=Yes
|
||||
|
||||
TRACK_RULES=No
|
||||
|
||||
USE_DEFAULT_RT=No
|
||||
USE_DEFAULT_RT=Yes
|
||||
|
||||
USE_PHYSICAL_NAMES=No
|
||||
|
||||
|
@ -197,7 +197,7 @@ TRACK_PROVIDERS=Yes
|
||||
|
||||
TRACK_RULES=No
|
||||
|
||||
USE_DEFAULT_RT=No
|
||||
USE_DEFAULT_RT=Yes
|
||||
|
||||
USE_PHYSICAL_NAMES=No
|
||||
|
||||
|
@ -197,7 +197,7 @@ TRACK_PROVIDERS=Yes
|
||||
|
||||
TRACK_RULES=No
|
||||
|
||||
USE_DEFAULT_RT=No
|
||||
USE_DEFAULT_RT=Yes
|
||||
|
||||
USE_PHYSICAL_NAMES=No
|
||||
|
||||
|
@ -197,7 +197,7 @@ TRACK_PROVIDERS=Yes
|
||||
|
||||
TRACK_RULES=No
|
||||
|
||||
USE_DEFAULT_RT=No
|
||||
USE_DEFAULT_RT=Yes
|
||||
|
||||
USE_PHYSICAL_NAMES=No
|
||||
|
||||
|
@ -197,7 +197,7 @@ TRACK_PROVIDERS=No
|
||||
|
||||
TRACK_RULES=No
|
||||
|
||||
USE_DEFAULT_RT=No
|
||||
USE_DEFAULT_RT=Yes
|
||||
|
||||
USE_PHYSICAL_NAMES=No
|
||||
|
||||
|
@ -2414,13 +2414,13 @@ INLINE - - - ; -j REJECT
|
||||
|
||||
<listitem>
|
||||
<para>Added in Shorewall6 4.4.25. When set to 'Yes', this option
|
||||
causes the Shorewall6 multi-ISP feature to create a different set of
|
||||
routing rules which are resilient to changes in the main routing
|
||||
table. Such changes can occur for a number of reasons, VPNs going up
|
||||
and down being an example. The idea is to send packets through the
|
||||
main table prior to applying any of the Shorewall6-generated routing
|
||||
rules. So changes to the main table will affect the routing of
|
||||
packets by default.</para>
|
||||
causes the Shorewall6 multi-ISP feature to create a set of routing
|
||||
rules which are resilient to changes in the main routing table. Such
|
||||
changes can occur for a number of reasons, VPNs going up and down
|
||||
being an example. The idea is to send packets through the main table
|
||||
prior to applying any of the Shorewall6-generated routing rules. So
|
||||
changes to the main table will affect the routing of packets by
|
||||
default.</para>
|
||||
|
||||
<para>When USE_DEFAULT_RT=Yes:</para>
|
||||
|
||||
@ -2464,8 +2464,10 @@ INLINE - - - ; -j REJECT
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
<para>If USE_DEFAULT_RT is not set or if it is set to the empty
|
||||
string then USE_DEFAULT_RT=No is assumed.</para>
|
||||
<para>Prior to Shorewall 4.6.0, if USE_DEFAULT_RT was not set or if
|
||||
it was set to the empty string then USE_DEFAULT_RT=No was assumed.
|
||||
Beginning with Shorewall 4.6.0, the default is USE_DEFAULT_RT=Yes
|
||||
and use of USE_DEFAULT_RT=No is discouraged.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user