View | Details | Raw Unified | Return to bug 38951
Collapse All | Expand All

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

Return to bug 38951