Odd pfblockerng behavior
-
Sometime over the weekend my pfblockerng started behaving differently. Ads in iOS games started leaking through when they had been pretty effectively filtered previously. And if pfblockerng is enabled YouTube TV on my Roku devices won't connect. I haven't changed anything recently so I'm not sure where I should be going to look to change the config to fix these issues.
-
@BiloxiGeek Well any list of ad servers will change over time.
Are you blocking DoH/DoT in pfBlocker? That will bypass any local DNS.
-
@BiloxiGeek said in Odd pfblockerng behavior:
And if pfblockerng is enabled YouTube TV on my Roku devices won't connect
Doesn't pfBlockerng mention the DNS request from the Roku blocked ?
Firewall > pfBlockerNG > Alerts@BiloxiGeek said in Odd pfblockerng behavior:
Ads in iOS games started leaking through
Check the other log : Firewall > pfBlockerNG > Unified and look for the IP in the Source common. If these 'new' add servers are ... well .. new, and not part of any list, they will show up.
Another explanation : If the iPhone decides (with some user help of course ^^) not use use pfSense as its DNS source, then it's normal that pfBlocker can't do it's work.
Other reasons ? -
@BiloxiGeek said in Odd pfblockerng behavior:
Ads in iOS games started leaking through
Almost inevitably DoH 'leak.'
@Gertjan said in Odd pfblockerng behavior:
Firewall > pfBlockerNG > Alerts
Firewall / pfBlockerNG / Reports / Alerts [or Unified] -
I'm trying to figure out what IPs are responsible for the ADs. Is there a guide to the best way to track which DNS requests are coming from a specific device so I can monitor while playing those games and get a list of the lookups happening? I got the Alerts - Filter set but I'm not seeing new entries, kinda like it's got the lookup cached so it's not doing a query.
Added: While playing a couple games to force an ad lookup it's not getting the ads now. Maybe I just needed to wait for the block lists to update or something along those lines.
-
@BiloxiGeek You can always run Wireshark on a compatible device, filtering the capture by "port 53". But this would not show any queries made via HTTPS (i.e., DoH).
You could also include "or port 853" in your capture filter to show DoT traffic. But the queries themselves would be encrypted.
