os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Use of appropriate tags for quotation marks, removing a contraction

Browse source 
PR:		docs/38951
Submitted by:	Marc Fonvieille <marc@blackend.org>
Approved by:	keramida
This commit is contained in:
Marc Fonvieille 2002-06-18 19:32:53 +00:00
parent 2492d7e28a
commit 194308ce1b
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=13417
1 changed files with 13 additions and 13 deletions

26
en_US.ISO8859-1/articles/filtering-bridges/article.sgml
View file

@ -128,7 +128,7 @@ options IPFIREWALL_VERBOSE</programlisting>
modules (according to the previously choosen installation method), you
have to make some changes to the <filename>/etc/rc.conf</filename>
configuration file. The default rule of the firewall is to reject all IP
packets. Initially we'll set up an 'open' firewall, in order to verify
packets. Initially we will set up an <option>open</option> firewall, in order to verify
its operation without any issue related to packet filtering (in case you
are going to execute this procedure remotely, such configuration will
avoid you to remain isolated from the network). Put these lines in
@ -141,7 +141,7 @@ firewall_logging="YES"</programlisting>
<para>The first row will enable the firewall (and will load the module
<filename>ipfw.ko</filename> if it is not compiled in the kernel), the
second one to set up it in 'open' mode (as explained in
second one to set up it in <option>open</option> mode (as explained in
<filename>/etc/rc.firewall</filename>), the third one to not show rules
loading and the fourth one to enable logging support.</para>
@ -178,7 +178,7 @@ firewall_logging="YES"</programlisting>
<para>Now it's time to reboot the system and use it as before: there will
be some new messages about the bridge and the firewall, but the bridge
will not be activated and the firewall, being in 'open' mode, will not
will not be activated and the firewall, being in <option>open</option> mode, will not
avoid any operations.</para>
<para>If there are any problems, you should sort them out now
@ -220,11 +220,11 @@ firewall_logging="YES"</programlisting>
are being received by the local machine. In general, incoming packets
are run through the firewall only once, not twice as is normally the
case; in fact they are filtered only upon receipt, so rules that use
'out' or 'xmit' will never match. Personally, I use 'in via' which is an
<option>out</option> or <option>xmit</option> will never match. Personally, I use <option>in via</option> which is an
older syntax, but one that has a sense when you read it. Another
limitation is that you are restricted to use only 'pass' or 'drop'
limitation is that you are restricted to use only <option>pass</option> or <option>drop</option>
commands for packets filtered by a bridge. Sophisticated things like
'divert', 'forward' or 'reject' are not available. Such options can
<option>divert</option>, <option>forward</option> or <option>reject</option> are not available. Such options can
still be used, but only on traffic to or from the bridge machine itself
(if it has an IP address).</para>
@ -234,7 +234,7 @@ firewall_logging="YES"</programlisting>
exact same set of IP addresses and port numbers (but with source and
destination reversed, of course). For firewalls that have no
statekeeping, there is almost no way to deal with this sort of traffic
as a single session. But with a firewall that can "remember" an outgoing
as a single session. But with a firewall that can <quote>remember</quote> an outgoing
<acronym>UDP</acronym> packet and, for the next few minutes, allow a
response, handling <acronym>UDP</acronym> services is trivial. The
following example shows how to do it. It's possible to do the same thing
@ -248,7 +248,7 @@ firewall_logging="YES"</programlisting>
have to care for them anymore. Custom rules should be put in a separate
file (say <filename>/etc/rc.firewall.local</filename>) and loaded at
system startup, by modifying the row of
<filename>/etc/rc.conf</filename> where we defined the 'open'
<filename>/etc/rc.conf</filename> where we defined the <option>open</option>
firewall:</para>
<programlisting>firewall_type="/etc/rc.firewall.local"</programlisting>
@ -338,14 +338,14 @@ add drop log all from any to any</programlisting>
server, if you have them. Obviously the whole rule set should be
flavored to personal taste, this is only a specific example (rule format
is described accurately in the &man.ipfw.8; man page). Note that in
order for 'relay' and 'ns' to work, name service lookups must work
order for <quote>relay</quote> and <quote>ns</quote> to work, name service lookups must work
<emphasis>before</emphasis> the bridge is enabled. This is an example of
making sure that you set the IP on the correct network card.
Alternatively it is possible to specify the IP address instead of the
host name (required if the machine is IP-less).</para>
<para>People that are used to setting up firewalls are probably also used
to either having a 'reset' or a 'forward' rule for ident packets
to either having a <option>reset</option> or a <option>forward</option> rule for ident packets
(<acronym>TCP</acronym> port 113). Unfortunately, this is not an
applicable option with the bridge, so the best thing is to simply pass
them to their destination. As long as that destination machine is not
@ -360,9 +360,9 @@ add drop log all from any to any</programlisting>
of traffic will take different paths through the kernel and into the
packet filter. The inside net will go through the bridge, while the
local machine will use the normal IP stack to speak. Thus the two rules
to handle the different cases. The 'in via
<devicename>fxp0</devicename>' rules work for both paths. In general, if
you use 'in via' rules throughout the filter, you will need to make an
to handle the different cases. The <literal>in via
<devicename>fxp0</devicename></literal> rules work for both paths. In general, if
you use <option>in via</option> rules throughout the filter, you will need to make an
exception for locally generated packets, because they did not come in
via any of our interfaces.</para>
</sect1>