extern/shorewall_code
1
0
Fork 1
mirror of https://gitlab.com/shorewall/code.git synced 2024-11-25 17:13:11 +01:00
Code Issues Packages Projects Releases Wiki Activity

Update TRACK_PROVIDER description in the man pages.

Browse Source 
Signed-off-by: Tom Eastep <teastep@shorewall.net>
This commit is contained in:
Tom Eastep 2010-01-14 08:36:22 -08:00
parent 45d975cb45
commit 25d433b36f
2 changed files with 22 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
manpages/shorewall.conf.xml
View File

@ -1521,16 +1521,16 @@ net all DROP info</programlisting>then the chain name is 'net2all'
Previously, when TC_EXPERT=No, packets arriving through 'tracked'
provider interfaces were unconditionally passed to the PREROUTING
tcrules. This was done so that tcrules could reset the packet mark
to zero so that the packet would be routed using the 'main' routing
table. Using the main table allowed dynamic routes (such as those
added for VPNs) to be effective. The route_rules file was created to
provide a better alternative to clearing the packet mark. As a
consequence, passing these packets to PREROUTING complicates things
without providing any real benefit. Beginning with Shorewall 4.4.6,
when TRACK_PROVIDERS=Yes and TC_EXPERT=No, packets arriving through
'tracked' interfaces will not be passed to the PREROUTING rules.
Since TRACK_PROVIDERS was just introduced in 4.4.3, this change
should be transparent to most, if not all, users.</para>
to zero, thus allowing the packet to be routed using the 'main'
routing table. Using the main table allowed dynamic routes (such as
those added for VPNs) to be effective. The route_rules file was
created to provide a better alternative to clearing the packet mark.
As a consequence, passing these packets to PREROUTING complicates
things without providing any real benefit. Beginning with Shorewall
4.4.6, when TRACK_PROVIDERS=Yes and TC_EXPERT=No, packets arriving
through 'tracked' interfaces will not be passed to the PREROUTING
rules. Since TRACK_PROVIDERS was just introduced in 4.4.3, this
change should be transparent to most, if not all, users.</para>
</listitem>
</varlistentry>

22
manpages6/shorewall6.conf.xml
View File

@ -1307,16 +1307,18 @@ net all DROP info</programlisting>then the chain name is 'net2all'
Previously, when TC_EXPERT=No, packets arriving through 'tracked'
provider interfaces were unconditionally passed to the PREROUTING
tcrules. This was done so that tcrules could reset the packet mark
to zero so that the packet would be routed using the 'main' routing
table. Using the main table allowed dynamic routes (such as those
added for VPNs) to be effective. The route_rules file was created to
provide a better alternative to clearing the packet mark. As a
consequence, passing these packets to PREROUTING complicates things
without providing any real benefit. Beginning with Shorewall 4.4.6,
when TRACK_PROVIDERS=Yes and TC_EXPERT=No, packets arriving through
'tracked' interfaces will not be passed to the PREROUTING rules.
Since TRACK_PROVIDERS was just introduced in 4.4.3, this change
should be transparent to most, if not all, users.</para>
to zero, thus allowing the packet to be routed using the 'main'
routing table. Using the main table allowed dynamic routes (such as
those added for VPNs) to be effective. The <ulink
url="shorewall6-route_rules.html">shorewall6-route_rules</ulink>(5)
file was created to provide a better alternative to clearing the
packet mark. As a consequence, passing these packets to PREROUTING
complicates things without providing any real benefit. Beginning
with Shorewall 4.4.6, when TRACK_PROVIDERS=Yes and TC_EXPERT=No,
packets arriving through 'tracked' interfaces will not be passed to
the PREROUTING rules. Since TRACK_PROVIDERS was just introduced in
4.4.3, this change should be transparent to most, if not all,
users.</para>
</listitem>
</varlistentry>