PF Rule diagnostics - Halp!

museur

New Member


Messages: 18

Hi there all,

first post here so just say if I've a mistake, besides, well... my pf rules. 😀

I've created this rule configuration while I was experimenting with OpenBSD. I'm not a programmer, just a consumer so I don't even know what these are meant for other than from what I read for about half an hour of various sources in the interwebs.

I don't even know how to diagnose it, other than my observation that browser is dead slow, cannot stream stuff without hanging every few seconds and torrent client keeps speeding up and then dropping to zero before again starting up. I'm suspecting because the rules include keeping the connection for only about a short while but hey, I'm no expert here.

Can someone just fix this up without breaking its approach/philosophy whatever the terminology is, or maybe should I just abandon it altogether?

Here are my rules:
Code:
set skip on lo
set block-policy drop
set loginterface wlan0
set state-policy if-bound
set fingerprints "/etc/pf.os"
set ruleset-optimization none
set optimization aggressive
set timeout { adaptive.end 120000, interval 2, tcp.tsdiff 5, tcp.first 5, tcp.closing 5, tcp.closed 5, tcp.finwait 5, tcp.established 600 }
antispoof for lo0
antispoof for wlan0 
#scrub in on wlan0 all fragment reassemble
block drop in log quick on ! wlan0 inet from (wlan0:network) to any
block log on wlan0
block return
block in from no-route to any
block in quick from urpf-failed to any
block return in on ! lo0 proto tcp to port 6000:6010
pass out on wlan0 proto { tcp, udp, icmp } from any to any modulate state
output of pfctl is as follows:
Code:
set skip on lo
set block-policy drop
set loginterface wlan0
set state-policy if-bound
set fingerprints "/etc/pf.os"
set ruleset-optimization none
set optimization aggressive
set timeout { adaptive.end 120000, interval 2, tcp.tsdiff 5, tcp.first 5, tcp.closing 5, tcp.closed 5, tcp.finwait 5, tcp.established 600 }
antispoof for lo0
antispoof for wlan0
#scrub in on wlan0 all fragment reassemble
block drop in log quick on ! wlan0 inet from (wlan0:network) to any
block log on wlan0
block return
block in from no-route to any
block in quick from urpf-failed to any
block return in on ! lo0 proto tcp to port 6000:6010
pass out on wlan0 proto { tcp, udp, icmp } from any to any modulate state
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 9,283
Messages: 33,826

I'm not a programmer, just a consumer so I don't even know what these are meant for other than from what I read for about half an hour of various sources in the interwebs.
Remove it. All of it. Only add the things you actually need to configure and what you understand. Just stick to basic rules and assume the system itself is already "tuned". Don't tune for the sake of tuning, especially if you don't know what you're doing.

The only rules that should be left are these:
Code:
set skip on lo0

block in on wlan0 
pass out on wlan0
 
OP
M

museur

New Member


Messages: 18

Only add the things you actually need to configure and what you understand. .. Don't tune for the sake of tuning, especially if you don't know what you're doing.
I was just looking around and thought that the idea of modulating connections and dropping them after a short while a good conduct for a firewall rather than just assuming it will do it since with OpenBSD documentation it is as detailed as a kitch toilet decoration, ironically, considering the whole approach of it is around safest and cleanest defaults.
Thanks for answering.
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 9,283
Messages: 33,826

thought that the idea of modulating connections and dropping them after a short while a good conduct for a firewall
In theory it is, but in practice it causes a lot of problems.
 
OP
M

museur

New Member


Messages: 18

...it causes a lot of problems.
So I think that's what I have experienced. Sorry to bother but, just curious if does ipfw in workstation mode or defaults of pf do anything like this modulate and drop approach? Maybe within a longer time? Because, it seemed to me is a good way to prevent a "advertising" pop-up webkit my system.
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 9,283
Messages: 33,826

Sorry to bother but, just curious if does ipfw in workstation mode or defaults of pf do anything like this modulate and drop approach?
To be honest, I don't know. If there is, it's likely going to cause the exact same kind of issues. But as far as I know the 'standard' workstation ruleset is fairly basic, it simply blocks everything incoming and allows everything outgoing.
 
OP
M

museur

New Member


Messages: 18

After I followed your advice on approaching this, I've settled in a working ruleset, albeit without a copy-paste from you. Since you seem to like the idea, this one does not create any problems while browsing web and using torrents on a laptop without any ssh or network or lan.

If anyone searched the internet for a ruleset maybe these may be of us to some rookie like me...

We add this so we do not let pinging party know that we are blocking them:
Code:
set block-policy drop
This one are for how long the connections (or maybe states) are kept in place:
Code:
set timeout { adaptive.end 120000, interval 2, tcp.tsdiff 5, tcp.first 5, tcp.closing 5, tcp.closed 5, tcp.finwait 5, tcp.established 600 }
This one is (I'm half-guessing) to keep states only if the packet coming in is in accordance with what the pf expects:
Code:
set state-policy if-bound
We add modulate state so it modulates the state if to keep it or not, whatever hell that of means:
Code:
pass out on wlan0 modulate state
This is why Dr. Kaczynski had universities campus adresses written on packages:
Code:
block in from no route to any
This blocks any if urpf (I still don't know what it is) has not approved of it:
Code:
block in quick from urpf-failed to any
These prevent people from watching porn with you simultaniously:
Code:
block in quick proto tcp to port 6000:6010
block out quick proto tcp to port 6000:6020
 
OP
M

museur

New Member


Messages: 18

No, no, no! Now I've got pf library trying to meggle with iwm0 instead of wlan0 for using default, is this not a maintainer issue? Is it not supposed to be "tuned"?
 
Top