Cannot access website from mac

SharkScout · September 10, 2021, 8:37am

Hi all,

I have installed openwrt on my router.

I have a strange problem now. I cannot access "www.apple.com" from a mac connected to the network. I tried with an iPhone connected to the network, and it works. Both the mac and iPhone connect to the router via wifi.

Note that the mac can access any other webpage without issue. But the mac cannot even ping or traceroute (via Terminal) "www.apple.com".

I have tried everything I could think of, this problem persists across system reboots, and I've been having this problem for months.

I am a little lost. Any advice on how I can diagnose this issue?

Thanks!

trendy · September 10, 2021, 8:43am

Can you try the following on the mac?
nslookup www.apple.com; nslookup www.apple.com 8.8.8.8

SharkScout · September 10, 2021, 8:48am

Hi @trendy, thanks for your help.

$nslookup www.apple.com
Server:		192.168.1.1
Address:	192.168.1.1#53

Non-authoritative answer:
www.apple.com	canonical name = www.apple.com.edgekey.net.
www.apple.com.edgekey.net	canonical name = www.apple.com.edgekey.net.globalredir.akadns.net.
www.apple.com.edgekey.net.globalredir.akadns.net	canonical name = e6858.dscx.akamaiedge.net.
Name:	e6858.dscx.akamaiedge.net
Address: 2.21.169.157

$ nslookup www.apple.com 8.8.8.8
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
www.apple.com	canonical name = www.apple.com.edgekey.net.
www.apple.com.edgekey.net	canonical name = www.apple.com.edgekey.net.globalredir.akadns.net.
www.apple.com.edgekey.net.globalredir.akadns.net	canonical name = e6858.dscx.akamaiedge.net.
Name:	e6858.dscx.akamaiedge.net
Address: 2.21.169.157

trendy · September 10, 2021, 8:59am

Name resolution works fine. Try to ping and open a page from the mac to this address and capture on the router the packets.
Install tcpdump on OpenWrt, if it is not there already.
tcpdump -i any -evn -c 50 host 2.21.169.157

SharkScout · September 10, 2021, 9:06am

Thanks for that trendy. I won't be able to do it right now, but will try that later.

SharkScout · September 23, 2021, 5:27pm

Hi,

I haven't been able to download tcpdump and analyze the traffic (I need to get familiarized with all this first).

But I have some further info on this issue.

I now have this issue on www.google.com. I can access any other sites without problem, except this one.

