Occasional DNS leak on Eddie 2.17.2 (openSUSE Tumbleweed)

[Ansuz 5]

On two occasions I've noticed DNS leaks showing up on ipleak.net.

When they did, the VPN DNS server appears along with varying numbers of ISP DNS servers (each time I refresh the page, different DNS servers appear). Sometimes only the VPN DNS server is listed which means I need to check for DNS leaks 2 or 3 times to be sure.

If I disconnect, disengage the network lock, re-engage the lock, and reconnect it still leaks.
If I disconnect, disengage the lock, and close Eddie before restarting Eddie and reconnecting to the VPN, it's ok.

I haven't found a way to reproduce it yet and I don't know when the problems start (if it starts leaking mid-session, when I first connect to the VPN, or when I first start Eddie).
Note that because of this issue I generally keep Eddie running and just disconnect/reconnect (disengaging/reengaging network lock) when needed, so I think it starts happening either mid-session or when I reconnect to the VPN. I don't know for sure because, while I make it a habit to check for leaks every time I connect, it's possible I forget to on some occasions.

The only workaround I've found is to check for DNS leaks 2 or 3 times every time I connect to the VPN, then, if there is a leak, close Eddie and restart it.

[Staff 9972]

Hello!

Please check your system DNS settings before and after the issue occurs. It's a trivial yet safest and fastest way to understand what happens. It's important to know that Eddie changes nameservers immediately after the VPN server DNS push. After that, and during the same VPN session, Eddie does not check or alter DNS anymore, so if "you" (your system) changes them on the fly, Eddie will not do anything.

Additionally, you must be aware that Eddie may NOT able to handle DNS properly in systems where systemd-networkd AND systemd-resolved run  (also important to know: systemd-resolved might run with or without systemd-networkd running).

Unless you have on-link DNS (an abomination for DNS leaks, which unfortunately is now available on Linux too) Linux has a global DNS, so DNS leaks simply don't exist (DNS queries are tunneled regardless the DNS server they are sent to). For various complications and combinations involving DNS please cross check: https://wiki.archlinux.org/index.php/Systemd-networkd

Kind regards

[Ansuz 5]

I still sometimes get DNS leaks with version 2.18.5beta but have found a fix (if it happens in a specific session):

systemctl restart nscd

Would it be possible to add an option to automatically restart the Name Service Cache Daemon to Eddie as part of its connection process?

[OpenSourcerer 1435]

5 hours ago, Ansuz said:

Would it be possible to add an option to automatically restart the Name Service Cache Daemon to Eddie as part of its connection process?

For such a niche request you should probably do it as a down-script or something. In the Events tab next to VPN down, enter something like systemctl restart nscd.

[Ansuz 5]

On 2/6/2020 at 5:11 PM, giganerd said:

For such a niche request you should probably do it as a down-script or something. In the Events tab next to VPN down, enter something like systemctl restart nscd.

Thanks, I didn't know about that option.

That's probably the best way if it's an isolated incident. Still good for the devs know about it in case it's potentially a bigger issue (for example, if it randomly happens on all Linux distros that use systemd). One thing to consider is that this might be affecting people without them realizing it since it doesn't happen all the time and not everyone will consistently verify their connection with ipleak.net. Those that it does affect might not find the answer here or know how to implement it (I don't know how to create a script file, but can probably figure it out).

Could you explain why the script should be associated with the VPN Down event instead of VPN Up? From the name of the event, it sounds like linking it with VPN Down would run the script, flushing the DNS when the VPN is disconnected, but this is an issue where DNS is leaking after the VPN is connected.

[OpenSourcerer 1435]

5 hours ago, Ansuz said:

Still good for the devs know about it in case it's potentially a bigger issue (for example, if it randomly happens on all Linux distros that use systemd)

Sure, but then the devs need to know of every DNS app which implements a DNS cache. nscd is just one, dnsmasq is a second, systemd-resolved another, etc. You'd need to find out which one is active and caching, because dnsmasq for example can have its cache disabled although it is running (which is why it is not enough to check for the app listening on 53).
And then there's things like Debian which doesn't even come with a DNS cache preinstalled.
 

Quote

Could you explain why the script should be associated with the VPN Down event instead of VPN Up? From the name of the event, it sounds like linking it with VPN Down would run the script, flushing the DNS when the VPN is disconnected, but this is an issue where DNS is leaking after the VPN is connected.

You wrote about cases when you disconnect, so VPN down seemed right. You can of course also do that before or after you connect.

[Staff 9972]

@giganerd
@Ansuz

Eddie tries to flush DNS cache by checking various processes and acting accordingly. nscd should be detected and restarted by both Eddie 2.16 and Eddie 2.18 (exactly with the purpose to flush DNS cache), we will check the anomaly. What is the exact distribution where the anomaly has been detected?

Kind regards
 

[Ansuz 5]

I'm using openSUSE Tumbleweed.

I'm using Tumbleweed-cli and was synced to the 2020-01-10 snapshot at the time I wrote the post but switched to the 2020-01-27 snapshot earlier today. It may take a few days for me to tell if it's still happening on the current snapshot.

I manually ran systemctl status nscd to check the active run time of the service before and after starting Eddie and the time didn't reset so the service wasn't restarted..

This is the first I've tried using this command before and after starting Eddie, so I don't know if this is normal, though.