PF A weird PF whitelist problem

K

kalleboy

Under FreeBSD 13, I'm using PF and it was working fine till today.

I've a <whitelist> table that I suspect it's not really working with PF.

Any IPs within that file (table <whitelist> persist file "/var/pf/whitelist.txt") seems still getting blocked by PF,

as I see through real-time by the help of:

tcpdump -n -e -ttt -i pflog0 command

sample line: 00:00:00.000000 rule 3/0(match): block in on igb0: ip.address.that.exist.in.whitelist > myserverip.443: Flags [R], seq 2609505599, win 0, length 0

Now, my question is, how can I make sure IPs within whitelist.txt are not being blocked never by PF?

pfctl -t whitelist -T show -v shows to me all my whitelist IPs with: "Cleared: Tue Jan 4 16:30:32 2022" - what does "cleared" mean? If that'd help..

P.S: My respective line related to the whitelist table in pf.conf: pass quick on $ext_if from <whitelist> to any keep state
(I did move it to the top rules, like it was first one, and then comes: block return in log all - didn't work neither.)

That's the output of "pfctl -sr" : https://bsd.to/QcLx/raw

and this is my pf.conf: https://bsd.to/BgPO/raw

Any suggestion would be much appreciated.

Thanks.
 
Your fail2ban anchor sits before your whitelist rule. So it's possible fail2ban flagged an IP from your whitelist and is blocking it. Either put your whitelist rule before the fail2ban anchor or configure a whitelist on fail2ban so it never flags on it.

If you look at the output from pfctl -sr, rule #2 and #3 (the one that's blocking your traffic) are:
Code: 
block drop in on ! igb0 inet from 49.12.126.xx/26 to any
block drop in inet from 49.12.126.xx to any
Those rules aren't in your pf.conf. They don't appear to be part of fail2ban (that anchor comes after it). Where are they coming from? The antispoof line perhaps? Looks like you're receiving traffic on igb0 that's not expected because that network is tied to a different interface.
 
Hi SirDice.

Failban has an empty table well, not ready yet at all..

Now I minimized the "block" rules, removed almost everything, the resulting rules list is (pfctl -sr output): https://bsd.to/mfee/raw - but still same.

Well, I hope I'm verifying it in a right way.

After modifying the pf.conf file, I restart the pf service, then I check the log in real-time with: tcpdump -n -e -ttt -i pflog0 and getting a line like;

00:00:00.093747 rule 1/0(match): block in on igb0: the.ip.in.my.whitelist.63788 > myserverip.443: Flags [R], seq 2025978074, win 0, length 0
then I assume it still gets blocked..
 
After reading the documentation I'm convinced it's your antispoof line that's blocking the traffic. I rarely use antispoof so I had to look it up.

Code: 
     For example, the line

           antispoof for lo0

     expands to

           block drop in on ! lo0 inet from 127.0.0.1/8 to any
           block drop in on ! lo0 inet6 from ::1 to any
Code: 
block drop in on ! igb0 inet from 49.12.126.xx/26 to any
block drop in inet from 49.12.126.xx to any
Those are consistent with antispoof for igb0 if igb0 has 49.12.126.xx/26. As it's rule #3 (block drop in inet from 49.12.126.xx to any) that's blocking your traffic it's the antispoof rule that's causing problems for you.
 
SirDice said:
Code: 
block drop in on ! igb0 inet from 49.12.126.xx/26 to any
block drop in inet from 49.12.126.xx to any
Where are they coming from?
Click to expand...


Yes, it's the line: antispoof for $ext_if inet

after activated it again, getting with pfctl -sr:

block drop in on ! igb0 inet from 49.12.126.xx/26 to any
block drop in inet from 49.12.126.xxx to any (my server IP)

However, disabling that line didn't help me unban my IPs in "whitelist" table.. What could prevent those IPs being passed, according to my last simple configuration like: https://bsd.to/mfee/raw - any idea? Although the passing rule "pass on igb0 from <whitelist> to any flags S/SA keep state" seems the first one..
 
kalleboy said:
However, disabling that line didn't help me unban my IPs in "whitelist" table..
Click to expand...
Set your whitelist rule as the first rule. As it's a quick rule none of the other rules will be checked if something matches.
 
What is the output from pfctl -t whitelist -T show | grep 49.12.126 ?

Code: 
pass on igb0 from <whitelist> to any flags S/SA keep state
Add the quick keyword to this rule. You want to "short-circuit" if anything matches, in other words, if it's on the whitelist the rest of the ruleset should be ignored.
 
I think your "to any keep state" rule includes hidden "flags S/SA" and that's the reason why this rule doesn't apply to your packet with "Flags [R]". Try to add "flags any", but I'm not sure this is a correct solution.
 
Added "quick" to the rule and also "flags any". Will check and return the results. Good point @Denis.

Many thanks, both of you.
 
SirDice pfctl -t whitelist -T show | grep 49.12.126 returns nothing, by the way. This is IP network of my dedicated server. Should be whitelisted, or?
 
Denis Shaposhnikov said:
I think your "to any keep state" rule includes hidden "flags S/SA" and that's the reason why this rule doesn't apply to your packet with "Flags [R]". Try to add "flags any", but I'm not sure this is a correct solution.
Click to expand...

You were right, Denis! Adding;

pass quick on $ext_if from <whitelist> to any flags any keep state

solved it, my IPs in whitelist are now passing. These are (IPs in whitelist) actually Cloudflare's IPs proxying for my domain, towards my server. See: https://www.cloudflare.com/ips-v4

Thanks a lot! And thanks SirDice for such a great tip on "quick". Very useful.
 
Yes, "flags any" resolves this situation, but as I told, I'm not sure this is correct solution. It's a mystery for me, why so many TCP packets skipped by flags S/SA. In my pflog I see lOOOOOts of entries like
Code: 
2022-01-04 19:06:12.705639 rule 98/0(match): block in on igb0: 192.168.1.19.64380 > 192.168.1.254.445: Flags [R.], seq 913, ack 1, win 57856, length 0
I can't understand why something sends such tcp packets. It was blocked because pf hasn't any state for this tcp connection. It didn't create a state, because 192.168.1.19.64380 didn't send SYN to 192.168.1.254.445, if I understand it correct. But why did it send [R.] packet without SYN first? And as I told I see lots of such entries from different IP to different IP.
 
@Denis, in my case, that was Cloudflare's IP addresses (my domain hosted&proxied by Cloudflare towards my server) - so seems safe (at least with CF) to do so - I think.
 
You must log in or register to reply here.
Back
Top