What's blocking this. Even if I disable DNSBL, it still gets blocked. I'd like to unblock it.
OPNsense does not block any web service by default so it must be something you explicitly configured. If all else fails restore to defaults.
Thanks. I'm running the defaults.
Didn't you have an issue with iHeart using one of Stephen Black's lists?
Maybe the block is still active in some cache...
Quote from: EricPerl on April 22, 2025, 01:19:02 AMDidn't you have an issue with iHeart using one of Stephen Black's lists?
Maybe the block is still active in some cache...
Where work I look. As I posted, even if I disable blocking, it still gets blocked. Plus, when I look at the log, nothing is getting blocked. Thanks
Well, if it has not resolved by now, the cache theory was just a bad guess.
You ought to see actual queries for that domain and replies.
What are the symptoms of the "block"?
As with any internet traffic, you ought to be able to find (in the FW logs) traffic IN on some internal interface, then OUT on wan with a destination equal to what's returned by DNS.
I'm looking at logs but maybe at the wrong ones. Thanks
I can't ping googleadservices.com Diagnostics-Ping
Do a nslookup please and show the output
Quotenslookup googleadservices.com
Regards,
S.
Thanks see below
Sorry. This post is meaningless without this important information. Setting DNS to Google Public fixed it.
In Chrome settings:
So DNS resolves on OPN (using Google's DNS).
You can't ping the IPs returned from OPN (Interfaces diags)? for example 64.233.185.154?
In any case, if your browser is using Google's DNS directly (versus using OPN's DNS), you're using a different path.
On the same machine, the rest of the OS is likely using something else depending on how it's configured.
If you don't configure your devices consistently, troubleshooting needs to take all these settings into consideration.
If your browser is going to 8.8.8.8 (Google public DNS) directly, then DNS filtering on OPN is worthless (port forwarding could handle some use cases, but not DoT).
Using the curl command line could yield a completely different outcome.
Consistent setup:
* No DNS servers in System > Settings > General
* Unbound (Default DNS server) works out of the box as a recursive resolver.
If you instead want to use DNS over TLS consistently, specify that there (Services > Unbound > DNS over TLS). Pick your provider.
* DHCP by default will by default point clients to the FW's interface IP for DNS (see help tip in Services > ISC DHCP v4 > [Interface] > DNS Servers).
* Don't override settings in browsers so they use OS settings (obtained via DHCP by default).
Then you can test sanely. Verify DNS (GUI or nslookup/dig), Ping (GUI or ping), fetch URL (browser or curl) on different machines (OPN, clients).
I did have the Google DNS in System Settings. I deleted them and now Googleadservices is blocked again.
Start on one end and work your way to the other (for example: OPN, then machine(s), then browser(s) on these machine(s)).
Test DNS (GUI when available, or tool like nslookup).
If it's not working as expected, determine which service is handling the request (Unbound by default on OPN), look at the settings.
Post screenshots if you're stuck.
If you specified an explicit server in your browser, then you're bypassing whatever mechanisms is available at the OS level and whatever infrastructure (e.g. OPN) is used based on configuration at the OS level. That's fine if that's what you want to do but then don't expect DNS filtering on OPN to be effective.
Thanks Eric.
Online NSLookup
Ping and DNSLookup from OPNSense Diagnostics. Ping failed.
More:
The DNS lookup from OPN (last screenshot) is a dead giveaway that this particular FQDN is blocked (0.0.0.0) by OPN or its upstream server(s).
You can identify the process handling DNS using
sockstat | grep :53Console or ssh.
Then you can dig in the configuration of that service.
Edit: ping failed on OPN because the DNS query returned 0.0.0.0 (typical blocked behavior) from OPN.
As you can see from your last post, if you resolve externally, you can ping that site from your Windows machine.
Thanks. Unfortunately, we're starting to get above my head.
Let's assume you are using Unbound (default on OPN) then.
Take screenshots of the General, Overrides, Blocklist (advanced mode checked), Query Forwarding, and DNS over TLS config pages.
Thanks Eric.
You have a blocklist enabled. What do you expect? It blocks ads - that's the point. Disable the blocklist feature and the problem will be solved.
Quote from: Patrick M. Hausen on April 24, 2025, 01:55:48 PMYou have a blocklist enabled. What do you expect? It blocks ads - that's the point. Disable the blocklist feature and the problem will be solved.
Post #1
So if you disable the blocklist, then restart Unbound, you still get 0.0.0.0?
Quote from: Patrick M. Hausen on April 24, 2025, 02:43:53 PMSo if you disable the blocklist, then restart Unbound, you still get 0.0.0.0?
And the result of an nslookup on that desktop system with the error message gives what address?
Quote from: Patrick M. Hausen on April 24, 2025, 03:16:24 PMAnd the result of an nslookup on that desktop system with the error message gives what address?
Is that a web page that performs a lookup? I meant open a command line window and type "nslookup www.googleadservices.com" followed by the ENTER key. When you receive IP addresses, no filtering is taking place. When you receive "0.0.0.0" *something* is still filtering that request.
You have problems connecting to googleadservices.com from a PC behind your OPNsense, right? So a web service somewhere on the Internet performing a lookup is pretty worthless. We need to check what your PC receives.
Quote from: Patrick M. Hausen on April 24, 2025, 05:19:49 PMIs that a web page that performs a lookup?
It looks like some sort of Network Tools web site, so the OP is not running this from their system/LAN while they should.
None of this is rocket science. If something is not working on the Internet, you have one or several of the following reasons:
1. DNS server is not resolving.
- It simply does not have an address record for the name.
- It has but refuses to resolve, i.e. has a block.
2. hosts file overrides DNS resolution.
3. Firewall is blocking.
4. You are using a proxy that is blocking the address.
5. You are using a personal firewall on your device.
When you suspect that DNS or firewall are blocking, you ssh into the OS and use its shell to run nslookup or ping, to eliminate anything on your device or your LAN before the OS router.
Copy/paste this comment into a text file and keep it for future reference.
Quote from: Patrick M. Hausen on April 24, 2025, 05:19:49 PMIs that a web page that performs a lookup? I meant open a command line window and type "nslookup www.googleadservices.com" followed by the ENTER key. When you receive IP addresses, no filtering is taking place. When you receive "0.0.0.0" *something* is still filtering that request.
You have problems connecting to googleadservices.com from a PC behind your OPNsense, right? So a web service somewhere on the Internet performing a lookup is pretty worthless. We need to check what your PC receives.
From Command Prompt, all zero
Quote from: verfluchten on April 24, 2025, 05:24:44 PMQuote from: Patrick M. Hausen on April 24, 2025, 05:19:49 PMIs that a web page that performs a lookup?
It looks like some sort of Network Tools web site, so the OP is not running this from their system/LAN while they should.
None of this is rocket science. If something is not working on the Internet, you have one or several of the following reasons:
1. DNS server is not resolving.
- It simply does not have an address record for the name.
- It has but refuses to resolve, i.e. has a block.
2. hosts file overrides DNS resolution.
3. Firewall is blocking.
4. You are using a proxy that is blocking the address.
5. You are using a personal firewall on your device.
When you suspect that DNS or firewall are blocking, you ssh into the OS and use its shell to run nslookup or ping, to eliminate anything on your device or your LAN before the OS router.
Copy/paste this comment into a text file and keep it for future reference.
I'm basically using OPNSense with no modifications. It does it from my phone as well when connected to wifi.
Quote from: t84a on April 24, 2025, 06:00:31 PMI'm basically using OPNSense with no modifications.
That is not quite correct. You enabled a block list. That's a modification. And a rather relevant one.
Please post the complete output from the nslookup command on your PC. Does it query the OPNsense at all?
Quote from: Patrick M. Hausen on April 24, 2025, 06:10:31 PMQuote from: t84a on April 24, 2025, 06:00:31 PMI'm basically using OPNSense with no modifications.
That is not quite correct. You enabled a block list. That's a modification. And a rather relevant one.
Please post the complete output from the nslookup command on your PC. Does it query the OPNsense at all?
Thanks. I'm just going to live with it as it's an ad tracker.
Also useful would be to test the FQDN that's actually used in the URL.
Tested: googleadservices.com
Used: www.googleadservices.com
With Steven Black's list, it likely doesn't matter.
# [googleadservices.com]
0.0.0.0 googleadservices.com
0.0.0.0 pagead2.googleadservices.com
0.0.0.0 www.googleadservices.com
With my AdGuard setup (in this case because of the 'AdGuard DNS filter' rule), the tested name is blocked while the one in the URL is not...
In any case, even with blocklists, you can make an exception. AdGuard makes it really easy.
I believe there have been some quirks with Unbound on that subject, but it is possible.