Windows computers stop name resolution

Hi,

The problem is as follow: OpenWRT works fine for linux, android, iOS, and IoT clients connected (using both WiF or ethernet). But when the windows machine joins the network, the name resolution stops working. Internet connectivity is still there (I can ping eg 1.1.1.1) but names can't be resolved. This affects wifi and ethernet connected clients. After some time (usualy 5-15 minutess) everything start working again. This happens for two machines with W10...

I've checked logs - nothing unusual is indicated there. I've restarted services (dnsmasq, firewall, odhcpd, among others), but without effect. OpenWRT reboot helps.

My current OpenWrt is 22.03.0, but this was happening also for two previous versions... Few days back I've freshly installed OpenWRT and apart from changing the network address and setting some static IPs I haven't changed anything.

I'm on Linksys EA8300 (Dallas).

I will appreciate any tips on what can cause the problem or how to diagnose it.

best,
Filip

Resolved from where, using what?

what does SMB1 have to do with domain name resolution on OpenWrt?

@filips - let's start here:

Please copy the output of the following commands and post it here using the "Preformatted text </> " button:
grafik
Remember to redact passwords, MAC addresses and any public IP addresses you may have:

cat /etc/config/network
cat /etc/config/dhcp
cat /etc/config/firewall

Thanks for the prompt reply,

Resolved from where, using what?

Resloved from any computer connected to the network (both wifi and cable), including the openwrt router itself. Using, for example, ping.

@psherman

Please copy the output of the following commands and post it here using the "Preformatted text </> " button:

# cat /etc/config/network

config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'xxx::/48'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth0'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option ipaddr '10.0.0.200'

config interface 'wan'
        option device 'eth1'
        option proto 'dhcp'

config interface 'wan6'
        option device 'eth1'
        option proto 'dhcpv6'
        list dns '2620:fe::fe'
        list dns '2620:fe::9'
        option peerdns '0'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '1 2 3 4 0'

        
        
# cat /etc/config/dhcp

config dnsmasq
        option domainneeded '1'
        option localise_queries '1'
        option rebind_protection '1'
        option rebind_localhost '1'
        option local '/lan/'
        option domain 'lan'
        option expandhosts '1'
        option authoritative '1'
        option readethers '1'
        option leasefile '/tmp/dhcp.leases'
        option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
        option localservice '1'
        option ednspacket_max '1232'

config dhcp 'lan'
        option interface 'lan'
        option start '100'
        option limit '150'
        option leasetime '12h'
        option dhcpv4 'server'
        option dhcpv6 'server'
        option ra 'server'
        list ra_flags 'managed-config'
        list ra_flags 'other-config'

config dhcp 'wan'
        option interface 'wan'
        option ignore '1'

config odhcpd 'odhcpd'
        option maindhcp '0'
        option leasefile '/tmp/hosts/odhcpd'
        option leasetrigger '/usr/sbin/odhcpd-update'
        option loglevel '4'

config host
        option name 'kofola2'
        option dns '1'
        option mac 'XXX'
        option ip '10.0.0.226'

config domain
        option name 'denon.vtuner.com'
        option ip '10.0.0.226'

config domain
        option name 'denon2.vtuner.com'
        option ip '10.0.0.226'


# cat /etc/config/firewall

config defaults
        option syn_flood '1'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'

config zone
        option name 'lan'
        list network 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'

config zone
        option name 'wan'
        list network 'wan'
        list network 'wan6'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'

config forwarding
        option src 'lan'
        option dest 'wan'

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'
        option enabled '0'

config rule
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        option icmp_type 'echo-request'
        option family 'ipv4'
        option target 'ACCEPT'
        option enabled '0'

config rule
        option name 'Allow-IGMP'
        option src 'wan'
        option proto 'igmp'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-DHCPv6'
        option src 'wan'
        option proto 'udp'
        option dest_port '546'
        option family 'ipv6'
        option target 'ACCEPT'
        option enabled '0'

config rule
        option name 'Allow-MLD'
        option src 'wan'
        option proto 'icmp'
        option src_ip 'fe80::/10'
        list icmp_type '130/0'
        list icmp_type '131/0'
        list icmp_type '132/0'
        list icmp_type '143/0'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Input'
        option src 'wan'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        list icmp_type 'router-solicitation'
        list icmp_type 'neighbour-solicitation'
        list icmp_type 'router-advertisement'
        list icmp_type 'neighbour-advertisement'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Forward'
        option src 'wan'
        option dest '*'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-IPSec-ESP'
        option src 'wan'
        option dest 'lan'
        option proto 'esp'
        option target 'ACCEPT'

config rule
        option name 'Allow-ISAKMP'
        option src 'wan'
        option dest 'lan'
        option dest_port '500'
        option proto 'udp'
        option target 'ACCEPT'

