After upgrading, adblock and internet don't work anymore

Today, I upgraded to OpenWrt 22.03.2 r19803-9a599fee93 (git-22.288.45147-96ec0cd) but I didn't succeed in keeping settings/configuration + installed packages, so I re-configured everything from scratch. After doing so, adblock doesn't work and I have no internet connection.

Here's what I did:

Installed stubby

opkg install dnsmasq-full --download-only && opkg remove dnsmasq && opkg install dnsmasq-full --cache . && rm *.ipk
opkg install stubby

Configured stubby

Made dnsmasq send all DNS requests to stubby and prevented dnsmasq from using /etc/resolv.conf:

uci add_list dhcp.@dnsmasq[-1].server='127.0.0.1#5453'
uci set dhcp.@dnsmasq[-1].noresolv=1

Prevented OpenWrt from sending DNS requests to the ISP's DNS:

uci set network.wan.peerdns='0'
uci set network.wan.dns='127.0.0.1'
uci set network.wan6.peerdns='0'
uci set network.wan6.dns='0::1'
uci commit && reload_config

In /etc/config/stubby I enabled option tls_min_version '1.2', removed all default resolvers and added custom ones. These worked fine before the upgrade.

Sources for the DNS server configs: Digitalcourage (scroll down a bit), Dismail

config resolver
        option address '5.9.164.112'
        option tls_auth_name 'dns3.digitalcourage.de'
        list spki 'sha256/2WFzfO2/56HpeR+v/l25NPf5dacfxLrudH5yZbWCfdo='

config resolver
        option address '159.69.114.157'
        option tls_auth_name 'fdns2.dismail.de'
        list spki 'sha256/yJYDim2Wb6tbxUB3yA5ElU/FsRZZhyMXye8sXhKEd1w='

config resolver
        option address '80.241.218.68'
        option tls_auth_name 'fdns1.dismail.de'
        list spki 'sha256/yJYDim2Wb6tbxUB3yA5ElU/FsRZZhyMXye8sXhKEd1w='

DNS firewall rule

Allowed DNS traffic in the firewall:

uci add firewall rule
uci set firewall.@rule[-1].target='ACCEPT'
uci set firewall.@rule[-1].proto='udp'
uci set firewall.@rule[-1].name='Allow-DNS-from-WAN'
uci set firewall.@rule[-1].src='wan'
uci set firewall.@rule[-1].dest_port='53'
uci commit firewall
/etc/init.d/firewall restart

DNSSEC

Enabled DNSSEC:

uci set dhcp.@dnsmasq[-1].dnssec=1
uci set dhcp.@dnsmasq[-1].dnsseccheckunsigned=1
uci commit && reload_config

Made sure that DNSSEC works:

dig dnssectest.sidn.nl +dnssec +multi @192.168.1.1

Indeed, the response included the ad flag indicating DNSSEC is working.

Adblocker

Then, I installed and configured the adblock and luci-app-adblock packages via luci. I set dnsmasq as the DNS backend and selected a few blocklists.

The problem

After applying the configuration, the adblocker only said running / 0 domains blocked. Also, I was unable to open any website on any device connected to the WiFi after that (before setting up the adblocker, it had worked fine).

Now, I can't even open the luci dashboard or SSH into OpenWrt on two of my three laptops:

  • Windows laptop, connected via LAN (WiFi module broken) to the OpenWrt router, can't open luci or connect via SSH
  • Linux laptop, connected via WiFi to the OpenWrt router, can't open luci or connect via SSH
  • Windows laptop, connected via WiFi to the OpenWrt router, CAN open luci and connect via SSH

Restarting adblock, dnsmasq, stubby and OpenWrt altogether didn't help.

However, resolving domains still works on all devices.

Linux:

~$ nslookup openwrt.org 192.168.0.251
Server:		192.168.0.251
Address:	192.168.0.251#53

Non-authoritative answer:
Name:	openwrt.org
Address: 139.59.209.225
Name:	openwrt.org
Address: 2a03:b0c0:3:d0::1af1:1

Windows:

>nslookup openwrt.org
Server: OpenWrt.lan
Address: fd0a:6de3:87a0::1

Non-authoritative answer:
Name: openwrt.org
Addresses: 2a03:b0c0:3:d0::1af1:1
                   139.59.209.225

OpenWrt:

root@OpenWrt:~# nslookup openwrt.org
Server: 127.0.0.1
Address: 127.0.0.1:53

Non-authoritative answer:
Name: openwrt.org
Address: 139.59.209.225

Non-authoritative answer:
Name: openwrt.org
Address: 2a03:b0c0:3:d0::1af1:1

I have no clue what the issue might be and don't know what to do. I'm happy about any advice.

Thanks for your help!




1 Like

There are issues, I don't know what but after upgrading to OpenWrt 22.03.2 https-dns-proxy is/was also not working.

This is wrong. Please read here.

You mean wrong as in “done in a wrong way” or “generally a bad idea”?

very bad idea. You can config 1.1.1.1 or 8.8.8.8 for your wan connection, if you are not comfortable using ISP's DNS server during bootup.

I just ran

root@OpenWrt:~# uci set network.wan.dns='5.9.164.112'

and rebooted the router. Unfortunately, this didn't solve the issue.

