PF的语法相当灵活，因此，允许编写非常灵活的规则集。PF能够自动插入某些关键字因此它们不必在规则中明确写出，关键字的顺序也是随意的，因此不需要记忆严格的语法限制。

要定义全部拒绝的策略，使用下面2条规则：

如果没有指定方向，PF会认为规则适用于数据包传递的进、出2个方向。

第一条规则阻塞rl0上从任意到任意的进入数据包，第二条规则允许rl0上端口22的TCP流量通过。

用于阻塞数据包，回应TCP RST或者ICMP不可到达的规则集可以这么写：

当PF看到return关键字，PF可以智能回复合适应答，或者完全不回复，取决于要阻塞的数据包使用的协议。W

在大多数情况下，关键字的顺序是非常灵活的。例如，规则可以这么写：

其他类似的顺序也能够正常工作。

运行选项是控制pf操作的选择。这些选项在

重启syslogd使变化生效：

所有符合标准的包将被写入/var/log/pflog.txt. 如果增加了第二行，这些信息也将被存入远程日志服务器syslogger。

PF 将日志以ASCII格式记录到/var/log/pflog.txt. 如果这样配置 /etc/syslog.conf, 系统将把日志存到远程服务器。存储过程不会马上发生，但是会在符合条件的包出现在文件中前5－6分钟实现。

“PF可以处理多少带宽？”
“我需要多少台计算机处理因特网连接？”

这个问题没有简单的答案。对于一些应用程序来说，一台486/66主机，带有2个比较好的ISA网卡在做过滤和NAT时接近5Mbps，但是对于其他应用程序，一个更快的计算机加上更有效的PCI网卡也会显得能力不足。真正的问题不是每秒处理的位数而是每秒处理的包数和规则集的复杂程度。

体现PF性能的几个参数:

一个1500的包和一个只有1个字节的包所需要的处理过程的数目几乎是一样的。每秒处理包的数量标志着状态表和过滤规则集在每秒内被评估的次数 ，标志着一个系统最有效的需求（在没有匹配的情况下）。

* 系统总线性能.  总线最大带宽 8MB/秒, 当访问它时, 它必须降速到80286的有效速度，不管处理器的真实处理速度如何，PCI总线有更有效的带宽，与处理器的冲突更小。

一些网卡的工作效率要高于其他网卡。 基于的网卡性能较低，而基于  的网卡性能较好。为了取得更好的性能，建议使用千兆网卡，尽管所连接的网络不是千兆网，这些千兆网卡拥有高级的缓存，可以大幅提高性能。

* 规则集的设计和复杂性。 规则越复杂越慢。越多的包通过keep和quick方式过滤，性能越好。对每个包的策略越多，性能越差。

CPU 和内存。由于PF是基于内核的进程，它不需要swap空间。所以，如果你有足够的内存，它将运行很好，如果没有，将受影响。不需要太大量的内存。 32MB内存对小型办公室或者家庭应用足够，300MHz的cpu如果配置好网卡和规则集，足够满足要求。

人们经常询问PF的基准点。唯一的基准是在一个环境下系统的性能。不考虑环境因素将影响所设计的防火墙的系统性能。

PF 曾经在非常大流量的系统中工作，同时PF的开发者也是它的忠实用户。

是一种协议，它可以追溯到因特网发展初期，那时的因特网规模小，联网的计算机彼此友好，过滤和严格安全性在那时不是必须的。FTP设计之初就没有考虑包过滤、穿透防火墙和NAT。

FTP的工作模式分为被动（passive）和主动（active）两种。通常这两种选择被用来确定哪边有防火墙问题。实际上，为了方便用户应该全部支持这两种模式。

在active模式下,当用户访问远程FTP服务器并请求一个文件信息时，那台FTP服务器将与该用户建立一个新的连接用来传输请求的数据，这被称为数据连接。具体过程为：客户端随机选择一个端口号，在该端口监听的同时将端口号传给服务器，由服务器向客户端的该端口发起连接请求，然后传递数据。在 NAT后的用户访问FTP服务器的时候会出现问题，由于NAT的工作机制，服务器将向NAT网关的外部地址的所选端口发起连接，NAT网关收到该信息后将在自己的状态表中查找该端口对应的内部主机，由于状态表中不存在这样的记录，因此该包被丢弃，导致无法建立连接。