config redirect
        option dest 'lan'
        option target 'DNAT'
        option name 'www'
        option src 'wan'
        option src_dport '80'
        option dest_ip '10.0.0.226'
        option dest_port '80'

config redirect
        option target 'DNAT'
        option name 'wwws'
        option src 'wan'
        option src_dport '443'
        option dest 'lan'
        option dest_ip '10.0.0.226'
        option dest_port '443'

config redirect
        option target 'DNAT'
        option name 'rsync'
        option src 'wan'
        option src_dport '873'
        option dest 'lan'
        option dest_ip '10.0.0.226'
        option dest_port '873'

config redirect
        option target 'DNAT'
        list proto 'udp'
        option src 'wan'
        option src_dport '1194'
        option dest 'lan'
        option dest_ip '10.0.0.226'
        option dest_port '1194'
        option name '1194-OpenVPN'
        option enabled '0'

config redirect
        option target 'DNAT'
        option name 'knock'
        option src 'wan'
        option src_dport '10000-12000'
        option dest 'lan'
        option dest_ip '10.0.0.226'
        option dest_port '10000-12000'

config redirect
        option target 'DNAT'
        option name 'ssh'
        option src 'wan'
        option src_dport '31415'
        option dest 'lan'
        option dest_ip '10.0.0.226'
        option dest_port '31415'

config redirect
        option target 'DNAT'
        option name 'mqtt'
        option src 'wan'
        option src_dport '8883'
        option dest 'lan'
        option dest_ip '10.0.0.226'
        option dest_port '8883'

So your network configuration appears to be pretty standard. There is nothing that I would suspect in the router's configuration.

So...

  • Do you experience the same name resolution issue with all systems and the router at the same time?
  • Have you tried using a public DNS server (instead of what is assigned by DHCP) in your wan configuration on OpenWrt? This could fix the issue if the actual root cause is, for example, the ISPs DNS servers.

Thanks for your reply.

Do you experience the same name resolution issue with all systems and the router at the same time?

