Troubleshooting problems with DNS requests

Got a problem with Viscosity or need help? Ask here!

floatingpurr

Posts: 3
Joined: Fri Jan 19, 2024 8:45 pm

Post by floatingpurr » Fri Jan 19, 2024 9:28 pm
Hello, I'm using viscosity 1.10.8 on macOS 14.2.1. A friend of mine has just sent to me the following OpenVPN configuration file for my client:

client.ovpn
Code: Select all
client
dev tun
remote <MY FRIEND'S IP> 1194 tcp
tun-mtu 1500
tls-client
nobind
user nobody
group nogroup
ping 15
ping-restart 45
ping-timer-rem
persist-tun
persist-key
mute-replay-warnings
verb 3
cipher AES-128-CBC
auth SHA1
pull
auth-user-pass
remote-cert-tls server
redirect-gateway def1
<ca>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</ca>
However, once connected I can't surf the internet at all. Using nslookup in combination with tcpdump, I figured out that the problem is related to the DNS requests. I'm not sure if this issue is strictly related to Viscosity or, more in general, to the OpenVPN settings. Anyway, if I start a capture and then I issue nslookup www.google.it, I get the following output:
Code: Select all
$ sudo tcpdump -ni any port 53
tcpdump: data link type PKTAP
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type PKTAP (Apple DLT_PKTAP), snapshot length 524288 bytes
18:30:19.403577 IP 127.0.0.1.55553 > 127.0.0.1.53: 14064+ A? www.google.it. (31)
18:30:19.403591 IP 127.0.0.1.55553 > 127.0.0.1.53: 14064+ A? www.google.it. (31)
18:30:20.404482 IP6 ::1.50658 > ::1.53: 14064+ A? www.google.it. (31)
18:30:20.404503 IP6 ::1.50658 > ::1.53: 14064+ A? www.google.it. (31)
18:30:25.409492 IP 127.0.0.1.55553 > 127.0.0.1.53: 14064+ A? www.google.it. (31)
18:30:25.409523 IP 127.0.0.1.55553 > 127.0.0.1.53: 14064+ A? www.google.it. (31)
18:30:26.414496 IP6 ::1.50658 > ::1.53: 14064+ A? www.google.it. (31)
18:30:26.414531 IP6 ::1.50658 > ::1.53: 14064+ A? www.google.it. (31)
That makes no sense, since there's no DNS running on localhost. To complete the scenario here is the routing with active tunnel:
Code: Select all
$ netstat -nr -f inet
Routing tables

Internet:
Destination        Gateway            Flags               Netif Expire
0/1                192.168.10.1       UGScg              utun10
default            192.168.1.1        UGScg                 en5
default            192.168.10.1       UGScIg             utun10
<FRIEND'S IP>/32   192.168.1.1        UGSc                  en5
127                127.0.0.1          UCS                   lo0
127.0.0.1          127.0.0.1          UH                    lo0
128.0/1            192.168.10.1       UGSc               utun10
169.254            link#13            UCS                   en5      !
192.168.1          link#13            UCS                   en5      !
192.168.1.1/32     link#13            UCS                   en5      !
192.168.1.1        10:71:b3:94:ce:70  UHLWIir               en5   1199
192.168.1.100/32   link#13            UCS                   en5      !
192.168.1.100      0:e0:4c:68:0:40    UHLWI                 lo0
192.168.10         192.168.10.42      UGSc               utun10
192.168.10.1/32    link#24            UCS                utun10
192.168.10.1       link#24            UHWIir             utun10
192.168.10.42      192.168.10.42      UH                 utun10
224.0.0/4          link#13            UmCS                  en5      !
224.0.0/4          link#24            UmCSI              utun10
224.0.0.251        1:0:5e:0:0:fb      UHmLWI                en5
239.255.255.250    1:0:5e:7f:ff:fa    UHmLWI                en5
239.255.255.250    link#24            UHmW3I             utun10   2400
255.255.255.255/32 link#13            UCS                   en5      !
255.255.255.255/32 link#24            UCSI               utun10
Finally, here's the log from Viscosity upon connection:
Code: Select all
Opened utun device utun10
/sbin/ifconfig utun10 delete
NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
/sbin/ifconfig utun10 192.168.10.42 192.168.10.42 netmask 255.255.255.0 mtu 1500 up
/sbin/route add -net 192.168.10.0 192.168.10.42 255.255.255.0
/sbin/route add -net <MY FRIEND'S IP> 192.168.1.1 255.255.255.255
/sbin/route add -net 0.0.0.0 192.168.10.1 128.0.0.0
/sbin/route add -net 128.0.0.0 192.168.10.1 128.0.0.0
Initialization Sequence Completed
DNS mode set to Full
State changed to Connected
As a temporary workaround, I'm setting DNS mode to Split DNS, and DNS works via my local resolver. I've been using Viscosity with OpenVPN for years without problems just importing *.ovpn files, Also in this case, I'd like to find a way to avoid such a manual workaround. Do I need to tell my friend that she should change something on her server side? Or can I fix just modifying the client.ovpn file?

floatingpurr

Posts: 3
Joined: Fri Jan 19, 2024 8:45 pm

Post by floatingpurr » Fri Jan 19, 2024 10:00 pm
Follow Up:

Strangely enough, the same conf file works with the OpenVPN connect client.

James

User avatar
Posts: 2309
Joined: Thu Sep 04, 2008 9:27 pm

Post by James » Mon Jan 22, 2024 9:47 pm
Hi floatingpurr,

It's difficult to tell without the full connection log, however as a guess it sounds like the VPN server isn't setting any DNS servers, or setting an invalid one. With Full DNS mode, this means that when you connect your computer won't have any DNS servers set. If this is the case, you can either get your friend to get their connection to push out one or more DNS servers, or set one in Viscosity:
https://www.sparklabs.com/support/kb/ar ... -settings/
Strangely enough, the same conf file works with the OpenVPN connect client.
The OpenVPN Connect client uses Google's DNS Servers for a VPN connection as a fallback, which is likely why it's working. We don't do the same thing in Viscosity because we don't think it's a good idea to unknowingly send all DNS lookups to Google. If you'd like the same behaviour you can set Google's DNS Servers for your connection:
https://www.sparklabs.com/support/kb/ar ... s-security

If you're still stuck, please post the details list at the following link and we can take a closer look:
https://www.sparklabs.com/support/kb/ar ... ort-staff/

Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs

floatingpurr

Posts: 3
Joined: Fri Jan 19, 2024 8:45 pm

Post by floatingpurr » Tue Jan 23, 2024 9:28 pm
Hi James,

thank you very much for your kind help. Indeed, it turned out that the problem was related to the DNS settings of the VPN server. Once fixed, the connection works in Viscosity, as well,

Take care.
4 posts Page 1 of 1