pf change in upgrade47.html

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

pf change in upgrade47.html

Rod Whitworth-3
Any that section (pf(4) NAT syntax change) it says:

8><--
nat on $ext_if from 10/8 -> ($ext_if)
   rdr on $ext_if to ($ext_if) -> 1.2.3.4
becomes
   match out on $ext_if from 10/8 nat-to ($ext_if)
   match in on $ext_if to ($ext_if) rdr-to 1.2.3.4
----><8

Leaving out the redirects we can have a 4.6 pf.conf:
#pf.conf for 4.6 simple NAT fw/router
#skip the if macros for now
nat on $ext_if from 10/8 -> ($ext_if)
block on $ext_if
pass out on $ext_if from ($ext_if:0)
pass on $int_if
#EOF

Utterly just about the simplest pf.conf for 4.6 and we would all want
more in there I'd say but it will do for the exercise. Yep, it won't
pass traffic that was not NATted but NAT keeps state for the LAN hosts.

Now take any old box with two NICs, bang 4.7 on it, apply the suggested
change and then try it.

Then come back and tell me why ALL the examples start with "match" ?
(i.e. NAT in man pf.conf for 4.7)

The latest pf.conf documentation is written by people who don't need
documentation but, probably for the first time, they forgot that
"compleat newbies" need docs that enable them to get things working if
they RTveryFM.

Uncorrected, I fear we will see lots of frustration from folk who have
been told that there is the finest set of man pages around at OpenBSD.

I have my lab setups working but I have the benefit of working with
ipf, then pf since 2.something and I still scratched my head reading
pf.conf(5), the upgrade47 doc and Henning's email (referred to in the
upgrade doc).

How about a ruleset like this (equally missing frills):
# pf.conf for 4.7
block in on $ext_if
pass out on $ext_if from ($ext_if:0)
pass out on $ext_if from $lan_ip to any nat-to ($ext_if:0)
pass on $int_if
# EOF

jmc said that we don't need a collection of pf.conf examples. Maybe
not, but in the past there was a skeleton that worked if you
uncommented the features you needed and did some minor editing in the
macros.

