Re: Learning how-to pf "right"
Kenneth Gober <[email protected]> Wed, 13 May 2015 09:29:44 -0400
| Newsgroups | gmane.os.openbsd.pf |
|---|---|
| Message-ID | <CANHrbpe77aqMWoLUxR3YegqmfmoOYCgZLJCDdtbTd62BVAVAtA@mail.gmail.com> |
--001a1145789ca998e30515f69ab3 Content-Type: text/plain; charset=UTF-8 On Tue, May 12, 2015 at 6:36 PM, Dennis Steinkamp <[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 --001a1145789ca998e30515f69ab3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T= ue, May 12, 2015 at 6:36 PM, Dennis Steinkamp <span dir=3D"ltr"><<a href= =3D"mailto:[email protected]" target=3D"_blank">dennis@lightandshado= w.tv</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> =20 =20 =20 <div bgcolor=3D"#FFFFFF" text=3D"#000000">As far as i know, in order to g= rant my client machines in the local network access to the internet the keyword<b> "any"</b> in ru= le 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"#88= 8888"><br> </font></span></div> </blockquote></div><br></div><div class=3D"gmail_extra">actually, the rules= et you have listed does exactly this. =C2=A0the reason is, in order for cli= ent traffic to reach its destination, it has to make it past *two* pass rul= es, it must "pass in" to get into your pf router, and then it mus= t "pass out" to go on to its destination.</div><div class=3D"gmai= l_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 tr= affic will be allowed to pass on to any other interfaces. =C2=A0you could g= o 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 $pr= ivate_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 ru= les 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=A0eithe= r way works, as long as it gets blocked *somewhere*.</div><div class=3D"gma= il_extra"><br></div><div class=3D"gmail_extra">-ken</div></div> --001a1145789ca998e30515f69ab3--