Why Does Router Constantly Ping dns.google:0 despite VPN and all process go through VPN checked?

Does this mean the entire time I was connecting to a VPN and marking that I wanted everything to go through the VPN that my VPN was sending constant pings to a google DNS server?

This is not okay, Google has a horrible record when it comes to privacy and I had no idea the router was doing this until I looked closely at Luci.

It means the Google corporation knows exactly when I am using my computer and VPN, which means they know when I’m working and can probably guess who I am more easily to sell me products and track me.

I appreciate privacy and use a VPN and this router to avoid stuff like this, and yet here the router is, pinging google more than once a second.

Can someone explain the purpose of this? Why the router did this or chose to do this? This seems beyond sloppy programming to me and seems intentional.

I expected to see 2 connections here: a connection to my VPN and to a SecureDNS choice that was not google. I am really upset about this and will likely never buy another product from your company and may throw out what I have and buy other things. What is the purpose of router with a VPN that always connects to google? If port 0 does not connect to google, why have this show up? Also, from what I’ve read, asking to bind TCP on port 0 indicates a request to dynamically generate an unused port number. If this is not connecting to google, explain why this is here.

Clearly you rage has blinded you as you have left out vital information WHAT ROUTER? WHAT FIRMWARE? WHAT VPN SERVICE? Why did YOU not set up you own DNS correctly lots of help supplied on this forum no need to be a jerk because of you mistake. Throw it out and buy a ASUS or Netgear with the proprietary software that Is much more Google friendly.

I am a private person. I use a gl.inet router using the gl.inet interface. I use OpenVPN and I don’t see how the maker of the VPN would lead to leaks with OpenVPN turned on and also kill switch on and also VPN option on to send all processes through the VPN.

The VPN has a built in DNS and I get this showing even if I use one of the built in SecureDNS servers. It doesn’t matter what settings I use, this gl.inet router tries to contact google dns.

I am not being a jerk and this is not my mistake. I really like gl.inet and their router has been constantly sending packets to google while claiming to protect my privacy?

There are other options that aren’t proprietary. It isn’t a choice between a proprietary router and one that pings a google DNS server constantly. If the VPN is defective somehow the kill switch should lock the router, not send a bunch of packets to a google dns address.

If there are DNS settings, and I select a secure DNS server and have a VPN and request all processes go through the VPN, how could I be incorrectly setting up a DNS server? I really liked gl.inet, but this seems more than just bad programming, this seems intentional. If dns.google:0 doesn’t generate traffic despite showing packets in the list, that would change things but then I would like to know why that is even generated.

What you are probably seeing is the actions of mwan3 plug-in, which manages multiple WAN connections. Take a look at:

I turn this off on my routers and I do not think that this should be the default setting in the GL iNet routers. You should have to turn this function on manually with a note that it is going to constantly ping Googles DNS servers.

1 Like

Since you are to private to even give the router model, firmware or vpn service no one can help you.
Did you have DNS Rebinding Attack protection on? What about Override DNS Settings for All Clients? DNS authoritative order? No mention. Why not use DNS over TLS?

it is mwan3.

SSH to the router and remove all the info in /etc/config/mwan3 and remove mwan3 package. Reboot router and done.

1 Like

WHY IS YOUR DEFAULT SETTING TO ALWAYS PING GOOGLE DNS EVERY SECOND?

YOU SHOULD LET YOUR USERS KNOW THAT BY DEFAULT YOUR ROUTERS CONSTANTLY PING GOOGLE OUTSIDE OF AN ALWAYS-ON VPN WITH A KILL SWITCH AND NOT MAKE THIS SOME HIDDEN SETTING

THIS SHOULDN’T BE SOMETHING THAT HAS TO BE DISCOVERED BY EXAMINING WHERE THE PACKETS ARE GOING. YOUR SETTINGS ARE MISLEADING AND THIS IS UNFAIR TO PEOPLE, IF YOU WANT TO PING GOOGLE BY DEFAULT YOU SHOULD TELL PEOPLE

THIS MAKES ME WONDER WHAT ELSE YOU ARE DECEPTIVE ABOUT. i will never buy gl.inet product again.

Although I agree with you that by default a router should not be sending out packets to google or anyone else, I find that their hardware is mostly good, and on most but unfortunately not all their routers, you can load the generic OpenWRT firmware, which does not by default have things like mwan3 running. Since you have already paid for the product, I would recommend trying the generic OpenWRT firmware if OpenWRT supports your router.

Except for two of their routers that I only use as travel routers which are an AR750s and a USB150, all the rest of my GL iNet products that I still have in service are running OpenWRT. I find OpenWRT more secure and up to date then the GL iNet firmware, but the GL iNet interface is just easier to use when on travel. I use ssh to disable things like mwan3 manually, do my own backups of the config directory, and have a procedure on what packages, scripts and tools I need to reload after every firmware update to have a working travel router. It is a royal pain, but I like the interface.

What exactly are you worried about? While not ideal, this is the MWAN3’s project decision and not GL-iNet’s. You can read other people talking about it at OpenWRT:

At the end of the day, GL-iNet products are built on OpenWRT and will share most of the same quirks.

When Use VPN for all processes on the router has been enabled in VPN Policies, the pings to Google DNS should be going through VPN also. LuCI may be showing the ping packets before they are then routed through the tunnel.

I do not work for and I do not have formal association with GL.iNet

I was going to say that we will provide an option to let the user set up multiple wan failover and balance. But your claim made me think a lot: what are human deceptive about …