What I found out is that if I do
"ping www.google.com", it blanks out (it can't ping it).

However, if I do an nslookup, I get :

nslookup www.google.com
Server:		192.168.1.1
Address:	192.168.1.1#53

Non-authoritative answer:
Name:	www.google.com
Address: 142.250.201.68

and if I ping this IP address (142.250.201.68) it does work !

So it seems nslookup directs to the correct IP, but my browser and ping do not.

Any chance that gives more color to understand my problem?

trendy · September 23, 2021, 7:37pm

A tcpdump would be more helpful to identify the issue.

SharkScout · September 24, 2021, 8:50am

Ok, I'll try to sort out the tcpdump. Thanks.

SharkScout · October 4, 2021, 1:42pm

Hi,

so I have gotten around to installing and running tcpdump in this manner : tcpdump -i br-mynetwork icmp

Unfortunately, it does not show anything.

So here's the situation :

on the mac if I run ping www.apple.com, nothing happens, and nothing shows in the tcpdump in the openwrt router
on the mac, pinging other domains works fine
on the openwrt router itself, ping www.apple.com works fine
on the mac, pinging the underlying ip (found by nslookup www.apple.com) works fine

Any clue what I could try now?

Thank you

SharkScout · October 4, 2021, 1:47pm

Oh, I think I have just found a very significant pointer : if I run /etc/init.d/https-dns-proxy restart on the router, everything now works fine !

I run the following version :

/etc/init.d/https-dns-proxy version
2021-01-17-5

on openwrt 19.07.7

Are there known issues?

trendy · October 4, 2021, 5:21pm

I am not familiar with this package. Moreover it would help troubleshooting if you had mentioned it earlier. Bottom line is that you need to provide more information on the configuration of this package to understand why it blocks only one domain for one device in your network.

SharkScout · October 4, 2021, 5:53pm

I didn't mention it earlier because I didn't know it was the issue.

Here's the configuration :

config main 'config'
	option force_dns '0'
	list force_dns_port '53'
	list force_dns_port '853'
	option update_dnsmasq_config '-'

config https-dns-proxy
	option listen_addr '127.0.0.1'
	option bootstrap_dns '1.1.1.1,1.0.0.1,2606:4700:4700::1111,2606:4700:4700::1001'
	option resolver_url 'https://cloudflare-dns.com/dns-query'
	option listen_port '5053'

config https-dns-proxy
	option listen_addr '127.0.0.1'
	option bootstrap_dns '1.1.1.2,1.0.0.2,2606:4700:4700::1112,2606:4700:4700::1002'
	option resolver_url 'https://security.cloudflare-dns.com/dns-query'
	option listen_port '5054'

Because the problem only appears after a while, I am wondering if it's a buffer running out of space, or something like that.

vgaetera · October 4, 2021, 10:50pm

ubus call system board; uci show dhcp; \
netstat -l -n -p | grep -e dnsmasq -e https-dns; \
head -v -n -0 /etc/resolv.* /tmp/resolv.* /tmp/resolv.*/*

SharkScout · October 9, 2021, 11:39am

Hey thanks @vgaetera.

The problem seems solved for now, thanks for your help!

laingo · October 9, 2021, 12:22pm

If you're still facing resource exhaustion issues with this proxy, it sounds familiar.
My take is it's an expensive option unless you're okay with no shared network cache.

I've since switched to unbound that has the additional advantage of caching at the router to speed up lookups. I use unbound with nextdns as the forward zone. It has been solidly stable on 19.0x,21.0x and snapshots.

**Documentation: ** https://openwrt.org/docs/guide-user/services/dns/dot_unbound

With unbound-control you have tooling to perform interrogation of your DNS server performance, metrics e.t.c.

My Configuration

unbound.ub_main.listen_port='53'
unbound.ub_main.localservice='1'
...
unbound.fwd_nextdns=zone
unbound.fwd_nextdns.enabled='1'
unbound.fwd_nextdns.tls_upstream='1'
unbound.fwd_nextdns.zone_type='forward_zone'
unbound.fwd_nextdns.zone_name='.'
unbound.fwd_nextdns.server='45.90.28.0#<your-unique-id>.dns1.nextdns.io' '45.90.30.0#<your-unique-id>.dns2.nextdns.io'

dhcp config

dhcp.@dnsmasq[0].localuse='0'
dhcp.@dnsmasq[0].port='0'

SharkScout · October 9, 2021, 1:05pm

Hi @laingo, what you are saying is very interesting.

I want to make sure I understand it fully :

"no shared network cache" I am unclear what you mean by that. Do you mean that there is an option to disable shared network cache that i should consider?

Also, I do think the issue is ressource exchaustion, but I am not 100% certain. Is there a way for me to confirm that's the issue at hand ?

Thanks!

laingo · October 9, 2021, 1:14pm

@SharkScout what I meant was that https-radius-proxy is non-caching, so all DNS queries to the router will be forwarded to the upstream (from whichever client).

So unless every client maintains their own cache, each query will get out to the internet including the same query from different clients on your LAN side.

unbound on the other hand, is a proper DNS server just like dnsmasq, with caching support and in-built support for DNS over TLS/HTTPS to an upstream. You can turn off caching in unbound as well - it is just a more robust solution for secure DNS.

SharkScout · October 9, 2021, 2:15pm

Ok, I understand. Thanks for the explanation, that makes sense.

I think I looked very briefly into unbound in the past, but felt the config was more complex than https-dns-proxy. So I opted for the latter. Maybe I should revisit this.

system · October 19, 2021, 2:16pm

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