在passive模式下（OpenBSD的ftp客户端默认模式），由客户端请求服务器随机选择一个端口并在此端口监听，服务器通知客户端它所选择的端口号，等待客户端连接。不幸的是，ftp服务器前的防火墙可能会阻断客户端发往服务器的请求信息。OpenBSD的ftp（1）默认使用

工作在防火墙之后的FTP客户端

如前所述，FTP对NAT和防火墙支持不好。

包过滤机制通过将FTP数据包重定向到一个FTP代理服务器解决这一问题。这一过程将引导FTP数据包通过NAT网关/防火墙。OpenBSD和PF使用的FTP代理是ftp-proxy（8），可以通过在pf.conf中的NAT章节增加下列信息激活该代理：

这条语句的解释为：在内部接口上的ftp数据包被重定向到本机的8021端口

显然该代理服务器应该已在OpenBSD中启动并运行。配置方法为在/etc/inetd.conf中增加下列信息：

重启系统或者通过下列命令发送一个‘HUP’标记来生效：

ftp代理在8021端口监听，上面的rdr语句也是将数据包转发到这一端口。这一端口号是可选的，因为8021端口没有被其他应用程序占用，因此不失为一个好的选择。

请注意ftp-proxy（8）是用来帮助位于PF过滤器后的ftp客户端传递信息；并不用于PF过滤器后的ftp服务器。

PF“自保护”FTP服务器

当PF运行在一个FTP服务器上，而不是单独的一台防火墙。这种情况下处理passive模式的FTP连接请求时FTP服务器将随机取一个较大的 TCP端口接收数据。默认情况下OpenBSD的本地FTP服务器ftpd（8）使用49152～65535范围内的端口，显然，必须要有对应的过滤规则放行这些端口的数据：

使用NAT外部 PF防火墙保护FTP服务器

这种情况下，防火墙必须将数据重定向到FTP服务器。为了讨论方便，我们假设该FTP服务器使用标准的OpenBSD ftpd（8），并使用默认端口范围。

过滤FTP和FTP如何工作的更多信息可以参考下面的白皮书。

