Re: pf change in upgrade47.html
* J.C. Roberts list-...@designtools.org [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, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: pf change in upgrade47.html
I plain don't understand your problem, nor was it clear was yur question actually was. * Rod Whitworth glis...@witworx.com [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, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: pf change in upgrade47.html
* J.C. Roberts list-...@designtools.org [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, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: pf change in upgrade47.html
* Claudio Jeker cje...@diehard.n-r-g.com [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, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: pf change in upgrade47.html
On Wed, May 12, 2010 at 03:54:04PM -0700, J.C. Roberts wrote: On Wed, 12 May 2010 20:18:14 + (UTC) Stuart Henderson s...@spacehopper.org 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 - 1.49 +++ pf.conf 12 May 2010 22:25:59 - @@ -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
Re: pf change in upgrade47.html
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.
Re: pf change in upgrade47.html
On Wed, 12 May 2010 19:35:14 +1000 Rod Whitworth glis...@witworx.com 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-miscm=125181847818600w=2
Re: pf change in upgrade47.html
On Wed, 12 May 2010 13:05:15 +0200, Robert wrote: On Wed, 12 May 2010 19:35:14 +1000 Rod Whitworth glis...@witworx.com 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-miscm=125181847818600w=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.
Re: pf change in upgrade47.html
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
Re: pf change in upgrade47.html
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)
Re: pf change in upgrade47.html
On Wed, 12 May 2010 21:28:03 +1000 Rod Whitworth glis...@witworx.com 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-miscm=125181847818600w=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.
Re: pf change in upgrade47.html
On Wed, 12 May 2010 21:28:03 +1000 Rod Whitworth glis...@witworx.com 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
Re: pf change in upgrade47.html
On Wed, 12 May 2010 07:46:59 -0700 J.C. Roberts list-...@designtools.org 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
Re: pf change in upgrade47.html
On 2010-05-10, Rod Whitworth glis...@witworx.com 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
Re: pf change in upgrade47.html
On Wed, 12 May 2010 20:18:14 + (UTC) Stuart Henderson s...@spacehopper.org 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 - 1.49 +++ pf.conf 12 May 2010 22:25:59 - @@ -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/*
Re: pf change in upgrade47.html
On Wed, 12 May 2010 15:54:04 -0700, J.C. Roberts wrote: On Wed, 12 May 2010 20:18:14 + (UTC) Stuart Henderson s...@spacehopper.org 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.
Re: pf change in upgrade47.html
On Thu, 13 May 2010 09:45:47 +1000 Rod Whitworth glis...@witworx.com 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
Re: pf change in upgrade47.html
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
