Tutorial How to monitor DNS traffic in real-time

[eibgrad]

The following script allows for real-time monitoring of DNS on the router for the purposes of knowing what DNS servers are in use, and which network interfaces are being used.

merlin-dns-monitor.sh - Pastebin.com

Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.

pastebin.com

Overview

One of the most difficult aspects of the router for users is managing DNS. DNS configuration is distributed across the GUI, involving the WAN (w/ ISP, custom, and DoT options), DHCP server (with its own custom servers), the VPNs (w/ their Exclusive, Strict, Relaxed and Disabled options), DNS filters and their options, etc. Trying to understand exactly how DNS is being handled becomes quite difficult, esp. for those less familiar w/ the underlying system. It's darn near impossible to just look at GUI and all the relevant configuration pages and be sure it works the way you assume it works. There's a good chance you're wrong! And things can change over time, so what appears correct NOW may not be the case 30 minutes or an hour from now.

I'm aware that many ppl depend on online DNS leak testing tools for these purposes. But I don't trust them. Having a third-party *reliably* determine the actual DNS server(s) in use seems a near impossible task. And these websites rarely if ever explain their methodology. I assume it involves some Javascript "trickery" and/or WebRTC (which many ppl keep disabled, myself included). So you just have to take it on faith it's correct (good or bad results). Frankly, I can't understand how it could be accurate given the LAN clients are accessing DNS via the router's proxy, DNSMasq (at least by default).

That's why I threw together this simple utility.

How It Works

The most accurate means to determine which DNS servers are in use by the router, and how they are being routed, is to use connection tracking.

egrep 'dport=(53|853) ' /proc/net/nf_conntrack

The above one-liner will do more to keep you *accurately* informed about what's happening on the router than all the online DNS leaking testing tools put together.

The connection tracking system is constantly being updated w/ *all* the traffic from the LAN clients and the router. That's how the router maps outgoing traffic w/ incoming replies (and vice versa). NOTHING is more reliable than this part of the subsystem for such purposes.

