Solved pf is still passing traffic after anchor is cleared

[tOsYZYny]

I split out my entire ruleset into various anchors for more fine-grained control, but it does not seem to work as expected. In particular, I have an anchor that allows traffic to the specific VPN service I use for work at a preset time of day.

It is also worth pointing out that my generic web anchor has a table of devices it passes traffic to/from and this device is not included in that table (nor is it added dynamically). The rationale being that all traffic should only be going through the VPN (the exceptions to that are allowing traffic to Apple for periodic updates, Microsoft for teams and outlook). Those anchors are for specific CIDR blocks and ports for specific devices.

The anchor gets cleared out after hours with the below commands.

pfctl -a e_10_work -F all
pfctl -a e_10_work -F states

After, I run pfctl -a e_10_work -sr and see that it is indeed empty. And, it appears like it is blocking traffic, but then shortly thereafter, I am able to get out. Is there something else I need to do? At the very end of my ruleset, I have a block rule which should effectively block and log the traffic on a pflog interface for inspection.

EDIT:
My entire ruleset is (removed entire path for brevity and the listing of the other anchors, each anchor allows a specify type of traffic, ie. ssh to github, teams ports for microsoft teams, imap/smtp for email to specific hosts, etc):

include policy
table web_client table/web_client.generated
include pre-rule
anchor e_10_work
load anchor e_10_work from anchor/e.10.work
...
include post-rule

policy:

set skip on {lo epair0a}

# hitting a table limit @ 131072
set limit { states 1000000, frags 1000000, src-nodes 1000000, table-entries 1000000 }

pre-rule:

# [URL]https://docstore.mik.ua/manuals/openbsd/faq/pf/scrub.html[/URL]
scrub log on wan all reassemble tcp fragment reassemble no-df random-id

# [URL]https://daemon-notes.com/articles/network/pf[/URL]
WAN_BANDWIDTH=300Mb

altq on wan hfsc bandwidth $WAN_BANDWIDTH queue { normal, high, top }
queue normal bandwidth 30% hfsc(default upperlimit 99%)
queue high   bandwidth 50% hfsc(upperlimit 99%)
queue top    bandwidth 20% hfsc(realtime 20% upperlimit 99%)

###
# default queue is required
#altq on wired hfsc bandwidth 1Gb queue {default, no_media}
#queue default bandwidth 99% hfsc(default upperlimit 99%)
#queue no_media bandwidth 1M hfsc(upperlimit 1M)

no rdr

nat on wan inet from wired:network to any -> (wan)

block in log (to pflog0) quick on wan

# [URL]https://www.digitalocean.com/community/tutorials/how-to-configure-packet-filter-pf-on-freebsd-12-1[/URL]
# disabled for vm-bhyve and jails to work
#antispoof quick for {lo0 wired epair0b epair1b bridge0}

###table <country_allowlist> persist file "/usr/local/etc/walterjwhite/network/country-blocks/allowlist"
#block log (to pflog0) quick on wan to !<allow_whitelist>

###table <blocked_devices> persist file "/usr/local/etc/walterjwhite/network/blocked-devices"
block log (to pflog1) quick from <blocked_devices>
block log (to pflog1) quick to <blocked_devices>

post-rule:

block return log (to pflog2) quick on wired
block out log (to pflog3) quick on wan

 

[SirDice]

And, it appears like it is blocking traffic, but then shortly thereafter, I am able to get out.

Cronjob firing more often than you expected?

At the very end of my ruleset, I have a block rule which should effectively block and log the traffic on a pflog interface for inspection.

Show us the rest of the rules. Traffic might be allowed due to an earlier rule. Also remember that the default, if there are no rules, is to allow everything.

 

[tOsYZYny]

I think I found one issue, it was a member of the web client table which allows traffic anywhere to TCP/UDP port 80/443. My VPN to my knowledge uses a separate port and Microsoft Teams and Outlook also use different ports outside of that.

After removing the device from the table, the changes should be immediate, right? I wouldn't need to flush states or anything?

 

[tOsYZYny]

I think that was the issue, I had somehow added it to the general web client table and both teams and my VPN client were working as a result. The additional port for the VPN is for IPSEC and it seems it is not required. The odd thing is that teams needs other ports in addition to https to function, otherwise it will display a warning message or complain it isn't connected to the Internet. I think the issue is sorted out.