New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
O.o that's like saying:
"The GPS in my car sometimes doesn't work" - "try driving a mercedes"
@mailinabox seriously?
are you routing DNS queries through the VPN? If so - which DNS server are you using? If you don't mind having DNS leakage when you test, try disabling redirect-gateway feature and see if you still having this issue. What domains aren't resolving?
I am not sure.
This was the conf I imported
Let's just say some domains
Are you certain those domains exists and that there are records to resolve? If you try to resolve them using an online tool like MXtoolbox, do they resolve? If you do a whois lookup, are there name servers for that domain?
Also - from your ovpn, I can't tell if are resolving through your local connection or proxying DNS query's through your VPN. If you are using Windows, quick way to check resolution is to use nslookup and do a "set debug". And then type in the hostname, you are trying to resolve.
Sounds like you may be using a DNS server which is denying access if those are domains which are sketchy.
Do you push dns servers in the openvpn server config?
Yes, the domains exist and resolve.
I am on linux and if I run dig domain.com the result says
SERVER: 127.0.1.1#53(127.0.1.1)
so I guess it's using the local connection.Here is the thing, the domains I am talking about are blocked in my country so it could be on the DNS level, I am not sure. I wouldn't say all the domains are sketchy, at one point even youtube was blocked. Anyway that's a completely different topic.
Btw, thank you for looking into this
I believe yes, this is from the server config
That's because you are using a Linux distro that's using the systemd-resolved daemon.
I was going to ask you to try a +trace on dig but unfortunately resolved has a problem that breaks dig's trace capability.
If I remember how openvpn works, that's going to cause your Linux box to use those two Google public DNS servers instead of routing your DNS queries through the VPN. That kinda makes sense why those hostnames are not resolving if DNS queries are being intercepted.
You have to push a DNS proxy address. Normally, that would be the VPN server private internal address. The address would be a 10.x.x.x or similar RFC1918 address.
I tried the same configuration on android with OpenVPN Connect app and everything seems to be working fine so I guess there is something wrong with the desktop, not the server.
If you're using systemd-resolved, you're probably going to have to reference your VPN's DNS server in a .network file under
/etc/systemd/network/
. You could also override your global DNS settings in/etc/systemd/resolved.conf
; that's simpler, but if your VPN goes down, name resolution goes down with it.You can check what DNS servers systemd-resolved is using at
/run/systemd/resolved/resolv.conf
, or runresolvectl status
orsystemd-resolve --status
.Or just dump systemd-resolved altogether and use the tried-and-true
/etc/resolv.conf
.Okay so I was using NetworkManager, and not systemd-resolved. The
/etc/resolv.conf
is being generated automatically by the NM and not a good idea to edit directly.While searching, I found out 2 ways to get around this. One, there is
update-resolv-conf
script for openvpn. It basically gets the pushed dns servers and adds them toresolv.conf
. Have to launch openvpn from the terminal for this to work. And second, was to disablednsmasq
for NM. I don't know if there are any consequences for this but I guess we'll find out soon.Anyway it's all good now. @birchbeer @drivex @seanho thanks so much for giving me the direction.