(Cool是身份认证网关的用户shell。身份认证网关类似于普通网关，只不过用户必须在网关上通过身份验证后才能使用该网关。当用户 （4）策略集做必要的修改以便该用户的数据包可以通过过滤器或者（和）使用NAT、重定向功能。一旦用户退出登录或者连接被断开，authpf将移除加载到该用户上的所有策略，同时关闭该用户打开的所有会话。因此，只有当用户保持着他的SSH会话进程时他才具备透过防火墙发送数据包的能力。

Authpf通过向附加到锚点的命名策略集增加策略来改变pf（4）的策略集。每次用户进行身份验证，authpf建立一个新的命名策略集，并将已经配置好的filter、nat、binat和rdr规则加载上去。被authpf所加载的策略可以被配置为针对单独的一个用户相关或者针对总体。

* 在允许用户访问因特网之前进行身份验证。
* 赋予特殊用户访问受限网络的权利，例如管理员。
* 只允许特定的无线网络用户访问特定的网络。
* 允许公司员工在任何时候访问公司网络，而公司之外的用户不能访问，并可以将这些用户重定向到特定的基于用户名的资源（例如他们自己的桌面）。
* 在类似图书馆这样的地方通过PF限制guest用户对因特网的访问。Authpf可以用来向已注册用户开放完全的因特网连接。

Authpf通过syslogd（8）记录每一个成功通过身份验证用户的用户名、IP地址、开始结束时间。通过这些信息，管理员可以确定谁在何时登陆，也使得用户对其网络流量负责。

配置authpf的基本步骤大致描述如下。详细的信息请查看man手册。

将authpf连入主策略集

通过使用锚点策略将authpf连入主策略集：

锚点策略放入策略集的位置就是PF中断执行主策略集转为执行authpf策略的位置。上述4个锚点策略并不需要全部存在，例如，当authpf没有被设置加载任何nat策略时，nat-anchor策略可被省略。

Authpf通过下面两个文件之一加载策略：

第一个文件包含只有当用户$USER（将被替换为具体的用户名）登录时才被加载的策略。当特殊用户（例如管理员）需要一系列不同于其他默认用户的策略集时可以使用每用户策略配置。第二个文件包含没定义自己的authpf.rules文件的用户所默认加载的策略。如果用户定义的文件存在，将覆盖默认文件。这两个文件至少存在其一，否则authpf将不会工作。

过滤器和传输策略与其他的PF策略集语法一样，但有一点不同：authpf允许使用预先定义的宏：

推荐使用宏$user_ip，只赋予通过身份验证的计算机透过防火墙的权限。

可以通过在/etc/authpf/banned/目录下建立以用户名命名的文件来阻止该用户使用authpf。文件的内容将在authpf断开与该用户的连接之前显示给他，这为通知该用户被禁止访问的原因并告知他解决问题联系人提供了一个便捷的途径。

相反，有可能只允许特定的用户访问，这时可以将这些用户的用户名写入/etc/authpf/authpf.allow文件。如果该文件不存在或者文件中输入了“*”，则authpf将允许任何成功通过SSH登录的用户进行访问（没有被明确禁止的用户）。

如果authpf不能断定一个用户名是被允许还是禁止，它将打印一个摘要信息并断开该用户的连接。明确禁止将会使明确允许失效。

authpf必须作为用户的登录shell才能正常工作。当用户成功通过sshd（8）登录后，authpf将被作为用户的shell执行。它将检查该用户是否有权使用authpf，并从适当的文件中加载策略，等等。

有两种途径将authpf设置为用户shell：

一旦用户成功登录，并且authpf调整了PF的策略，authpf将改变它的进程名以显示登录者的用户名和IP地址：

在这里用户chalie从IP地址为192.168.1.3的主机登录。用户可以通过向authpf进程发送SIGTERM信号退出登录。Authpf也将移除加载到该用户上的策略并关闭任何该用户打开的会话连接。

OpenBSD网关通过authpf对一个大型校园无线网的用户进行身份验证。一旦某个用户验证通过，假设他不在禁用列表中，他将被允许SSH并访问网页（包括安全网站https），也可以访问该校园的任一个DNS服务器。

定义在/etc/pf.conf中的主策略集配置如下：

该策略集非常简单，作用如下：

* 阻断所有（默认拒绝）。
* 放行外部网卡接口上的来自无线网络并流向外部的TCP,UDP和ICMP数据包。
* 放行来自无线网络，目的地址为网关本身的SSH数据包。该策略是用户登录所必须的。
* 在无线网络接口上为流入数据建立锚点“authpf”。

设计主策略集的主导思想为：阻断任何包并允许尽可能小的数据流通过。在外部接口上流出数据包是允许的，但是默认否策略阻断了由无线接口进入的数据包。用户一旦通过验证，他们的数据包被允许通过无线接口进入并穿过网关到达其他网络。

在这个例子中，PF作为防火墙和NAT网关运行在OpenBSD机器上，为家庭或办公室的小型网络提供服务。总的目标是向内部网提供因特网接入，允许从因特网到防火墙的限制访问。下面将详细描述：

内部网有若干机器，图中只划出了3台，这些机器除了COMP3之外主要进行网页冲浪、电子邮件、聊天等；COMP3运行一个小型web服务器。内部网使用192.168.0.0/24网段。

* 向内部网络的每台计算机提供无限制的因特网接入。
* 启用一条“默认拒绝”策略。
* 允许下列来自因特网的请求访问防火墙：
* 重定向访问80端口（访问web的请求）的请求到计算机COMP3，同时，允许指向COMP3计算机的80端口的数据流过防火墙。
* 记录外部网卡接口上的过滤日志。
* 尽量保持策略集简单并易于维护。

这里假设作为网关的OpenBSD主机已经配置完成，包括IP网络配置，因特网连接和设置net.inet.ip.forwarding 的值为1。

下面将逐步建立策略集以满足上诉要求。

定义下列宏以增强策略集的可维护性和可读性：

前两行定义了发生过滤的网络接口。第3、4行定义了向因特网开放的服务端口号（SSH和ident/auth）和允许访问防火墙的ICMP包类型。第5行定义了回送地址段和RFC1918定义的私有地址段。最后一行定义了主机COMP3的IP地址。

注意：如果ADSL接入因特网需要PPPoE，则过滤和NAT将发生在tun0接口上而不是ep0接口。

下列两个选项用来设置阻断后的默认操作为反馈，并在外部接口设置开启日志记录：

没有理由不起用对所有进入防火墙的所有包进行规格化，因此只需要简单的一行：

NAT（网络地址转换）

为所有内部网启用NAT可以通过下列策略：

由于外部网卡的IP地址是动态获得的，因此在外部网卡接口处增加小括号以使当IP地址发生变化时PF可以自适应。

第一个需要重定向策略的是ftp-proxy（8），只有这样内部网上的FTP客户端才可以访问因特网上的FTP服务器。

注意这条策略只捕获到21端口的数据包，如果用户通过其他端口访问FTP服务器，则在定义目的端口时需要使用list（列表），例如： from any to any port { 21, 2121 }。

第二个重定向策略捕获因特网上的用户访问防火墙80端口的数据包。用户试图访问网络的web服务器时将产生合法的访问该端口的数据包，这些连接请求需要重定向到主机COMP3:

过滤规则第一行是默认否规则：

这时没有任何数据包可以流过防火墙，甚至来自内部网络的数据包。下面的规则将逐个依据上面提到的目标开启防火墙上的虚拟接口。

每个Unix系统都有一个“loopback（回送）”接口，它是用于系统中应用程序间通信的虚拟网络接口。在OpenBSD中，回送接口是lo（4）。

下一步，由RFC 1918定义的私有地址将在外部网卡接口的进和出方向被阻断。这些地址不应该出现在公网上，通过阻断这些地址可以保证防火墙不向外部网泄漏内网地址，同时也阻断了来自外部网中源地址为这些私有地址的数据包流入内网。

这里block drop用来通知PF停止反馈TCP RST或者ICMP Unreachabel 数据包。因为RFC 1918规定的地址不会存在于因特网上，发往那些地址的数据包将没有意义。Quick 选项用来通知PF如果这条规则匹配则不再进行其他规则的匹配操作，来自或流向$ priv_nets的数据包将被立即丢弃。

现在将打开因特网上的一些服务所用到的端口：

通过在宏$tcp_services中定义服务端口可以更方便的进行维护。开放UDP服务也可一模仿上述语句，只不过改为proto udp。

已经有了一条rdr策略将web访问请求转发到主机COMP3上，我们必须建立另一条过滤规则使得这些访问请求可以通过防火墙：

考虑到安全问题，我们使用保护web服务器――。

现在将允许ICMP包通过防火墙：

类似于宏$tcp_services，当需要增加允许进入防火墙的ICMP数据包类型时可以容易地编辑宏$icmp_types。注意这条策略将应用于所有网络接口。

现在数据流必须可以正常出入内部网络。我们假设内网的用户清楚自己的所作所为并且确定不会导致麻烦。这并不是必然有效的假设，在某些环境下更具限制性的策略集会更适合。

上面的策略将允许内网中的任何计算机发送数据包穿过防火墙；然而，这并没有允许防火墙主动与内网的计算机建立连接。这是一种好的方法吗？评价这些需要依靠网络配置的一些细节。如果防火墙同时充当DHCP服务器，它需要在分配一个地址之前ping一下该地址以确认该地址没有被占用。允许防火墙访问内部网络同时也允许了在因特网上通过ssh控制防火墙的用户访问内网。请注意禁止防火墙直接访问内网并不能带来高安全性，因为如果一个用户可以访问防火墙，他也可以改变防火墙的策略。增加下列策略可以使防火墙具备访问内网的能力：

如果这些策略同时存在，则keep state选项将不是必须的；所有的数据包都可以流经内网接口，因为一条策略规定了双向放行数据包。然而，如果没有pass out这条策略时，pass in策略必须要有keep state选项。这也是keep state的有点所在：在执行策略匹配之前将先进行state表检查，如果state表中存在匹配记录，数据包将直接放行而不比再进行策略匹配。这将提高符合比较重的防火墙的效率。

最后，允许流出外部网卡接口的数据包通过防火墙

TCP, UDP, 和 ICMP数据包将被允许朝因特网的方向出防火墙。State信息将被保存，以保证反馈回来的数据包通过防火墙。