OpenVPN - some DNS resolve, others don't...

[nerf]

Hi all,

I have a small issue I wondering if someone has faced the same and maybe some help on how to approach this. I am running openvpn 2.4.11 (shipped with RHEL/CentOS 8).

I have my server configuration as follows:

View OriginalServer Config

port 1194
proto udp
dev tun
server 10.8.0.0 255.255.255.0
tls-server
topology subnet

ca /etc/openvpn/certs/ca.crt
cert /etc/openvpn/certs/cert.crt
key /etc/openvpn/certs/cert.key
dh /etc/openvpn/server/dh.pem
tls-crypt /etc/openvpn/myvpn.tlsauth

push "redirect-gateway def1"
push "dhcp-option DNS 10.8.0.1"
push "register-dns"

cipher AES-256-GCM
tls-version-min 1.2
auth SHA512
auth-nocache
keepalive 20 60
persist-key
persist-tun
compress lz4
daemon
user nobody
group nobody
max-clients 6

log-append /var/log/openvpn.log
status /var/log/openvpn-status.log
verb 3

username-as-common-name
verify-client-cert none
client-cert-not-required
auth-user-pass-verify "/etc/openvpn/auth.py" via-file
script-security 2

My client configuration as follows:

View OriginalClient Config

client
dev tun
proto udp
remote xxx.xxx.xxx.xxx 1194
persist-key
persist-tun
verb 3
remote-cert-tls server
cipher AES-256-GCM
auth SHA512
auth-nocache
tls-version-min 1.2
compress lz4
auth-user-pass

<ca>...</ca>

<tls-crypt>...</tls-crypt>

I have no errors no openvpn log except for a warning about link-mtu size being different....

The NAT rules are as follows (I have a more complex one but using this for troubleshooting):

Code: Select all

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -i eth0 -p udp -m state --state NEW -m udp --dport 1194 -j ACCEPT
-A INPUT -i tun0 -j ACCEPT
-A FORWARD -i tun0 -j ACCEPT
-A FORWARD -i tun0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o tun0 -j ACCEPT

The issue I have is the following and quite weird.... Client connects OK, can do some stuff, but DNS resolve fails in a very inconsistent matter, some domains it doesnt resolve at all.... here's an example (on client through vpn):

Code: Select all

nslookup
> server 10.8.0.1
Default server: 10.8.0.1
Address: 10.8.0.1#53
> youtube.com
Server:		10.8.0.1
Address:	10.8.0.1#53

Non-authoritative answer:
Name:	youtube.com
Address: 142.250.201.174
> www.youtube.com
;; connection timed out; no servers could be reached
> 

Now the same on VPN server:

Code: Select all

nslookup
> server 10.8.0.1
Default server: 10.8.0.1
Address: 10.8.0.1#53
> youtube.com
Server:		10.8.0.1
Address:	10.8.0.1#53

Non-authoritative answer:
Name:	youtube.com
Address: 142.250.201.174
Name:	youtube.com
Address: 2a00:1450:4007:81a::200e
> www.youtube.com
Server:		10.8.0.1
Address:	10.8.0.1#53

Non-authoritative answer:
www.youtube.com	canonical name = youtube-ui.l.google.com.
Name:	youtube-ui.l.google.com
Address: 216.58.204.110
Name:	youtube-ui.l.google.com
Address: 216.58.209.238
Name:	youtube-ui.l.google.com
Address: 216.58.204.142
Name:	youtube-ui.l.google.com
Address: 142.250.201.174
Name:	youtube-ui.l.google.com
Address: 142.250.179.110
Name:	youtube-ui.l.google.com
Address: 142.250.75.238
Name:	youtube-ui.l.google.com
Address: 216.58.214.78
Name:	youtube-ui.l.google.com
Address: 216.58.201.238
Name:	youtube-ui.l.google.com
Address: 142.250.178.142
Name:	youtube-ui.l.google.com
Address: 172.217.19.238
Name:	youtube-ui.l.google.com
Address: 172.217.18.206
Name:	youtube-ui.l.google.com
Address: 142.250.74.238
Name:	youtube-ui.l.google.com
Address: 216.58.213.142
Name:	youtube-ui.l.google.com
Address: 172.217.22.142
Name:	youtube-ui.l.google.com
Address: 216.58.213.174
Name:	youtube-ui.l.google.com
Address: 216.58.214.174
Name:	youtube-ui.l.google.com
Address: 2a00:1450:4007:80f::200e
Name:	youtube-ui.l.google.com
Address: 2a00:1450:4007:80a::200e
Name:	youtube-ui.l.google.com
Address: 2a00:1450:4007:818::200e
Name:	youtube-ui.l.google.com
Address: 2a00:1450:4007:819::200e
> 

I am using OpenVPN Connect on a OSX, but the same behavior is also seen on a Windows machine with OpenVPN Connect.
The only messages I get on OpenVPN are:

Code: Select all

xxx.xxx.xxx.xxx:49995 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1552', remote='link-mtu 1524'

Anyone has ever gone through the same? As some DNS seem not to resolve while a few others do? I know I am using a DNS at 10.8.0.1 for testing (powerdns recursor), but the same thing happens with any other DNS I use, Google, Cloudflare, corporate, ISP, etc. Some domains seem to resolver others dont.
Any advice (ICMP ping does work for any place, just DNS fails)?

