Hi Pau, http://www.openbsd.org/faq/pf/
I highly recommend the following books... http://www.bsdly.net/~peter/ https://www.michaelwlucas.com/os/ao2e regards, Daniel On 11/26/2016 08:05 AM, Pau Amaro-Seoane wrote: > Hi Josh et al: > > I have been trying to use tcpdump after applying these rules: > > # cat /etc/pf.conf > match log > block > pass from self to any > > and I get this: > > # tcpdump -ni pflog0 > tcpdump: WARNING: snaplen raised from 116 to 160 > tcpdump: listening on pflog0, link-type PFLOG > > ^C > 0 packets received by filter > 0 packets dropped by kernel > > With those pf.conf rules I am not able to do anything. All outgoing > traffic seems to be blocked. > > Although I have added match log, I must admit that I do not know how > to look at the log... > > Any idea? > > thanks! > > > > > Pau > --- > Group Leader of Theoretical Astrophysics > Max Planck Institute Gravitational Physics > Albert Einstein Institute http://astro-gr.org > > > 2016-06-25 19:43 GMT+02:00 Josh Grosse <j...@jggimi.homeip.net>: >> On Sat, Jun 25, 2016 at 07:16:29PM +0200, Pau Amaro-Seoane wrote: >>> Dear Josh: >>> >>> Apologies for being vague. >>> >>> I mean that I have yours now: >>> >>> $ cat /etc/pf.conf >>> block >>> pass from self to any >>> #a. Rule 1 blocks all traffic. >>> #b. Rule 2 passes all traffic originating on the laptop, going anywhere. >>> >>> If I enable them with >>> >>> $ pfctl -e >>> >>> I can ping anything, but no browser will open anything >>> >>> If I run >>> >>> $ pfctl -d >>> pf disabled >>> >>> Then of course everything works just fine. >>> >>> Pau >> >> I am at a loss to explain your issue, then. I have just >> tested that exact 2-line ruleset here, and am able >> to connect to a nameserver for address resolution, connect >> to websites with a browser, and connect to an Email client >> with ssh in order to post this message. >> >> Please post additional information. >> >> 1. Post your dmesg(8). >> >> $ dmesg > /path/to/my.dmesg >> >> This will show us the exact version of the OS you are >> using, when it was built, and your network interfaces, >> among other information. >> >> 2. Post your ifconfig(8). >> >> $ ifconfig > /path/to/my.ifconfig >> >> This will show us how your network interfaces are >> configured. Feel free to redact any "real" Internet >> facing addresses, if your laptop is on the Internet >> rather than on a private network that routes to the >> Internet. >> >> 3. Optionally, collect information to determine if >> desired traffic is being blocked by PF. >> >> a. Add this new rule above the other two: >> >> match log >> >> This will log all pass and block rules as they >> match through your pflog(4) interface. >> >> b. Use tcpdump(8) to inspect pass/block rules as they >> are applied. The following example command will >> do this "live" while you attempt to use your network, >> output goes to the local terminal window and also to a file. >> >> # tcpdump -ni pflog0 | tee /path/to/my.tcpdump.log >> >>> 2016-06-25 18:35 GMT+02:00 Josh Grosse <j...@jggimi.homeip.net>: >>>> On Sat, Jun 25, 2016 at 06:18:18PM +0200, Pau Amaro-Seoane wrote: >>>>> thanks, Josh! >>>>> >>>>> Although with these rules I seem not to be able to send e-mails.... >>>> >>>> Which rules? Mine or yours? Please remember I only have what you >>>> state in your Emails for a problem description. >>>> >>>> All I know is that you have a laptop running OpenBSD, and that >>>> when you use your "six rule" ruleset, all traffic would be blocked. >>>> If you use your "five rule" ruleset, no traffic would be blocked. >>>> If you use Stephen's recommended additional line, and build a >>>> "seven rule" ruleset that ends with his pass out rule, or, end >>>> with my pass from self to any rule, or you use my simple two >>>> rule exampe, with either the pass out or the pass from self to any >>>> rule, you should have a working ruleset for the use case you >>>> described. >>>> >>>>> ... For >>>>> instance, gmail complains about not being able to do so, and it also >>>>> says that I seem to have a very old browser, and should load a >>>>> simplistic html version of gmail. When I disable pf with pfctl -d, the >>>>> email is sent and gmail does not complain about anything. Maybe the >>>>> block is also blocking sites from delivering cookies? >>>> >>>> I can only guess that your normalization ("scrub") directive is the >>>> cause of this symptom. >>>> >>>>> 2016-06-25 15:39 GMT+02:00 Josh Grosse <j...@jggimi.homeip.net>: >>>>>> On Sat, Jun 25, 2016 at 09:28:16AM +0200, Pau Amaro-Seoane wrote: >>>>>>> pf is disabled, yes... >>>>>>> >>>>>>> So, then I would have to remove the last line. I need to download and >>>>>>> upload things, but do not want to allow any remote connection to the >>>>>>> laptop. I guess this configuration fulfills my needs? >>>>>> >>>>>> No. If you remove the rule that blocks all traffic, what will PF do? >>>>>> >>>>>> 1) Ignore lo0 traffic >>>>>> 2) Scrub all other traffic >>>>>> >>>>>> Nothing else. >>>>>> >>>>>> Let's look at your six-line rule set in detail: >>>>>> >>>>>> a. Rules 1 and 2 set the macros $wifi and $wired, which are never used. >>>>>> b. Rule 3 sets the option to respond to blocked TCP traffic with RST >>>>>> and respond with ICMP UNREACHABLE to other blocked traffic. >>>>>> c. Rule 4 instructs PF to ignore traffic on the loopback interface. >>>>>> d. Rule 5 requests packet normalization >>>>>> e. Rule 6 blocks all traffic, except on the ignored loopback interface, >>>>>> and logs them through your pflog(4) interface. >>>>>> >>>>>> Keep in mind, I can only answer questions based upon the information >>>>>> you provide. Based solely on your laptop use-case description, here is >>>>>> a very simple ruleset: >>>>>> >>>>>> block >>>>>> pass from self to any >>>>>> >>>>>> a. Rule 1 blocks all traffic. >>>>>> b. Rule 2 passes all traffic originating on the laptop, going anywhere. >>>>>> >>>>>> How does PF manage inbound traffic with this? >>>>>> >>>>>> Because passed traffic keeps state by default, response packets >>>>>> will be passed. For stateless protocols like UDP or ICMP, state is >>>>>> maintained via timers. >>>>>> >>>>>> In my previous reply to you, I'd reminded you that in PF, the last >>>>>> matching rule wins. When an inbound packet is part of an existing >>>>>> state (TCP session, or within a response timeout window), the rule >>>>>> set will not be tested and the packet will flow. When an inbound >>>>>> packet is not part of any existing state, PF will test it against >>>>>> the rule set and the first rule (block) will be the last one >>>>>> which matches. >>>>>> >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> 2016-06-23 19:20 GMT+02:00 Josh Grosse <j...@jggimi.homeip.net>: >>>>>>>> On 2016-06-23 10:29, Pau Amaro-Seoane wrote: >>>>>>>>> >>>>>>>>> Hi... with these pf rules >>>>>>>>> >>>>>>>>> wifi=iwn0 >>>>>>>>> wired=em0 >>>>>>>>> set block-policy return >>>>>>>>> set skip on lo0 >>>>>>>>> match in all scrub >>>>>>>>> block log all >>>>>>>>> >>>>>>>>> I can ping www.google.com without loss >>>>>>>>> but no browser opens any URL... do you know what's going on? >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> >>>>>>>>> Pau >>>>>>>>> _______________________________________________ >>>>>>>>> Openbsd-newbies mailing list >>>>>>>>> Openbsd-newbies@sfobug.theapt.org >>>>>>>>> http://mailman.theapt.org/listinfo/openbsd-newbies >>>>>>>> >>>>>>>> >>>>>>>> Hi, Pau. Last matching rule wins, and your last rule blocks all >>>>>>>> traffic. >>>>>>>> >>>>>>>> The only packets that will pass through PF are those that use the >>>>>>>> loopback >>>>>>>> interface lo0. So either that is not your entire rule set, or PF is >>>>>>>> disabled. >>>>>>>> >>>>>>>> Ping requires the passing of ICMP protocol ECHO packates, while address >>>>>>>> resolution of www.google.com requires the passing of DNS protocol >>>>>>>> packets via UDP port 53. > _______________________________________________ > Openbsd-newbies mailing list > Openbsd-newbies@sfobug.theapt.org > http://mailman.theapt.org/listinfo/openbsd-newbies > _______________________________________________ Openbsd-newbies mailing list Openbsd-newbies@sfobug.theapt.org http://mailman.theapt.org/listinfo/openbsd-newbies