Yes, when the Windows machine joins the network, name resolution stops working at all connected computers (also connected by the ethernet cable) and the OpeWRT router itself (I can ssh to the router and ping openwrt.org, but the name can't be resolved).

Have you tried using a public DNS server (instead of what is assigned by DHCP) in your wan configuration on OpenWrt? This could fix the issue if the actual root cause is, for example, the ISPs DNS servers.

Yes. In the previous configs of OpenWRT I used quad9, cloudflare, or google DNS; for some time I also had DoH enabled on my router. But always the effect was the same...

Some other observations:

  • This doesn't happen when we use another router instead one with OpenWRT (eg android wifi router form mobile phone)
  • I've check if windows machines start their own DNS or DHCP servers, but no, this is not the case (at least as far as I can tell).
  • "Resolution problem" usually resolves itself after 5-15 minutes (sometime longer, sometime never) so something must happen in the OpenWRT (a service restart or sth?) or in Windows machines...

I will appreciate any tips how to debug this issue.

best,
Filip

Do you have a (rogue) dhcpd running on that windows system (windows server variants expect to handle dhcp/ dns for AD purposes)?

No, as far as I can tell there is only one dhcpd running in the network (OpenWRT).

nmap --script broadcast-dhcp-discover confirms this...

Collect some info using nslookup.

Router

nslookup openwrt.org; nslookup openwrt.org localhost; nslookup openwrt.org 8.8.8.8

Linux client

nslookup openwrt.org; nslookup openwrt.org 10.0.0.200; nslookup openwrt.org 8.8.8.8

Windows client

nslookup openwrt.org & nslookup openwrt.org 10.0.0.200 & nslookup openwrt.org 8.8.8.8
1 Like

Hi,

thanks for the reply, the outputs are below:

OpenWRT router

# nslookup openwrt.org; nslookup openwrt.org localhost; nslookup openwrt.org 8.8.8.8
Server:         ::1
Address:        [::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

Server:         localhost
Address:        [::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

;; connection timed out; no servers could be reached


## testing other NS

# nslookup openwrt.org 1.1.1.1 & nslookup openwrt.org 8.8.8.8 & nslookup openwrt.org 9.9.9.9 &
;; connection timed out; no servers could be reached
;; connection timed out; no servers could be reached
;; connection timed out; no servers could be reached

Linux client:

# nslookup openwrt.org; nslookup openwrt.org 10.0.0.200; nslookup openwrt.org 8.8.8.8
;; connection timed out; no servers could be reached
;; connection timed out; no servers could be reached
;; connection timed out; no servers could be reached

I wasn't able to test it on windows client, I will try to do it during next days.

Interestingly, during such NS "blackouts" I can still successfully ping these NS (eg. ping 1.1.1.1)

I've also set up a "probe" on one linux client on the network. It is testing name resolution using various nameservers every minute. I've noticed that frequently there are problems with name resolution using quad9, google, or cloudflare servers, but not using localhost or openwrt...

any ideas?

If I'm reading your chart properly, your local lookup (10.0.0.200 and localhost) works all the time, but the external ones are problemat sporadically. To me, this looks like a possible ISP issue (despite pings going through, there could be issues with the higher level protocols like TCP/UDP).

During these DNS-blackouts, are you able to browse the internet using a IP addresses (so openwrt.org -> 139.59.209.225)? Obviously anything not hosted at that IP would fail, but still worth a quick test.

2 Likes

@filips - Do you have a working IPv6 setup?

Configs here:

Don't match here:

How about a whole different DNS, router and gateway? :thinking:

First, run: https://www.test-ipv6.com/ and https://www.ipv6-test.com/ (these test both IPv4 and IPv6 DNS)


screen189


I'm not sure this is important...but while this occurs, can you do:

  • ip -4 route and ip -6 route from a Linux machine; and
  • route print from Windows

and compare, especially the IPv6 to make sure there's no difference.

Try:

With:

  • 2620:fe::fe
  • 2620:fe::9
  • 2001:4860:4860::8888
  • 2001:4860:4860::8844
  • 2606:4700:4700::1111
  • 2606:4700:4700::1001

From clients especially.

1 Like

Hi,

thanks for the further suggestions. I will try gathering further info during the next "ns-blackout".

No.

tests results:

nsookup using ipv6 addresses:

nslookup openwrt.org 2620:fe::fe
nslookup openwrt.org 2001:4860:4860::8888
nslookup openwrt.org 2606:4700:4700::1111
# and other mentioned

Nothing is displayed...

Few other observations:

  • Blackout doesn't happen when the windows machine first connects to another "source of the internet" (eg via mobile router) and then reconnects to OpenWRT network
  • Blackout doesn't happen when the windows machine immediately connects to VPN after startup.
  • Blackout also affects the name resolution by the ISP-provided DNS servers
  • During the blackout if I connect with my laptop to the upstream cable ISP modem, everything works fine. So I don't thing blocking queries or name servers by the ISP is the case here...

best, Filip

Then remove these:

Then run /etc/init.d/network reload and try after. No need to specify public IPv6 DNS servers if you don't have public IPv6 - eliminate this as the issue.

Hi, thank you for all your suggestions.

I removed the IP6 DNSes - didn't help.

ip -4 route and ip -6 route give the same output during the normal conditions and during the "blackout" (run from one of the linux clients):

$ip -4 route
default via 10.0.0.200 dev wlp3s0 proto dhcp metric 600 
10.0.0.0/24 dev wlp3s0 proto kernel scope link src 10.0.0.165 metric 600 
169.254.0.0/16 dev wlp3s0 scope link metric 1000 

$ip -6 route
::1 dev lo proto kernel metric 256 pref medium
fd07:942f:62c5::1c9 dev wlp3s0 proto kernel metric 600 pref medium
fd07:942f:62c5::/64 dev wlp3s0 proto ra metric 600 pref medium
fd07:942f:62c5::/48 via fe80::3223:3ff:fe73:5a76 dev wlp3s0 proto ra metric 600 pref medium
fe80::/64 dev wlp3s0 proto kernel metric 1024 pref medium

I've also started monitoring if the connected computers can access web pages (using the wget probe and regular addresses). In most cases - it can not:

It seems that I can not, but I could access the https://1.1.1.1/.

The situation from today:

  • the blackout started as soon as the windows computer joined the openwrt network
  • it happened despite the windows was connected via vpn to another server
  • as soon as windows left the openwrt network, everything started working again

I'm more and more puzzled with the situation...

best,
Filip

if your services suddenly go down when you add a computer to a network then the most likely cause is an IP conflict.

1 Like

Ok, but how to check this? In syslog I can't see any anomaly or info on that. Also googling doesn't help much...

Or MAC conflict.

ipconfig /all on Windows

ip -4 addr on Liunx

Look at the Windows network configuration -- what is the IP address (if static) or what is the IP that is issued (if DHCP)? You should also be able to see the MAC address in the hardware properties of your network adapter.

1 Like
  1. Windows can be configured for multiple IP addresses. Make sure you check all the IP addresses configured on your windows machine.

  2. If it is fetching a DHCP address check that you have not given it a reserved IP.

  3. If the DNS service goes down after you run a particular app on Windows such as the VPN client you should again check the IP address of your Windows machine after running the app. I might modify the IP address of your windows machine.

  4. You might have misbehaving app or even malware on your Windows machine that is doing a Denial-of-Service attack.

1 Like