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
