Re: Learning how-to pf "right"
Dennis Steinkamp <[email protected]> Wed, 13 May 2015 17:03:12 +0200
| Newsgroups | gmane.os.openbsd.pf |
|---|---|
| Message-ID | <[email protected]> |
--------------050901070209090706060200 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Hi Ken, thank you very much for explaining things a little bit more detailed. I wasn`t aware of the fact that traffic has to pass two rules to reach its endpoint but after making a little drawing that illustrated how the packets flow it was pretty obvious. Funny thing is that this is exactly the kind of misunderstanding the book mentions early on and thanks to your explanation i now understand what it means. Thanks. Dennis Am 13.05.2015 um 15:29 schrieb Kenneth Gober: > On Tue, May 12, 2015 at 6:36 PM, Dennis Steinkamp > <[email protected] <mailto:[email protected]>> wrote: > > As far as i know, in order to grant my client machines in the > local network access to the internet the keyword*"any"* in rule > 4.) is neccessary for obvious reasons. But of course "any" would > imply all other interfaces to where i maybe want to restrict > accessx to. > My understanding was, i would just grant my clients access to the > WAN interface (or the egress interface) so that they can surf the > web etc. but at the same time are locked out to access other > interfaces, until i create rules for it, thats the kind of > configuration i am probably used to, due to my pfsense background. > My question therefor is, how can i achieve a similar configuration > with "pf" or maybe i am just interested what the best/common > practice for that scenario is. > > > actually, the ruleset you have listed does exactly this. the reason > is, in order for client traffic to reach its destination, it has to > make it past *two* pass rules, it must "pass in" to get into your pf > router, and then it must "pass out" to go on to its destination. > > your rules allow any traffic in, but then only allow traffic to the > Internet to go out. since you don't have any kind of "pass out on > $private_if" rules, no traffic will be allowed to pass on to any other > interfaces. you could go to the trouble of adding block rules (e.g. > block in quick on $int_if from $int_net to $private_net) but since you > don't have any pass out on $private_if rules anyway, they would be > spurious right now. > > once you add pass out rules for your private interface(s), at that > point you can decide whether you want to block client traffic on its > way in, or on its way out. either way works, as long as it gets > blocked *somewhere*. > > -ken --------------050901070209090706060200 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by insomnia.benzedrine.ch id t4DFU13F025457 <html> <head> <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Ty= pe"> </head> <body bgcolor=3D"#FFFFFF" text=3D"#000000"> Hi Ken,<br> <br> thank you very much for explaining things a little bit more detailed.<br> I wasn`t aware of the fact that traffic has to pass two rules to reach its endpoint but after making a little drawing that illustrated how the packets flow it was pretty obvious.<br> Funny thing is that this is exactly the kind of misunderstanding the book mentions early on and thanks to your explanation i now understand what it means.<br> <br> Thanks.<br> <br> Dennis<br> <br> <div class=3D"moz-cite-prefix">Am 13.05.2015 um 15:29 schrieb Kenneth Gober:<br> </div> <blockquote cite=3D"mid:[email protected]= l.com" type=3D"cite"> <div dir=3D"ltr"> <div class=3D"gmail_extra"> <div class=3D"gmail_quote">On Tue, May 12, 2015 at 6:36 PM, Dennis Steinkamp <span dir=3D"ltr"><<a moz-do-not-send=3D"true" href=3D"mailto:[email protected]" target=3D"_blank= ">[email protected]</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div bgcolor=3D"#FFFFFF" text=3D"#000000">As far as i know,= in order to grant my client machines in the local network access to the internet the keyword<b> "any"</b> in rule 4.) is neccessary for obvious reasons. But of course "any" would imply all other interfaces to where i maybe want to restrict accessx to. <br> My understanding was, i would just grant my clients access to the WAN interface (or the egress interface) so that they can surf the web etc. but at the same time are locked out to access other interfaces, until i create rules for it, thats the kind of configuration i am probably used to, due to my pfsense background.<br> My question therefor is, how can i achieve a similar configuration with "pf" or maybe i am just interested what the best/common practice for that scenario is.<span class=3D"HOEnZb"><font color=3D"#888888"><br> </font></span></div> </blockquote> </div> <br> </div> <div class=3D"gmail_extra">actually, the ruleset you have listed does exactly this. =C2=A0the reason is, in order for client tra= ffic to reach its destination, it has to make it past *two* pass rules, it must "pass in" to get into your pf router, and then it must "pass out" to go on to its destination.</div> <div class=3D"gmail_extra"><br> </div> <div class=3D"gmail_extra">your rules allow any traffic in, but then only allow traffic to the Internet to go out. =C2=A0since = you don't have any kind of "pass out on $private_if" rules, no traffic will be allowed to pass on to any other interfaces. =C2=A0you could go to the trouble of adding block rules (e.g. b= lock in quick on $int_if from $int_net to $private_net) but since you don't have any pass out on $private_if rules anyway, they would be spurious right now.</div> <div class=3D"gmail_extra"><br> </div> <div class=3D"gmail_extra">once you add pass out rules for your private interface(s), at that point you can decide whether you want to block client traffic on its way in, or on its way out. =C2=A0either way works, as long as it gets blocked *somewhere*.= </div> <div class=3D"gmail_extra"><br> </div> <div class=3D"gmail_extra">-ken</div> </div> </blockquote> <br> </body> </html> --------------050901070209090706060200--