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

(-)article.sgml Thu Aug 16 06:19:57 2001 (-9 / +9 lines)
Lines 28-34 Link Here
28
28
29
    <abstract>
29
    <abstract>
30
      <para>This article documents how to setup a firewall using a PPP
30
      <para>This article documents how to setup a firewall using a PPP
31
       dialup with FreeBSD and IPFW, and specifically with firewalling over
31
       dialup with FreeBSD and &man.ipfw.8;, and specifically with firewalling over
32
       a dialup with a dynamically assigned IP address.  This document does
32
       a dialup with a dynamically assigned IP address.  This document does
33
       not cover setting up your PPP connection in the first place.</para>
33
       not cover setting up your PPP connection in the first place.</para>
34
    </abstract>
34
    </abstract>
Lines 175-181 Link Here
175
      order of allow first and  then deny. The premise is that you add the
175
      order of allow first and  then deny. The premise is that you add the
176
      rules for your allows, and  then everything else is denied. :)</para>
176
      rules for your allows, and  then everything else is denied. :)</para>
177
177
178
    <para>Now, let's make the dir /etc/firewall. Change into the directory and
178
    <para>Now, let's make the dir <filename>/etc/firewall</filename>. Change into the directory and
179
      edit the file <filename>fwrules</filename> as we specified in
179
      edit the file <filename>fwrules</filename> as we specified in
180
      <filename>rc.conf</filename>. Please note that you can change this
180
      <filename>rc.conf</filename>. Please note that you can change this
181
      filename to be anything you wish. This guide just gives an example of a
181
      filename to be anything you wish. This guide just gives an example of a
Lines 247-262 Link Here
247
    <qandaset>
247
    <qandaset>
248
      <qandaentry>
248
      <qandaentry>
249
       <question>
249
       <question>
250
         <para>Why are you using natd and ipfw when you could be using
250
         <para>Why are you using &man.natd.8; and &man.ipfw.8; when you could be using
251
           the built in ppp-filters?</para>
251
           the built in &man.ppp.8; filters?</para>
252
       </question>
252
       </question>
253
253
254
       <answer>
254
       <answer>
255
         <para>I'll have to be honest and say there's no definitive reason
255
         <para>I'll have to be honest and say there's no definitive reason
256
           why I use ipfw and natd instead of the built in ppp filters.  From
256
           why I use &man.ipfw.8; and &man.natd.8; instead of the built in &man.ppp.8; filters.  From
257
           the discussions I've had with people the consensus seems to be
257
           the discussions I've had with people the consensus seems to be
258
           that while ipfw is certainly more powerful and more configurable
258
           that while &man.ipfw.8; is certainly more powerful and more configurable
259
           than the ppp filters, what it makes up for in functionality it
259
           than the &man.ppp.8; filters, what it makes up for in functionality it
260
           loses in being easy to customise.  One of the reasons I use it is
260
           loses in being easy to customise.  One of the reasons I use it is
261
           because I prefer firewalling to be done at a kernel level rather
261
           because I prefer firewalling to be done at a kernel level rather
262
           than by a userland program.</para>
262
           than by a userland program.</para>
Lines 289-297 Link Here
289
       </question>
289
       </question>
290
290
291
       <answer>
291
       <answer>
292
         <para>The simple answer is no. The reason for this is that natd is
292
         <para>The simple answer is no. The reason for this is that &man.natd.8; is
293
           doing address translation for <emphasis>anything</emphasis> being
293
           doing address translation for <emphasis>anything</emphasis> being
294
           diverted through the tun0 device. As far as it's concerned
294
           diverted through the <devicename>tun0</devicename> device. As far as it's concerned
295
           incoming packets will speak only to the dynamically assigned IP
295
           incoming packets will speak only to the dynamically assigned IP
296
           address and NOT to the internal network. Note though that you can
296
           address and NOT to the internal network. Note though that you can
297
           add a rule like <literal>$fwcmd add deny all from
297
           add a rule like <literal>$fwcmd add deny all from

Return to bug 29744