On Wed, 12 May 2010 21:28:03 +1000 "Rod Whitworth"
<[email protected]> wrote:
> Have you actually written and tested a ruleset using either of those
> documents?
> If so please show us.
>
> Particularly seeing I referenced both of those in my original post as
> not being helpful and I've been trying to get somebody - anybody - to
> write a minimal NAT ruleset and show me.
Creating a minimal rule set for a firewall doing NAT is very simple;
basically, it's a one-liner 'match' rule, but with 4.7-RELEASE/STABLE
you should be more verbose if you're using ppp(8) and possibly pppd(8),
and create the typical interface-based rules.
-----------------------------------------------------------------------------
# $OpenBSD: pf.conf,v 1.49 2009/09/17 06:39:03 jmc Exp $
#
# See pf.conf(5) for syntax and examples.
# Remember to set net.inet.ip.forwarding=1 and/or net.inet6.ip6.forwarding=1
# in /etc/sysctl.conf if packets are to be forwarded between interfaces.
ext_if = "tun0"
int_if = "xl0"
set skip on lo
# set block-policy drop
# default block
block in log all
# block log quick inet6
# filter rules and anchor for ftp-proxy(8)
# anchor "ftp-proxy/*"
# pass in log on $int_if proto tcp to port ftp rdr-to 127.0.0.1 port 8021
# anchor for relayd(8)
# anchor "relayd/*"
# nat for local network
match out on $ext_if from ($int_if:network) nat-to ($ext_if:0)
pass in on $int_if
pass out on $ext_if
# rules for spamd(8)
#table <spamd-white> persist
#table <nospamd> persist file "/etc/mail/nospamd"
#pass in on egress proto tcp from any to any port smtp \
# rdr-to 127.0.0.1 port spamd
#pass in on egress proto tcp from <nospamd> to any port smtp
#pass in log on egress proto tcp from <spamd-white> to any port smtp
#pass out log on egress proto tcp to any port smtp
#block in quick from urpf-failed to any # use with care
# By default, do not permit remote connections to X11
block in on ! lo0 proto tcp to port 6000:6010
-----------------------------------------------------------------------------
NOTE: I don't know enough about interface groups or how they work with pf,
and I'm still testing and learning, so my advice is *VERY* dodgy. ;)
One of the issues is not well stated, namely, the improvements in pf ruleset
syntax have a goal of simplification such as hardware-independent rules. This
is being accomplished by using "interface groups" as noted in ifconfig(8).
You'll note how the default pf.conf ruleset *intentionally* avoids using the
previously typical hardware-dependent syntax such as defining 'ext_if' and
'int_if' then using them in the rules. The more complex hardware-dependent
syntax still works fine if used (as above), and providing an example might
be useful for the short term.
Long term, it is better to use hardware-independent rules. The previously
mentioned "one-liner" would simply be:
match out on egress from ! egress nat-to egress
Though the above *mostly* works, the trouble is, 'egress' is actually a *GROUP*
of interfaces, so what pf is really doing is less than crystal clear unless
you've worked with it a bit. I don't know how well the above one-liner works on
4.7-RELEASE/STABLE but I *just* started testing it on -CURRENt with a rather
unstable ppp connection (via umodem EVDO/Verizon).
With -CURRENT I've found one bug with using 'egress' NAT and it seems to be due
to the tun0 interface being destroyed and recreated by ppp(8) so pf loses track
of the (only) 'egress' interface. Manually reloading the pf ruleset after ppp(8)
recreates the tun0 interface and reestablishes the connection, fixes the
problem, so I could easily put the pf reload in /etc/ppp/ppp.linkup to solve
the problem.
Since manually reloading pf rules is not necessary when using the full
interface-based ruleset above, it also should not be necessary when using a
hardware independent group-based ruleset (i.e. with 'egress').
I haven't gotten to testing how pppd(8) behaves, but the 'egress group bug'
might be there as well.
NOTE:
I just discovered the above bug a few minutes ago, but the -CURRENT on
that box is stale (Mar9) so I'll update and retest to see if it's already
fixed before filing a PR. None the less, it might also exist in 4.7-RELEASE
or 4.7-STABLE and I'll try to get that tested as well. I don't have RELEASE
installed anywhere, so I'll have to build up a new box. Luckily, my 4.7 set
was pre-ordered and is sitting right next to me.
Ya, our new super-simple-syntax seems to have a show stopper bug on release
because you, me, and everyone else, have failed to do adequate testing.
--
The OpenBSD Journal - http://www.undeadly.org