All my script does is just put some fancy (but still useful) ornamentation around this one-liner. It's now easier to determine when you have a DNS leak, even if you don't understand connection tracking (which anyone w/ an interest in this topic should investigate; it's NOT difficult).

Compatibility

As of this moment, the script only supports IPv4, NOT IPv6. I may be able to add IPv6 support in the future, but I just don't have access to it at the moment.

Installation

The script installs into /tmp by default, since it's not expected the utility will be used on a regular basis, but just for temporary diagnostic purposes. But if you want to have it available and/or running permanently, you could install it to /jffs/scripts or wherever you prefer.

For immediate execution and monitoring (accepting all the defaults) ...

curl -kLs bit.ly/merlin-installer|tr -d '\r'|sh -s AGNF8cC8

Alternatively, to download the script and make changes ...

script=/tmp/tmpfile.$$.sh
curl -kLs bit.ly/merlin-installer|tr -d '\r'|sh -s -- --noexec AGNF8cC8 > $script
chmod +x $script
nano $script

Then execute the script to begin monitoring.

$script

Since the script is installed in /tmp, it will NOT survive a reboot.

Definitions

I've never found consensus on the definition of a DNS leak. So for the purpose of this post and the utility, here is *my* definition. A DNS leak is anytime you're using the ISP's DNS server(s), or any other DNS servers which the ISP can either eavesdrop on, or worse, hijack back to his own servers. Given this definition, simply avoiding the ISP's DNS server(s) is NOT sufficient, if all you end up doing is routing your alternative DNS server(s) (e.g., Cloudflare) "in the clear" over the WAN. OTOH, DoT is NOT considered a DNS leak since it's encrypted, even if routed over the WAN.

I realize others may quibble w/ that definition, but again, for the purposes discussed herein, those are the underlying assumptions.

Understanding the Results

The output is color-coded to make identification of problematic connections more obvious to the untrained eye. For the most part, the only connections you need to concern yourself w/ are those in RED, since they represent traditional Do53 (in the clear) queries sent over the WAN. But NOT all such connections are necessarily a problem. For example, if you're double NAT'd and the router is getting *local* name resolution from a *local* upstream DNS server, this is probably safe. OTOH, if your landlord is offering his own internet connection to you on his private network, perhaps that's a concern. But the script has no way to know one way or the other. YOU have to properly interpret the results in that case.

I also include other relevant information in the header to make interpretation easier, such as WAN/LAN ip, DNS configuration on the WAN vs. LAN (DHCP server), DoT, DNS configuration on any active OpenVPN clients, etc.

As the system configuration changes (due to the starting/stopping of OpenVPN clients, changes to the VPN Director, etc.), the output will change accordingly. You may find the LAN clients and/or router using different DNS servers and/or network interfaces. But beware; the old connections will NOT disappear instantaneously! They'll persist for a short period (perhap several minutes) until they're finally starved of all activity. So don't jump to the conclusion that something isn't working properly until you give the changes time to settle.

Practical Limitations

In order to keep the display limited to the available screen size (or as best possible), the script ignores duplicates. IOW, what you're seeing on the screen is NOT all the connections from a given LAN client or the router, but only those that are unique, since the purpose of the script is not to monitor the *amount* of DNS activity, but simply how it's being handled. Even so, you'll probably have to expand your terminal window vertically to prevent the header from scrolling off the screen if you have a particularly busy system (I may address that in a later update).

Preserving Results for Later Review

I provided a logging option (disabled by default) to record these problematic connections. But in order to keep the file a manageable size, it too ignores duplicates. If you hit Ctrl-C to exit the utility, it will report the log file by name (since it varies each time you run it). You can easily browse it using the less command.

Alternative Persistent Setup

If you wish to have the utility run continuously, even when you log off ssh, I recommend installing Entware using AMTM and including the screen utility.

opkg install screen

The screen utility allows you to run the script in the background, detached from your current ssh session.

/opt/sbin/screen -dmS dnsmon </path/script-name>

You can then reattach to the running script at any time, from any ssh session, on any client machine!

/opt/sbin/screen -r dnsmon

And detach w/ Ctrl-A D.

You could even configure the init-start script to call the screen utility to have DNS monitoring (and logging) available at the earliest possible moment after bootup!

(
until [ -f /opt/sbin/screen ]; do sleep 10; done
/opt/sbin/screen -dmS dnsmon /jffs/scripts/merlin-dns-monitor.sh
) &

Feedback

I still consider this a WIP (work in progress). But I thought it good enough (and useful enough) to be worth offering NOW, and frankly, I could benefit from any feedback. I'm willing to make changes if it helps improve things.

Final Thoughts

The limits of a single post in this forum make it impossible for me to provide specific examples of the output and how to correctly interpret it. I will do that in follow-up posts. The goal w/ this post is simply to "get it out there". I realize it will take some time before it's fully understood.

Enjoy!

 

[eibgrad]

For the following example, I have a router in my lab with its WAN patched to the private network (192.168.63.0/24) and an assigned IP of 192.168.63.102. That router is hosting a local network of 192.168.1.0/24, and there's presently one active LAN client that's been assigned the IP of 192.168.1.7.

Everything else is plain vanilla. The WAN is configured w/ a DNS of 192.168.63.1 and the LAN clients are configured by DHCP to use the router (192.168.1.1) as their DNS proxy.

In the above snapshot, there are two active connections, one from the LAN client to the router (specifically DNSMasq), and another from DNSMasq out to the public DNS server on behalf of that LAN client.

The first pair of src+dst fields shows the IPs from the perspective of the sender, while the second pair of src+dst fields show the IPs from the perspective of the recipient.

The key to understanding how DNS was handled in this case is the second pair of src+dst fields on the router's connection (the second one). You know it was sent to 192.168.63.1 and over the WAN since the recipient is sending the replies back to the WAN ip. That's a potential DNS leak, so it's color-coded in RED. But the connection between the LAN client and router is GREEN since it's an entirely local connection.

You may be asking, "Can't I just consider the dst field from the sender to know which network interface was used"? In this case, yes, but not always, as I'll illustrate in future examples.

What connection tracking can't tell you is exactly which local connections are associated w/ which remote connections. With a single LAN client, the association is obvious. But as the number of LAN clients increases, it gets harder to make that association, and to know where your DNS leaks are coming from in terms of which specific LAN clients. Esp. if your LAN clients are configured differently for DNS (e.g, only some are bound to a VPN w/ Exclusive).

---------------------------------------------------

In this next example, things get more interesting.

The configuration remains the same, but I've now enabled OpenVPN client #3, which is configured w/ Exclusive for Accept DNS Configuration, and routing policy is configured to route 192.168.1.0/24 over the VPN.

Notice that now the LAN client of 192.168.1.7 has a connection that suggests it's connecting to the router @ 192.168.1.1, but the recipient proves otherwise. The use of Exclusive w/ the OpenVPN client has introduced a redirection (DNAT) from the router and directly to the VPN's DNS server @ 103.86.96.100. And we know it was sent over the VPN because the second dst field contains the IP assigned to the OpenVPN client's network interface (tun13), specifically 10.8.1.12. Notice there's also *two* such connection, one udp, the other tcp. And since enabling the VPN takes the router itself OFF the VPN, it continues to use the WAN for its own name resolution.

Is that a DNS leak? Depends on your interpretation. Some ppl would say yes because you are sending DNS in the clear over the WAN. Others would say no because it wasn't their intention to route anything over the VPN other than the LAN clients defined in routing policy (which for these purposes, does NOT include the router).

Doesn't include the router? Why? Because the router is the one hosting the internet connections, WAN and VPN, and therefore doesn't rely on the LAN network interface to control its routing in this regard. It routes directly through either one of those network interfaces depending on the current configuration, which in this case is the WAN.

Also notice, this is why when using Exclusive w/ routing policy enabled, those bound to the VPN don't have access to DNSMasq and its features (local name resolution, ad blocking, etc.). DNSMasq is entirely bypassed. That would NOT be the case if you were NOT using routing policy.

---------------------------------------------------

In this next example, we configure DoT on the WAN, using the AdGuard Family servers (94.140.14.15 and 94.140.15.16). Everything we leave as before. The WAN is configured w/ DHCP, and the DHCP server will be configured with the same servers. At least until Stubby (the DoT service) starts up and reconfigures both the WAN and DHCP server to include its own loopback IP and port (127.0.1.1:53).

In the above snapshot, Stubby has NOT replaced what's configured on the WAN, but just added itself as another option. However, the DHCP server has recognized the domain name from the WAN and used it to limit access of the DNS server @ 192.168.63.1 to only that local domain (yankee). Otherwise, all the LAN clients use Stubby's DNS servers.

IOW, the LAN clients are completely protected against DNS leaks, but the router is another story. Its DNS usage teeters back and forth between 192.168.63.1 and the DoT DNS servers.

This is yet another example of how things don't always work as expected. I think most ppl would assume that once DoT was configured on the WAN, the WAN would use it *exclusively*. Afterall, that's what happens to the LAN clients given how the DHCP server is reconfigured. But that's simply NOT the case.

The way to prevent this is to set "Connect to DNS server automatically" to No, then leave the custom server fields *empty* (!), leaving the router with no other options. Of course, that assumes the lack of a Do53 server doesn't prevent DoT/Stubby from getting established. Frankly, I'm not sure. This might be a chicken and egg problem.

Once again, without the script, who would even notice? Even if you could use online testing tools, the problem would be intermittent and easily pass muster given bad timing.

 

[eibgrad]

Additional Information (in no particular order of importance)

Three-Step Process

I consider this script the first of a potential three-step process.

Step #1: If you get all GREEN, then you're probably good to go. But I also recommend you monitor things over time as well (e.g., 24 hours). That's where the logging feature might come in handy. Or even consider a persistent install as described in the initial post, so you can see what's happening at the earliest possible moments, if that's of any interest to you (may be overkill for most ppl).

If you find problems/concerns, and you can't determine the cause, it might be time to take the next step.

Step #2: Add the log-queries=extra directive to DNSMasq by copy/pasting the following script into the window of an ssh session and rebooting.

CONFIGS_DIR='/jffs/configs'
CONFIG="$CONFIGS_DIR/dnsmasq.conf.add"

mkdir -p $CONFIGS_DIR

create_config() {
cat << 'EOF' > $CONFIG
log-queries=extra
EOF
}

if [ -f $CONFIG ]; then
    echo "error: $CONFIG already exists; requires manual installation"
else
    create_config
    echo 'Done.'
fi
:

As with any form of user-defined scripting and custom config files, make sure you have that feature enabled under Administration->System.

Now all your DNS queries, in detail, will be dumped to the syslog for your review.

grep dnsmasq /tmp/syslog.log | less

Or for monitoring purposes …

grep dnsmasq | tail -F /tmp/syslog.log

If the above still leaves you puzzled ...

Step #3: You need to take out the big guns, which requires installation of Entware w/ AMTM and installing the tcpdump package. At that point, you can examine the actual DNS traffic in its most raw form.

tcpdump -vv -i $(nvram get wan0_ifname) udp port 53 or tcp port 53 or tcp port 853

Since DNS port 53 is always "in the clear", it might reveal the problem rather quickly, unlike most other protocols these days that are encrypted.

Of course, the "big idea" here is to prevent the need to go beyond Step #1 for *most* users, since by the time you hit Step #3, you're now "into the weeds". But in some cases, you may have no choice. The script simply doesn't provide enough details to always determine what's happening. But in most cases, I suspect it will suffice.

 

[ZebMcKayhan]

Nice script!

My intention is to have everything via dnsmasq to Unbound which queries out wireguard.
Seeing mostly local green ones and one red line with the source of my wan ip to my isp dns, which I'm assuming is the router connection tracking, but how could I tell?

//Zeb

 

[eibgrad]

Nice script!

My intention is to have everything via dnsmasq to Unbound which queries out wireguard.
Seeing mostly local green ones and one red line with the source of my wan ip to my isp dns, which I'm assuming is the router connection tracking, but how could I tell?

//Zeb

I don't have enough context to correctly interpret what you're seeing.

 

[eibgrad]

Nice script!

My intention is to have everything via dnsmasq to Unbound which queries out wireguard.
Seeing mostly local green ones and one red line with the source of my wan ip to my isp dns, which I'm assuming is the router connection tracking, but how could I tell?

//Zeb

As I thought more about what you said, I have a theory as to what you're seeing. And if I'm right, it further illustrates why a tool like this is so helpful.

What I suspect is that you've configured the DHCP server to use your alternate DNS server. But that has NO EFFECT on the router itself. The router itself always uses the DNS defined on the WAN, whether from the ISP, or custom servers. DNSMasq then copies those down to its own configuration files for the benefit of the LAN clients, since they will be configured to use the router as their DNS proxy. But if you choose to override DHCP w/ some other DNS server, this does NOTHING to change the behavior of the router wrt its own use of DNS. It will continue to use the WAN.

As I asked in the second post above, the one w/ the examples, is this a DNS leak? It depends on your interpretation. Maybe your intent and concern is only for the LAN clients. OTOH, some would consider *any* leakage, the router included, as a DNS leak. But you could easily miss the fact the router was still bound to the WAN if all you relied on was online leak testing tools (assuming they're accurate), since presumably they're only evaluating the LAN clients, NOT the router.

That's why I said initially, YOU have to look at the results and decide if any of the RED entries are of actual concern. All the script can do is make you aware of the possibility of DNS leaks.

 

[chongnt]

Nice script!

My intention is to have everything via dnsmasq to Unbound which queries out wireguard.
Seeing mostly local green ones and one red line with the source of my wan ip to my isp dns, which I'm assuming is the router connection tracking, but how could I tell?

//Zeb

Do you mean something like this?
The first line in red is my WAN IP to my ISP DNS. My client .21 is sending to router .1. And in turn router as source is sending over to outside world, the return pair dst is wireguard interface 10.5.0.2?

 

[SomeWhereOverTheRainBow]

The following script allows for real-time monitoring of DNS on the router for the purposes of knowing what DNS servers are in use, and which network interfaces are being used.

merlin-dns-monitor.sh - Pastebin.com

Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.

pastebin.com

Overview

One of the most difficult aspects of the router for users is managing DNS. DNS configuration is distributed across the GUI, involving the WAN (w/ ISP, custom, and DoT options), DHCP server (with its own custom servers), the VPNs (w/ their Exclusive, Strict, Relaxed and Disabled options), DNS filters and their options, etc. Trying to understand exactly how DNS is being handled becomes quite difficult, esp. for those less familiar w/ the underlying system. It's darn near impossible to just look at GUI and all the relevant configuration pages and be sure it works the way you assume it works. There's a good chance you're wrong! And things can change over time, so what appears correct NOW may not be the case 30 minutes or an hour from now.

I'm aware that many ppl depend on online DNS leak testing tools for these purposes. But I don't trust them. Having a third-party *reliably* determine the actual DNS server(s) in use seems a near impossible task. And these websites rarely if ever explain their methodology. I assume it involves some Javascript "trickery" and/or WebRTC (which many ppl keep disabled, myself included). So you just have to take it on faith it's correct (good or bad results). Frankly, I can't understand how it could be accurate given the LAN clients are accessing DNS via the router's proxy, DNSMasq (at least by default).

That's why I threw together this simple utility.

How It Works

The most accurate means to determine which DNS servers are in use by the router, and how they are being routed, is to use connection tracking.

egrep 'dport=(53|853) ' /proc/net/nf_conntrack

The above one-liner will do more to keep you *accurately* informed about what's happening on the router than all the online DNS leaking testing tools put together.

The connection tracking system is constantly being updated w/ *all* the traffic from the LAN clients and the router. That's how the router maps outgoing traffic w/ incoming replies (and vice versa). NOTHING is more reliable than this part of the subsystem for such purposes.

All my script does is just put some fancy (but still useful) ornamentation around this one-liner. It's now easier to determine when you have a DNS leak, even if you don't understand connection tracking (which anyone w/ an interest in this topic should investigate; it's NOT difficult).

Installation

The script installs into /tmp by default, since it's not expected the utility will be used on a regular basis, but just for temporary diagnostic purposes. But if you want to have it available and/or running permanently, you could install it to /jffs/scripts or wherever you prefer.

For immediate execution and monitoring (accepting all the defaults) ...

curl -kLs pastebin.com/raw/AGNF8cC8 | tr -d '\r' | sh

Alternatively, to download the script and make changes ...

script=/tmp/tmpfile.$$.sh
curl -kLs pastebin.com/raw/AGNF8cC8 | tr -d '\r' > $script
chmod +x $script
nano $script

Then execute the script to begin monitoring.

$script

Since the script is installed in /tmp, it will NOT survive a reboot.

Definitions

I've never found consensus on the definition of a DNS leak. So for the purpose of this post and the utility, here is *my* definition. A DNS leak is anytime you're using the ISP's DNS server(s), or any other DNS servers which the ISP can either eavesdrop on, or worse, hijack back to his own servers. Given this definition, simply avoiding the ISP's DNS server(s) is NOT sufficient, if you end up routing your alternative DNS server(s) (e.g., Cloudflare) "in the clear" over the WAN. OTOH, DoT is NOT considered a DNS leak since it's encrypted, even if routed over the WAN.

I realize others may quibble w/ that definition, but again, for the purposes discussed herein, those are the underlying assumptions.

Understanding the Results

The output is color-coded to make identification of problematic connections more obvious to the untrained eye. For the most part, the only connections you need to concern yourself w/ are those in RED, since they represent traditional Do53 (in the clear) queries sent over the WAN. But NOT all such connections are necessarily a problem. For example, if you're double NAT'd and the router is getting *local* name resolution from a *local* upstream DNS server, this is probably safe. OTOH, if your landlord is offering his own internet connection to you on his private network, perhaps that's a concern. But the script has no way to know one way or the other. YOU have to properly interpret the results in that case.

I also include other relevant information in the header to make interpretation easier, such as WAN/LAN ip, DNS configuration on the WAN vs. LAN (DHCP server), DoT, DNS configuration on any active OpenVPN clients, etc.

As the system configuration changes (due to the starting/stopping of OpenVPN clients, changes to the VPN Director, etc.), the output will change accordingly. You may find the LAN clients and/or router using different DNS servers and/or network interfaces. But beware; the old connections will NOT disappear instantaneously! They'll persist for a short period (perhap several minutes) until they're finally starved of all activity. So don't jump to the conclusion that something isn't working properly until you give the changes time to settle.

Practical Limitations

In order to keep the display limited to the available screen size (or as best possible), the script ignores duplicates. IOW, what you're seeing on the screen is NOT all the connections from a given LAN client or the router, but only those that are unique, since the purpose of the script is not to monitor the *amount* of DNS activity, but simply how it's being handled. Even so, you'll probably have to expand your terminal window vertically to prevent the header from scrolling off the screen if you have a particularly busy system (I may address that in a later update).

Preserving Results for Later Review

I provided a logging option (disabled by default) to record these problematic connections. But in order to keep the file a manageable size, it too ignores duplicates. If you hit Ctrl-C to exit the utility, it will report the log file by name (since it varies each time you run it). You can easily browse it using the less command.

Alternative Persistent Setup

If you wish to have the utility run continuously, even when you log off ssh, I recommend installing Entware using AMTM and including the screen utility.

opkg install screen

The screen utility allows you to run the script in the background, detached from your current ssh session.

screen -dmS dnsmon </path/script-name>

You can then reattach to the running script at any time, from any ssh session, on any client machine!

screen -r dnsmon

And detach w/ Ctrl-A D.

You could even configure the init-start script to call the screen utility to have DNS monitoring (and logging) available at the earliest possible moment after bootup!

Feedback

I still consider this a WIP (work in progress). But I thought it good enough (and useful enough) to be worth offering NOW, and frankly, I could benefit from any feedback. I'm willing to make changes if it helps improve things.

Final Thoughts

The limits of a single post in this forum make it impossible for me to provide specific examples of the output and how to correctly interpret it. I will do that in follow-up posts. The goal w/ this post is simply to "get it out there". I realize it will take some time before it's fully understood.

Enjoy!

Nice job!, I feel like it is time to bring back the ol'wireshark tcp dump checks for verifying encryption as well. Great work!

 

[ZebMcKayhan]

But if you choose to override DHCP w/ some other DNS server, this does NOTHING to change the behavior of the router wrt its own use of DNS. It will continue to use the WAN.

Exactly, so I assume this is request is something the router itself does (not something requested from the clients). If I use dig on the router it will use wan isp dns.

If it is indeed the router pinging for checking its wan connection (aah, maybee that was a bad choice of words, sorry) I would not consider this a leak. But I may consider doing something about it.

I will need to investigate further what this request is about.

But again, thanks for a great tool!

//Zeb

 

[chongnt]

Exactly, so I assume this is request is something the router itself does (not something requested from the clients). If I use dig on the router it will use wan isp dns.

If it is indeed the router pinging for checking its wan connection (aah, maybee that was a bad choice of words, sorry) I would not consider this a leak. But I may consider doing something about it.

I will need to investigate further what this request is about.

But again, thanks for a great tool!

//Zeb

I send dns queries over to wireguard interface and thought everything was good. All test tell me my dns is my vpn provider ip. No leak.
You just got me do a tcpdump on my ppp0 interface. At first I noticed the query to dns.msftncsi.com happened about every 30 seconds which should be normal. Then I noticed something is not right. It seems for every dns resolution over wireguard interface, I see the same but PTR over my WAN to my ISP DNS. So it is silently leaked to my ISP

 

[ZebMcKayhan]

I send dns queries over to wireguard interface and thought everything was good. All test tell me my dns is my vpn provider ip. No leak.
You just got me do a tcpdump on my ppp0 interface. At first I noticed the query to dns.msftncsi.com happened about every 30 seconds which should be normal. Then I noticed something is not right. It seems for every dns resolution over wireguard interface, I see the same but PTR over my WAN to my ISP DNS. So it is silently leaked to my ISP

what an interesting find.... so, something is doing reverse DNS lookup on your requests? interesting too see if you could track down this.

I will try to tcpdump on my end, but I'll have to wait until I get home.

 

[chongnt]

I think I find the culprit. I enabled rDNS in AdGuard Home I installed recently. Disable rDNS seems to have stop sending PTR over WAN to my ISP DNS.

 

[chongnt]

@eibgrad , I saw your earlier post. I put the IP and dns.msftncsi.com in hosts file, at the same time I use VPN director to route the destination IP via VPN Client 1. It seems nf_conntrack has a "aging timer" of about 180 seconds. After that there is no more connection in red color. It is really convenient for a quick check.
For those of us with a number of addons, we may see some DNS query over WAN when certain cronjob is run. The way your tools present the data is very nice.

 

[dazedandlost]

Yet another superb example of why this is such an incredibly helpful place. Thank you!

 

[eibgrad]

@eibgrad , I saw your earlier post. I put the IP and dns.msftncsi.com in hosts file, at the same time I use VPN director to route the destination IP via VPN Client 1. It seems nf_conntrack has a "aging timer" of about 180 seconds. After that there is no more connection in red color. It is really convenient for a quick check.
For those of us with a number of addons, we may see some DNS query over WAN when certain cronjob is run. The way your tools present the data is very nice.

Sorry, I had to pull my earlier comments.

To restate …

I'm thinking it might be a good idea to add an option to "hush" certain known acceptable traffic across the WAN, such as the WAN check w/ dns.msftncsi.com, by temporarily adding an entry for it in the local hosts file (I can't mention //etc//hosts by its proper name due the forum blocking it for some reason, but //etc//hosts gets around the blocking and works programmatically).

host=$(nslookup dns.msftncsi.com | awk '/^Name:/,0 {if (/^Addr[^:]*: [0-9]{1,3}\./) print $3}')
echo "$host dns.msftncsi.com" >> //etc//hosts

That's one of the limitations of the script. There's no easy way based solely on monitoring connections to know WHY you're seeing traffic. You need to either add the log-queries=extra directive to DNSMasq or use tcpdump.

tcpdump -i eth0 udp port 53 or tcp port 53

But tcpdump can be like a firehose and a bit overwhelming. The idea behind the script is to keep things simple during initial evaluation of the router's handling of DNS. If you see problems, then obviously you may need these tools to determine precisely what's happening. And if I can eliminate known issues like the WAN check w/ dns.msftncsi.com, even just temporarily, that might be a worthwhile addition to the script.

 

[ZebMcKayhan]

You just got me do a tcpdump on my ppp0 interface. At first I noticed the query to dns.msftncsi.com happened about every 30 seconds which should be normal. Then I noticed something is not right.

Had a similar journey... when I ran tcpdump

tcpdump -i eth0 udp port 53 or tcp port 53

I was just flooded with request, scared my out of my pants! But turns out my daughter had connected to the guest wifi (which I setup as a failsafe when family works/study from home) so it requests plainly over wan, never intended to be used except for testing or last resort.
So I had "the talk" with her and she switched wifi.
Added dns.msftncsi.com to host file and now it's all green as far as the eye can see.

 

[eibgrad]

On a side note, it seems a little ridiculous just how often the WAN check is made, and that it requires a DNS lookup every time. Good grief. Efficiency doesn't appear to be ASUS's goal here.

 

[ColinTaylor]

On a side note, it seems a little ridiculous just how often the WAN check is made, and that it requires a DNS lookup every time. Good grief. Efficiency doesn't appear to be ASUS's goal here.

That's what I thought. But I suppose the counter argument is "how slow do you want it at detecting internet failures". The volume of traffic involved is tiny and there are people complaining in these forums that they have problems because the router isn't quick enough at detecting a failure. Damned if you do and damned if you don't.

 

[eibgrad]

That's what I thought. But I suppose the counter argument is "how slow do you want it at detecting internet failures". The volume of traffic involved is tiny and there are people complaining in these forums that they have problems because the router isn't quick enough at detecting a failure. Damned if you do and damned if you don't.

Good point. But I still think doing a DNS lookup each and every time is a bit over the top. Seems to me they could have tightened that up a bit. Not unless the ttl itself is set particularly low.

P.S. I also find it a bit confusing the Adminstration->System page has the Network Monitoring option, but is NOT selected by default. That suggests this process is NOT taking place by default. You would think it would be enabled by default, w/ the option to change the target or methodology, or even disable it. The logic behind all this may be known to others, but it's not something I normal mess with.

 

[ColinTaylor]

P.S. I also find it a bit confusing the Adminstration->System page has the Network Monitoring option, but is NOT selected by default. That suggests this process is NOT taking place by default. You would think it would be enabled by default, w/ the option to change the target or methodology, or even disable it.

That used to be the case but Asus made an upstream change which necessitated the new behaviour in 386.4.