Did I configure the adblock package correctly? For example, is it corret to set WAN as the startup trigger interface and to set LAN as a forced zone?

I have no Idea about these things. I knew that you need to config dns for WAN interface for openwrt to boot properly thats why I mentioned it.

1 Like

You could simplify things by replacing Adblock and stubby with AdGuard Home.

AGH does DoT and DoH and filtering in one.

Also you should NOT direct your routers DNS to use either your setup or AGH. There is a race condition on boot which means NTP and other services will not be able to resolve DNS on boot. This will break SSL connections as incorrect date/time will mean SSL connections fail. You should set your WAN Dns for the router to either your ISP Dns or a stable DNS service like Cloudflare or google. A few people have been bitten by this and its detailed in my thread.

This way your router will have unfiltered on boot DNS but your clients will use the later booting and encrypted DNS provided by AGH from the DHCP server. This avoids the race condition.

1 Like

Ah, I see, thanks for the advice. Is this the proper way to set up a seperate DNS for the router? root@OpenWrt:~# uci set network.wan.dns='5.9.164.112' (I already tried this.) FYI, that's a stable DNS server ran by the German privacy organisation Digitalcourage.

Here's a weird thing: I used OpenWrt's Diagnostics tool to check whether the router itself is able to ping servers, and, indeed, it is. However, the devices connected can only resolve domains, and all pings result in a timeout. I don't understand this behaviour – what could possibly cause it?

Do you know whether it's possible to use DNSSEC with AdGuard? (I'm considering switching to AdGuard, but it seems like a more difficult approach than stubby + dnsmasq + adblock).

I have a wandns script on my thread u can use for setting ipv4 and 6 wan dns.

check you didn't break things with the firewall.

as long as the upstream DNS server supports DNSSEC then yes you can enable it. its a tickbox on the config page in AGH.

1 Like

The race condition with SYSNTPD service could be the possible cause of your issue.

Verify that bypass forwarders for NTP server pool are in place.
NTPD service should be able to resolve NTP providers prior to DoH/DoT service startup.
Without such bypass NTPD will be incapable to resolve NTP providers at boot time.
And without correct RTC clock set at boot time it is not possible for Stubby to establish SSl/TLS connection with a secure DNS provider due to inability to verify certificate chain validity (certificate may be 'Not yet valid').

Edit DNSMASQ config file:

nano /etc/config/dhcp

Add the following lines to the 'config dnsmasq' section:

   list	server		'/pool.ntp.org/1.1.1.1'
   list	server		'/time.nist.gov/1.1.1.1'

Restart services to apply changes:

/etc/init.d/dnsmasq restart

For more information on resolving NTP issues while using DNS encryption please refer to:

Unfortunately, this didn't help (after re-booting). Though, I noticed this in the system log multiple times:

daemon.info hstapd: wlan0: STA [some MAC address] IEEE 802.11: deauthenticated due to local deauth request
daemon.info hstapd: wlan0: STA [same MAC address] IEEE 802.11: authenticated
daemon.info hstapd: wlan0: STA [same MAC address] IEEE 802.11: associated (aid 1)
daemon.info hstapd: wlan0: AP-STA-POSSIBLE-PSK-MISMATCH [same MAC address]
daemon.info hstapd: wlan0: AP-STA-POSSIBLE-PSK-MISMATCH [same MAC address]
daemon.info hstapd: wlan0: AP-STA-POSSIBLE-PSK-MISMATCH [same MAC address]
daemon.info hstapd: wlan0: AP-STA-POSSIBLE-PSK-MISMATCH [same MAC address]
daemon.info hstapd: wlan0: STA [same MAC address] IEEE 802.11: deauthenticated due to local deauth request

I'm not sure what that is supposed to tell me – could it have something to do with the issue?

You should correct your WAN interface DNS settings.
It's good idea to use some publicly available and working DNS resolvers such as 1.1.1.1 or 1.0.0.1.

I have checked your '5.9.164.112' and it is not responding to plain DNS queries (i.e. not encrypted).

Screenshot 2022-10-29 Digitalcourage

According to Wikipedia (https://en.wikipedia.org/wiki/Digitalcourage):

Since December 2020, they have provided a third DNS server (IP address 5.9.164.112 = dns3.digitalcourage.de, port 853) exclusively for encrypted/private DNS according to the [DNS over TLS] standard.

Please ensure that your network config (/etc/config/network) contains the following three directives in the WAN interface definition:

config interface 'wan'
...
   list	dns		'1.0.0.1'	
   list	dns		'1.1.1.1'
   option	peerdns		'0'
...

In other case the local system (router itself) will be unable to perform DNS queries during boot - local system uses DNS resolvers gathered from active network interfaces, as a default behaviour.

1 Like

Riiiiight, thanks for the hint! I didn't see that at all! Though, configuring Cloudflare, Google, Dismail and other DNS services didn't make it work either.

Thus, I tried installing AdGuard Home on a USB drive plugged into the router (including resetting everything beforehand), but unfortunately, it hasn't worked yet. I've already posted my problem on the “Installing AdGuardHome on OpenWrt” thread:

Forgot to also state here that I have switched my configuration to AdGuard Home hosted on my Raspberry Pi.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.