Have a look at 4.7's default. Not a mention of NAT anywhere. The
commonest function required by a raw beginner doesn't show up but all
the spamd and ftp-proxy stuff does (and that's fine), but no NAT.
Crazy!

Just by the way, the default pf.conf for 4.7 has a line that says:
#pass in quick proto tcp to port ftp rdr-to 127.0.0.1 port 8021

I don't think that line is complete, is it?

Regards,




*** NOTE *** Please DO NOT CC me. I <am> subscribed to the list.
Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou.

Rod/
---
This life is not the real thing.
It is not even in Beta.
If it was, then OpenBSD would already have a man page for it.

Reply | Threaded
Open this post in threaded view
|

Re: pf change in upgrade47.html

Jason McIntyre-2
On Mon, May 10, 2010 at 03:08:19PM +1000, Rod Whitworth wrote:
>
> Then come back and tell me why ALL the examples start with "match" ?
> (i.e. NAT in man pf.conf for 4.7)
>

maybe the idea was that it's simpler to write pass/block rules for your
traffic, then just match the nat stuff. i don;t know.

>
> jmc said that we don't need a collection of pf.conf examples. Maybe
> not, but in the past there was a skeleton that worked if you
> uncommented the features you needed and did some minor editing in the
> macros.
>

that is not quite correct (i hope). i meant that the stuff that was
previously in /usr/share/examples was useless, so it was removed. there
are other, better places, like the faq.

> Have a look at 4.7's default. Not a mention of NAT anywhere. The
> commonest function required by a raw beginner doesn't show up but all
> the spamd and ftp-proxy stuff does (and that's fine), but no NAT.
> Crazy!
>

the best way to change something you don;t agree with is to submit a
diff.

jmc

Reply | Threaded
Open this post in threaded view
|

Re: pf change in upgrade47.html

Rod Whitworth-3
On Mon, 10 May 2010 15:23:45 +0059, Jason McIntyre wrote:

>On Mon, May 10, 2010 at 03:08:19PM +1000, Rod Whitworth wrote:
>>
>> Then come back and tell me why ALL the examples start with "match" ?
>> (i.e. NAT in man pf.conf for 4.7)
>>
>
>maybe the idea was that it's simpler to write pass/block rules for your
>traffic, then just match the nat stuff. i don;t know.

And neither does anyone else who hangs out here, it seems.

>
>>
>> jmc said that we don't need a collection of pf.conf examples. Maybe
>> not, but in the past there was a skeleton that worked if you
>> uncommented the features you needed and did some minor editing in the
>> macros.
>>
>
>that is not quite correct (i hope). i meant that the stuff that was
>previously in /usr/share/examples was useless, so it was removed. there
>are other, better places, like the faq.

Guess why Nick was in the address list?

No sign that he knows any more than I do.
He's trying to find out what is the best way to make NAT work too, I
suppose.

>
>> Have a look at 4.7's default. Not a mention of NAT anywhere. The
>> commonest function required by a raw beginner doesn't show up but all
>> the spamd and ftp-proxy stuff does (and that's fine), but no NAT.
>> Crazy!
>>
>
>the best way to change something you don;t agree with is to submit a
>diff.
It's awfully hard to write a diff when the info one needs to do it
correctly is not forthcoming.

I guess that nobody who writes the existing hints (man page etc) is
short of global IPs......

:{((



*** NOTE *** Please DO NOT CC me. I <am> subscribed to the list.
Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou.

Rod/
---
This life is not the real thing.
It is not even in Beta.
If it was, then OpenBSD would already have a man page for it.

Reply | Threaded
Open this post in threaded view
|

Re: pf change in upgrade47.html

roberth-5
On Wed, 12 May 2010 19:35:14 +1000
"Rod Whitworth" <[hidden email]> wrote:

> On Mon, 10 May 2010 15:23:45 +0059, Jason McIntyre wrote:
>
> >On Mon, May 10, 2010 at 03:08:19PM +1000, Rod Whitworth wrote:
> >>
> >> Then come back and tell me why ALL the examples start with
> >> "match" ? (i.e. NAT in man pf.conf for 4.7)
> >>
> >
> >maybe the idea was that it's simpler to write pass/block rules for
> >your traffic, then just match the nat stuff. i don;t know.
>
> And neither does anyone else who hangs out here, it seems.

?
http://www.openbsd.org/faq/current.html#20090901
http://marc.info/?l=openbsd-misc&m=125181847818600&w=2

Reply | Threaded
Open this post in threaded view
|

Re: pf change in upgrade47.html

Rod Whitworth-3
On Wed, 12 May 2010 13:05:15 +0200, Robert wrote:

>On Wed, 12 May 2010 19:35:14 +1000
>"Rod Whitworth" <[hidden email]> wrote:
>
>> On Mon, 10 May 2010 15:23:45 +0059, Jason McIntyre wrote:
>>
>> >On Mon, May 10, 2010 at 03:08:19PM +1000, Rod Whitworth wrote:
>> >>
>> >> Then come back and tell me why ALL the examples start with
>> >> "match" ? (i.e. NAT in man pf.conf for 4.7)
>> >>
>> >
>> >maybe the idea was that it's simpler to write pass/block rules for
>> >your traffic, then just match the nat stuff. i don;t know.
>>
>> And neither does anyone else who hangs out here, it seems.
>
>?
>http://www.openbsd.org/faq/current.html#20090901
>http://marc.info/?l=openbsd-misc&m=125181847818600&w=2
>

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.
*** NOTE *** Please DO NOT CC me. I <am> subscribed to the list.
Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou.

Rod/
---
This life is not the real thing.
It is not even in Beta.
If it was, then OpenBSD would already have a man page for it.

Reply | Threaded
Open this post in threaded view
|

Re: pf change in upgrade47.html

David Gwynne-3
On 12/05/2010, at 9:28 PM, Rod Whitworth wrote:
>
> 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.

i use the following on my router at home:

pass
block log on $if_external

anchor "ftp-proxy/*"

pass in on $if_external proto tcp from $host_jp to ($if_external) port smtp
rdr-to $host_apathy port smtp
pass in on $if_external proto tcp to ($if_external) port { https ssh } rdr-to
$host_apathy port ssh
pass in on $if_external proto tcp to ($if_external) port imaps rdr-to
$host_apathy port imaps

pass in on $if_external inet proto icmp to ($if_external:0) icmp-type echoreq
pass in on $if_external inet proto { tcp udp } to ($if_external:0) port domain
keep state (max 128)

pass in on $if_external inet proto udp from port isakmp to ($if_external:0)
port isakmp
pass in on $if_external inet proto esp to ($if_external:0)

pass out on $if_external from ($if_external:0)
match out on $if_external inet from { $if_wired:network $if_wireless:network }
nat-to ($if_external:0)
pass out quick on $if_external inet proto tcp to port { 80 443 } scrub
(max-mss 1280)
pass out on $if_external

pass on internal
pass in quick on internal proto tcp to port ftp rdr-to 127.0.0.1 port 8021

Reply | Threaded
Open this post in threaded view
|

Re: pf change in upgrade47.html

Peter Hessler
In reply to this post by Rod Whitworth-3
On 2010 May 12 (Wed) at 21:28:03 +1000 (+1000), Rod Whitworth wrote:
: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.

The ruleset I use on my laptop (which sometimes provides network for
experimental boxes), is simply thus:


pass                    # to establish keep-state

# By default, do not permit remote connections to X11
block in on ! lo0 proto tcp to port 6000:6010

match out log on egress from !(egress) to any nat-to (egress:0)



--
One is not superior merely because one sees the world as odious.
                -- Chateaubriand (1768-1848)

Reply | Threaded
Open this post in threaded view
|

Re: pf change in upgrade47.html

roberth-5
In reply to this post by Rod Whitworth-3
On Wed, 12 May 2010 21:28:03 +1000
"Rod Whitworth" <[hidden email]> wrote:

> On Wed, 12 May 2010 13:05:15 +0200, Robert wrote:

> >http://www.openbsd.org/faq/current.html#20090901
> >http://marc.info/?l=openbsd-misc&m=125181847818600&w=2
> >
>
> Have you actually written and tested a ruleset using either of those
> documents?
> If so please show us.

(oh, you didn't sent this only to me offlist, once more for the ml)

I am sending this through an OpenBSD firewall with match nat...
Yes, i changed the old syntax prompted by the commit and the "following
-current" faq.

> 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.

I didn't read up on the whole thread.
Only wondered what is so hard about changing the nat line to the new
syntax.

Here would be a condensed version of what i am actually running in my
adsl gateway. (striped and generalised)

IF_EXT = "pppoe0"
IF_INT = "sk0"
antispoof for $IF_EXT inet
set skip on lo0
match in all scrub (no-df)
match out on $IF_EXT all scrub (no-df random-id max-mss 1440)
match out on $IF_EXT inet from any to ! $IF_INT:network nat-to ($IF_EXT)
block log all
block quick inet6 all
pass in  on $IF_INT
pass out on $IF_EXT

Not minimal and generic enough to make into a default cfg, but simple
with some nice to have stuff left.

Reply | Threaded
Open this post in threaded view
|

Re: pf change in upgrade47.html

J.C. Roberts-3
In reply to this post by Rod Whitworth-3
On Wed, 12 May 2010 21:28:03 +1000 "Rod Whitworth"
<[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: pf change in upgrade47.html

J.C. Roberts-3
On Wed, 12 May 2010 07:46:59 -0700 "J.C. Roberts"
<[hidden email]> wrote:
> 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

It seems the ppp issue is because I botched the syntax. It should be:

        match out on egress from !(egress) nat-to (egress:0)

Now I need to figure out why...

--
The OpenBSD Journal - http://www.undeadly.org

Reply | Threaded
Open this post in threaded view
|

Re: pf change in upgrade47.html

Stuart Henderson
In reply to this post by Rod Whitworth-3
On 2010-05-10, Rod Whitworth <[hidden email]> wrote:
> The latest pf.conf documentation is written by people who don't need
> documentation but, probably for the first time, they forgot that
> "compleat newbies" need docs that enable them to get things working if
> they RTveryFM.

It's just been done as a conversion from the old syntax style to the
new one by the simplest method of converting, I think it it definitely
use rewriting into a nicer style...

> Just by the way, the default pf.conf for 4.7 has a line that says:
> #pass in quick proto tcp to port ftp rdr-to 127.0.0.1 port 8021
>
> I don't think that line is complete, is it?

that one's okay.

$ echo 'pass in quick proto tcp to port ftp rdr-to 127.0.0.1 port 8021' |
 pfctl -nvf -
pass in quick inet proto tcp from any to any port = ftp flags S/SA keep state rdr-to 127.0.0.1 port 8021

Reply | Threaded
Open this post in threaded view
|

Re: pf change in upgrade47.html

J.C. Roberts-3
On Wed, 12 May 2010 20:18:14 +0000 (UTC) Stuart Henderson
<[hidden email]> wrote:
> > I don't think that line is complete, is it?
>
> that one's okay.
>
> $ echo 'pass in quick proto tcp to port ftp rdr-to 127.0.0.1 port
> 8021' | pfctl -nvf -
> pass in quick inet proto tcp from any to any port = ftp flags S/SA
> keep state rdr-to 127.0.0.1 port 8021

It's valid, but if uncommented in the default pf.conf ruleset, it would
allow anyone to use your ftp-proxy due to the following 'pass' rule.

http://www.openbsd.org/cgi-bin/cvsweb/src/etc/pf.conf?rev=1.49;content-type=text%2Fplain

It would be better to prevent such potential abuse by using the
egress interface group. The trouble is the 'on ...' will not allow
the use of parenthesis since it's denoting a group of interfaces
rather than a group of addresses assigned to interfaces. But this
is easily overcome by using 'from (...)' so when the underlying
address(es) change on any interface in the group, the rule will
reevaluated.

NOTE: At present, I don't understand how pf reacts when interface
groups are changed (interfaces added or deleted).


Index: pf.conf
===================================================================
RCS file: /cvs/src/etc/pf.conf,v
retrieving revision 1.49
diff -N -u -p pf.conf
--- pf.conf 17 Sep 2009 06:39:03 -0000 1.49
+++ pf.conf 12 May 2010 22:25:59 -0000
@@ -8,7 +8,8 @@ set skip on lo
 
 # filter rules and anchor for ftp-proxy(8)
 #anchor "ftp-proxy/*"
-#pass in quick proto tcp to port ftp rdr-to 127.0.0.1 port 8021
+#pass in quick on !egress proto tcp from !(egress) to port ftp \
+# rdr-to 127.0.0.1 port 8021
 
 # anchor for relayd(8)
 #anchor "relayd/*"

Reply | Threaded
Open this post in threaded view
|

Re: pf change in upgrade47.html

Rod Whitworth-3
On Wed, 12 May 2010 15:54:04 -0700, J.C. Roberts wrote:

>On Wed, 12 May 2010 20:18:14 +0000 (UTC) Stuart Henderson
><[hidden email]> wrote:
>> > I don't think that line is complete, is it?
>>
>> that one's okay.
>>
>> $ echo 'pass in quick proto tcp to port ftp rdr-to 127.0.0.1 port
>> 8021' | pfctl -nvf -
>> pass in quick inet proto tcp from any to any port = ftp flags S/SA
>> keep state rdr-to 127.0.0.1 port 8021
>
>It's valid, but if uncommented in the default pf.conf ruleset, it would
>allow anyone to use your ftp-proxy due to the following 'pass' rule.
>
>http://www.openbsd.org/cgi-bin/cvsweb/src/etc/pf.conf?rev=1.49;content-type=text%2Fplain
>
>It would be better to prevent such potential abuse by using the
>egress interface group. The trouble is the 'on ...' will not allow
>the use of parenthesis since it's denoting a group of interfaces
>rather than a group of addresses assigned to interfaces. But this
>is easily overcome by using 'from (...)' so when the underlying
>address(es) change on any interface in the group, the rule will
>reevaluated.


What is wrong with the old rule:
rdr pass on $int_if proto tcp to port ftp -> 127.0.0.1 port 8021
being converted to:
pass in quick on $int_if proto tcp to port ftp rdr-to 127.0.0.1 port
8021
put in a location above any other rule applying to $inf_if  ??

The reason I queried whether the 4.7 construct was correct is that it
applies to traffic from any to any. Even my suggested rule would not be
universal. Maybe there's an ftp server on the LAN.


*** NOTE *** Please DO NOT CC me. I <am> subscribed to the list.
Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou.

Rod/
---
This life is not the real thing.
It is not even in Beta.
If it was, then OpenBSD would already have a man page for it.

Reply | Threaded
Open this post in threaded view
|

Re: pf change in upgrade47.html

J.C. Roberts-3
On Thu, 13 May 2010 09:45:47 +1000 "Rod Whitworth"
<[hidden email]> wrote:

> What is wrong with the old rule:
> rdr pass on $int_if proto tcp to port ftp -> 127.0.0.1 port 8021
> being converted to:
> pass in quick on $int_if proto tcp to port ftp rdr-to 127.0.0.1 port
> 8021
> put in a location above any other rule applying to $inf_if  ??
>
> The reason I queried whether the 4.7 construct was correct is that it
> applies to traffic from any to any. Even my suggested rule would not
> be universal. Maybe there's an ftp server on the LAN.

Yep, the 'pass in quick' with 'any to any' in the default pf.conf
ruleset is bad juju, and hence the patch I posted. If deemed acceptable
and committed, I'll patch update47.html accordingly.

But to answer your question, the interface names such as "int_if" were
intentionally removed since we can now create hardware independent
rulesets by using interface groups. If you're overly accustomed to
using interface names like '$int_if' it takes a bit to wrap your head
around the new interface groups, but they're really cool.

--
The OpenBSD Journal - http://www.undeadly.org

Reply | Threaded
Open this post in threaded view
|

Re: pf change in upgrade47.html

Claudio Jeker
In reply to this post by J.C. Roberts-3
On Wed, May 12, 2010 at 03:54:04PM -0700, J.C. Roberts wrote:

> On Wed, 12 May 2010 20:18:14 +0000 (UTC) Stuart Henderson
> <[hidden email]> wrote:
> > > I don't think that line is complete, is it?
> >
> > that one's okay.
> >
> > $ echo 'pass in quick proto tcp to port ftp rdr-to 127.0.0.1 port
> > 8021' | pfctl -nvf -
> > pass in quick inet proto tcp from any to any port = ftp flags S/SA
> > keep state rdr-to 127.0.0.1 port 8021
>
> It's valid, but if uncommented in the default pf.conf ruleset, it would
> allow anyone to use your ftp-proxy due to the following 'pass' rule.
>
> http://www.openbsd.org/cgi-bin/cvsweb/src/etc/pf.conf?rev=1.49;content-type=text%2Fplain
>
> It would be better to prevent such potential abuse by using the
> egress interface group. The trouble is the 'on ...' will not allow
> the use of parenthesis since it's denoting a group of interfaces
> rather than a group of addresses assigned to interfaces. But this
> is easily overcome by using 'from (...)' so when the underlying
> address(es) change on any interface in the group, the rule will
> reevaluated.
>

I don't understand this. on does not need () at all. Why should it?
Both groups and interfaces are always evaluated. OK maybe if you destroy
and recreate interfaces you use in pf.conf then you will need to reload
the ruleset.

> NOTE: At present, I don't understand how pf reacts when interface
> groups are changed (interfaces added or deleted).
>

pf will pick up the changes automagically.

>
> Index: pf.conf
> ===================================================================
> RCS file: /cvs/src/etc/pf.conf,v
> retrieving revision 1.49
> diff -N -u -p pf.conf
> --- pf.conf 17 Sep 2009 06:39:03 -0000 1.49
> +++ pf.conf 12 May 2010 22:25:59 -0000
> @@ -8,7 +8,8 @@ set skip on lo
>  
>  # filter rules and anchor for ftp-proxy(8)
>  #anchor "ftp-proxy/*"
> -#pass in quick proto tcp to port ftp rdr-to 127.0.0.1 port 8021
> +#pass in quick on !egress proto tcp from !(egress) to port ftp \
> +# rdr-to 127.0.0.1 port 8021

pass in quick on !egress proto tcp to port ftp rdr-to 127.0.0.1 port 8021
is good enough. There is no reason for the "from !(egress)" since that
would assume that someone is spoofing your external IP in your internal
network.

>  
>  # anchor for relayd(8)
>  #anchor "relayd/*"
>

--
:wq Claudio

Reply | Threaded
Open this post in threaded view
|

Re: pf change in upgrade47.html

Henning Brauer
In reply to this post by Rod Whitworth-3
I plain don't understand your problem, nor was it clear was yur
question actually was.

* Rod Whitworth <[hidden email]> [2010-05-12 11:39]:
> >maybe the idea was that it's simpler to write pass/block rules for your
> >traffic, then just match the nat stuff. i don;t know.
> And neither does anyone else who hangs out here, it seems.

pass / block and match nat-to afterwards works fine.
so does doing that very same match nat-to beforehands.
so does doing the nat-to on the pass rules.

--
Henning Brauer, [hidden email], [hidden email]
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting

Reply | Threaded
Open this post in threaded view
|

Re: pf change in upgrade47.html

Henning Brauer
In reply to this post by J.C. Roberts-3
* J.C. Roberts <[hidden email]> [2010-05-13 00:57]:
> NOTE: At present, I don't understand how pf reacts when interface
> groups are changed (interfaces added or deleted).

it doesn't.
it doesn't have to.
that stuff happens elsewhere :) the joys of proper design.

if you have an "on egress" rule, it will apply to any interface in the
egress group at the time the packet in question is evaluated by pf.

--
Henning Brauer, [hidden email], [hidden email]
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting

Reply | Threaded
Open this post in threaded view
|

Re: pf change in upgrade47.html

Henning Brauer
In reply to this post by J.C. Roberts-3
* J.C. Roberts <[hidden email]> [2010-05-13 02:09]:
> If you're overly accustomed to
> using interface names like '$int_if' it takes a bit to wrap your head
> around the new interface groups, but they're really cool.

your definition of "new" is interesting...

date: 2004/10/11 10:13:49;  author: henning;  state: Exp;  lines: +91 -66

--
Henning Brauer, [hidden email], [hidden email]
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting

Reply | Threaded
Open this post in threaded view
|

Re: pf change in upgrade47.html

Henning Brauer
In reply to this post by Claudio Jeker
* Claudio Jeker <[hidden email]> [2010-05-13 09:16]:
> OK maybe if you destroy
> and recreate interfaces you use in pf.conf then you will need to reload
> the ruleset.

for match/block/pass on? no, definately not.
for using interface or group names that expand to addresses, only if
you don't use the () notation.

--
Henning Brauer, [hidden email], [hidden email]
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting