finding out where a device is attempting to reach

BartH

I'm in way over my head! Here's an explanation of what is happening:

I'm using a NetGate 4100 router. I am using ngBlocker
I have a TP-Link managed switch connected to the 4100
I have an Apple TV hard wired to Vlan 40 of the switch.
Almost everything works as it should with one exception.
When I load Paramount TV, I can see the home page where I can select a movie I want to see. After I make my selection, the small circular buffering wheel loads and nothing else happens.

I assume Paramount is trying to send me to some tracking site and will not time out because If I set up a home router with no tracking protection and connect the Apple TV and the WAN connection, Paramount works.

My question is: How can I discover the URL of the place where the process stalls?

Please type the explanation very slowly so I can understand!

SteveITS

@BartH If you have DNSBL enabled:

...and look for the TV's IP.

Did you enable "DoH/DoT/DoQ Blocking" on the DNSBL SafeSearch page? I found the Dish network DVR will load all apps just fine except for their video on demand app which uses hard coded DNS servers, so I had to allow that.

BartH

Thank you so very much for your response!

I went to Firewall -> pfBlockerNG -> Alerts -> Reports -> Alerts
I watched the report as I went to Paramount+
Several entries showed up as Being blocked.
I clicked on the red lock symbol, one at a time, until I found the one that allowed the show to load.
It is dpm.demdex.net

Now, will this url remain unblocked even after an update from the StevenBlack file gets reloaded?

Is there a way to create a rule that allows this single Vlan to access this site yet still blocks it for all other Vlans?

smolka_J

@BartH Yes it will remain unblocked after updates and reloads. From the pfBlockerNG side of things for DNSBL, pfBlockerNG is using the system DNS resolver which will natively have whitelisted domains whitelisted system wide. To have rules to keep specific domains blocked for specific VLANs or interfaces, you will need a couple ALIAS lists made up. ALIAS #1 set type to Hosts and list out those specific domains you want selectively blocked, also include any associated CNAMEs that were whitelisted if any (when whitelisting via the Reports tabs, pfBlockerNG will list these in the DNSBL>DNSBL Whitelist drop-down under the domain you whitelisted). ALIAS #2 set type to Networks and list out each VLAN/network IP range/or specific IPs you want this block list applied to like

192.168.5.0/24
192.168.6.0/24
192.168.7.55/32

Then create a Firewall>NAT>NAT Port Forward rule with:

Protocol: Any
Source: Address or Alias > Enter the name of alias #2 that was created earlier
Destination: Address or Alias > Enter the name of alias #1 that was created earlier
Redirect Target IP: Address or Alias > Enter your pfBlockerNG DNSBL Webserver Virtual IP address, 10.10.10.1 is default.
NAT reflection: Disable

Save/apply then reboot pfSense or your switch to reset any open states/connections to those domains.

This much will get the job done for that but will take that last reboot when you need to manage/update those selective domains when the time comes. To avoid that and have an isolated DNS/pfBlockerNG configuration for each VLAN or group of IPs in an ALIAS, I went another step further and setup a second box with Proxmox running two more instances of pfSense in virtual machines to divide different blocklists/whitelists for each in their own pfBlockerNG configuration, easier to manage with Reports/alerts separated for each, then I use the NAT rules to route each group of IPs or VLANs to the desired pfSense IP for DNS/DNSBL.

BartH

Thank you both for your time.
This works for me!

smolka_J

@SteveITS If hardcoded DNS is giving you issues needing more than expected/desired to be whitelisted, it may be worth checking out this blog on Labzilla. It was wrote with Pihole in mind alongside pfSense, so the term Pihole can be replaced with pfBlockerNG to make more sense. The trick for hardcoded is making DNS replies answer back looking like the answers come from the intended/hardcoded DNS server and not coming from an unknown source/pfSense/Pihole, using the few NAT rules described in the Labzilla blog goes another couple steps further than what Netgates documentation has for just redirecting DNS, these additional NAT rules will mask where DNS replies are answered back from:

administrator@desktop:~$ nslookup www.google.com 8.8.8.8
Server:         8.8.8.8
Address:        8.8.8.8#53

Name:   www.google.com
Address: 10.10.10.69