OpenBSD Journal

Building a PF firewall walkthrough

Contributed by jose on from the help! dept.

Eric Bullen writes: "I get lots of requests for help with building PF firewalls from newbies, and they felt that the current FAQs have more information that they need for a beginner, and no real good walk through. So I felt it was time to scratch this itch, and I am sure others will find this useful. This is geared for beginners, and leaves out some of the more advanced features, but spends alot of time explaining why things are the way they are. I hope this helps more people than I am working with. Here's a direct link:

http://www.thedeepsky.com/howto/newbie_pf_guide.php "

Thanks, Eric!

(Comments are closed)

Comments

  1. By zibi () on

    You misslead people by notice of /etc/nat.conf
    in rc.conf.local and then you don't use that eg.:
    ---
    Listing 1. /etc/rc.conf.local
    #!/bin/sh -
    pf=YES # Packet filter / NAT
    pf_rules=/etc/pf.conf # Packet filter rules file
    nat_rules=/etc/nat.conf # NAT rules file
    pflogd_flags= # add more flags, ie. "-s 256"
    ---
    You should put the statement that everything is
    now in /etc/pf.conf


  2. By Anonymous Coward () on

    Thanks for a great article. I used it to upgrade my firewall at home, and update the pf.conf at the same time. Whlie it doesn't try to explain everything, it does the basics very well. I'd love to see another.

  3. By byte () on

    The text looks fine but I noticed a misunderstanding in the UDP section:

    "If you have a server hanging on the net, and it receives a UDP packet destined for a port it doesn't listen on, it will drop the packet with no reply [...]"

    Packets to closed UDP ports are supposed to trigger ICMP port unreachable error messages.

    Comments

    1. By Anonymous Coward () on

      No, it really doesn't. The server when it receives a packet doesn't have to even acknowlege receiving the packet, nor does it have to return anything if it is closed. Returning a icmp port-unreach is completely elective, and not required..

    2. By Ryvar () none on mailto:none

      I'm surprised you haven't encountered this before, the general consensus of the firewall-wielding Internet seems to be 'to Hell with the RFC, my machine is a blackhole.'

      --Ryv

      Comments

      1. By Anonymous Coward () on

        Which RFC?

  4. By Peter MacFarlane () cpmacfar@isn.net on mailto:cpmacfar@isn.net

    The walkthru should be much appreciated since it has taken me several weeks to come up with a basic configuration on oBSD 3.3 that works, contrary to the more basic default deny policy script I used on 2.9. Better syntax examples would help. I finally figured out that the pf.conf man pages did have the best startup examples. The problem I find is mainly how to pass TCP traffic correctly.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]