[nerf]

I have done a bit more or debug, and found out that the openvpn server (10.8.0.1) actually replies to the client (10.8.0.2):

Code: Select all

19:28:11.665974 IP 10.8.0.2.56567 > 10.8.0.1.domain: 58670+ A? www.reddit.com. (32)
19:28:11.666118 IP 10.8.0.1.domain > 10.8.0.2.56567: 58670 2/0/0 CNAME reddit.map.fastly.net., A 151.101.121.140 (83)
19:28:16.670075 IP 10.8.0.2.56567 > 10.8.0.1.domain: 58670+ A? www.reddit.com. (32)
19:28:16.670201 IP 10.8.0.1.domain > 10.8.0.2.56567: 58670 2/0/0 CNAME reddit.map.fastly.net., A 151.101.121.140 (83)
19:28:55.653455 IP 10.8.0.2.50280 > 10.8.0.1.domain: 28616+ A? www.reddit.com. (32)
19:28:55.663641 IP 10.8.0.1.domain > 10.8.0.2.50280: 28616 2/0/0 CNAME reddit.map.fastly.net., A 151.101.121.140 (83)
19:29:00.658707 IP 10.8.0.2.50280 > 10.8.0.1.domain: 28616+ A? www.reddit.com. (32)
19:29:00.658813 IP 10.8.0.1.domain > 10.8.0.2.50280: 28616 2/0/0 CNAME reddit.map.fastly.net., A 151.101.121.140 (83)
19:29:05.662042 IP 10.8.0.2.50280 > 10.8.0.1.domain: 28616+ A? www.reddit.com. (32)
19:29:05.662142 IP 10.8.0.1.domain > 10.8.0.2.50280: 28616 2/0/0 CNAME reddit.map.fastly.net., A 151.101.121.140 (83)

but the tcpdump on the client side never registers the reply, so the reply is not received. Any help?

[TinCanTech]

Any help?

Probably, your firewall ..

[nerf]

there's no firewall on clients, and firewall on server is posted above without drop/reject rules anywhere.

It seems to be a problem with OpenVPN Connect; It works fine if I configure my router with it, it works fine if I use TunnelBlick on OSX, it breaks if I use OpenVPN Connect on OSX or Windows. I need to find another client for Windows and test.

So at this point through all the testing I made, it points to OpenVPN connect. Routes are good on server (and there's no firewalls):

Code: Select all

[root@fe01 server]# ip route get 10.8.0.2
10.8.0.2 dev tun0 src 10.8.0.1 uid 0 
    cache 

It is also not any mechanismo from my VPS provider.

[TinCanTech]

It is most likely your badly configured server firewall.

[nerf]

No, it's the client. Just tested on Windows with openvpn community, and it works too.... only happens with OpenVPN Connect. Problem solved, that client just went banned

Thanks for your help.

[TinCanTech]

only happens with OpenVPN Connect

This is equally unlikely.

If Openvpn-Connect were the source of the issue then that would be a serious bug
and would have been found by the dev team by now.

The fault lies with your server configuration .. but you are welcome to believe what-ever nonsense suits you.

[nerf]

Long are gone the times where I participated in open source projects as software maintainer (ex: opensuse/fedora), people usually before making bold statements would try to replicate. It should be easy because up above, you have:

1. openvpn server configuration
2. openvpn client configuration
3. output of iptables -S (which is pretty much the configuration of my firewall, anywhere to see DROP/REJECT rules)

You have other cute information to replicate:

1. On OSX it works fine with Tunnelblick and not with OpenVPN Connect
2. On Windows it works fine with openvpn community client and not with OpenVPN Connect (tested in two machines)
3. It works on Netduma/Mikrotik routers

If OpenVPN Connect was on Linux and I was too bored to check, I would probably run it under gdb to try and figure it out myself, thing is I can't really spend the time trying to debug software in a platform is not really user friendly for me (ex: Windows) or in one that I use but never developed for (OSX).

So you can either take the info and do what I would do if I was software maintainer, try to replicate a potential bug that might arise in given conditions and check it out. Or you can just rule out the software is OK and everything is incompetence on my side... or maybe making bold statements after firewalls even with the firewall rules posted and ensurance there is no firewall on client side.... Maybe I have some weird rule on my firewall checking for strings on packets and if I get a string that matches OpenVPN Connect is just drops the packet (which I don't)....

Thanks for your time, and help. Not in the mood for debugging in OSX or Windows, when I have other clients that are working. Situation is solved for me. Please close the topic/whatever you do in this cases.

[TinCanTech]

It's your network and your client ..

If you are satisfied that you have done your job effectively then you will be confident to show this thread to your client.

I maintain my position, you have not resolved the problem.

[nerf]

How much for payed support?

[TinCanTech]

To whom are you directing your request ?

[nerf]

whoever provides support for openvpn connect, if they have a service

[TinCanTech]

Best place to start is here:
viewtopic.php?f=30&t=22603

[nerf]

OK thanks. I guess I won't be needing it anyway.... replaced OpenVPN by IPsec... My client is happy now, my kids have now a gateway capable of handling DDoS and can enjoy playing online a bit more protected.

[TinCanTech]

IPsec ..

[nerf]

https://www.wireguard.com/