Split DNS timeout

Viscosity Support (Windows)
1

OpenVPN (Viscosity) connected but DNS not resolving

I’m having an issue where my VPN connects successfully using Viscosity, but DNS resolution fails.

Symptoms

  • VPN connects normally

  • Internal network is reachable (I can ping internal IPs)

  • DNS queries time out:

nslookup google.com
→ DNS request timed out
  • The system is using this DNS:
fd53:7061:726b:4c61:6273:5669:7344:4e5c (Viscosity)

What I tested

  • Internal DNS server is reachable:
ping 192.168.211.101 → OK
  • DNS works when specified manually:
nslookup google.com 192.168.211.101 → OK
nslookup google.com 192.168.2.53 → OK

Full logs:

abr 08 10:28:54 AM: State changed to Connecting
abr 08 10:28:54 AM: Viscosity Windows 1.12.1 (1857)
abr 08 10:28:54 AM: Running on Microsoft Windows 11 Pro 64 bit
abr 08 10:28:54 AM: Running on .NET Framework Version 4.8.09221.533509
abr 08 10:28:54 AM: Checking reachability status of connection...
abr 08 10:28:54 AM: Connection is reachable. Starting connection attempt.
abr 08 10:28:54 AM: Interface Type: ViscTunTap
abr 08 10:28:54 AM: Bringing up interface...
abr 08 10:28:54 AM: 2026-04-08 10:28:54 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
abr 08 10:28:54 AM: OpenVPN 2.6.19 Windows [SSL (OpenSSL)] [LZO] [LZ4] [AEAD]
abr 08 10:28:54 AM: library versions: OpenSSL 3.0.19 27 Jan 2026, LZO 2.10
abr 08 10:28:54 AM: Virtual Adapter Version: 0.10.2.1023
abr 08 10:28:54 AM: Resolving address: "petrosoft.no-ip.org"
abr 08 10:28:54 AM: Valid endpoint found: petrosoft.no-ip.org:2194:udp
abr 08 10:28:54 AM: WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
abr 08 10:28:55 AM: TCP/UDP: Preserving recently used remote address: [AF_INET]177.129.15.94:2194
abr 08 10:28:55 AM: UDPv4 link local: (not bound)
abr 08 10:28:55 AM: UDPv4 link remote: [AF_INET]177.129.15.94:2194
abr 08 10:28:55 AM: State changed to Autenticando
abr 08 10:28:55 AM: [alhena] Peer Connection Initiated with [AF_INET]177.129.15.94:2194
abr 08 10:28:55 AM: State changed to Connecting
abr 08 10:28:55 AM: Awaiting adapter to come up...
abr 08 10:28:55 AM: Third-party filters attached to network interface: "Npcap Packet Driver (NPCAP) (INSECURE_NPCAP)".
abr 08 10:28:56 AM: TAP-WIN32 device [alhena] opened: \\?\root#net#0001#{adda4c48-c32e-4ef6-9602-b3252f082583}, index: 32
abr 08 10:28:57 AM: Waiting for DNS Setup to complete...
abr 08 10:28:57 AM: Successful ARP Flush on interface [32] {F6657F00-259B-45F2-BDD5-CD3CC7F093A4}
abr 08 10:29:01 AM: Initialization Sequence Completed
abr 08 10:29:02 AM: DNS set to Split, report follows:
Server: [2804:5c:65f7:bd00:be24:11ff:feee:ff4c]:53, Lookup Type: Any, Domains: localdomain.
Server: 192.168.2.52:53, Lookup Type: Any, Domains: localdomain.
Server: 192.168.211.101:53, Lookup Type: Split, Domains: petrosoftdesign.com.
abr 08 10:29:02 AM: State changed to Conectado

Any help is appreciated :+1:

2

Hi mateus2k2,

Thank you for posting detailed information about the issue you are running into. Your VPN connection is configured to use Split DNS, which means it should only be using the VPN DNS servers for the petrosoftdesign.com domain, and your local DNS servers for all other lookups.

If this isn’t your intention (i.e. you’d prefer all lookups to use the VPN DNS servers) then you can change the DNS Mode to Full DNS: Configuring DNS and WINS settings - SparkLabs

If you want to get Split DNS working, then it’ll be necessary to find out why lookups to the local 2804:5c:65f7:bd00:be24:11ff:feee:ff4c server are failing. Can you post a copy of your log with increased logging, along with a copy of the raw configuration data, and we can take a better look. Steps for how to do this can be found at: Logs and Information to Provide Support Staff - SparkLabs

Purely as a guess at this stage, I’d say your local IPv6 DNS server might not be contactable while connected to the VPN connection as the server could be pushing out the block-ipv6 command (or it is set locally).

Regards,
Aaron

3

Yes, I do want to get Split DNS workking, and it was working until yesterday, here are the logs with verb5:

abr 09 8:33:01 AM: State changed to Connecting
abr 09 8:33:01 AM: Viscosity Windows 1.12.1 (1857)
abr 09 8:33:01 AM: Running on Microsoft Windows 11 Pro 64 bit
abr 09 8:33:01 AM: Running on .NET Framework Version 4.8.09221.533509
abr 09 8:33:01 AM: Checking reachability status of connection...
abr 09 8:33:01 AM: Connection is reachable. Starting connection attempt.
abr 09 8:33:01 AM: Interface Type: ViscTunTap
abr 09 8:33:01 AM: Bringing up interface...
abr 09 8:33:01 AM: 2026-04-09 08:33:01 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
abr 09 8:33:01 AM: Current Parameter Settings:
abr 09 8:33:01 AM:   config = 'stdin'
abr 09 8:33:01 AM:   mode = 0
abr 09 8:33:01 AM:   show_ciphers = DISABLED
abr 09 8:33:01 AM:   show_digests = DISABLED
abr 09 8:33:01 AM:   show_engines = DISABLED
abr 09 8:33:01 AM:   genkey = DISABLED
abr 09 8:33:01 AM:   genkey_filename = '[UNDEF]'
abr 09 8:33:01 AM:   key_pass_file = '[UNDEF]'
abr 09 8:33:01 AM:   show_tls_ciphers = DISABLED
abr 09 8:33:01 AM:   connect_retry_max = 0
abr 09 8:33:01 AM: Connection profiles [0]:
abr 09 8:33:01 AM:   proto = udp
abr 09 8:33:01 AM:   local = '[UNDEF]'
abr 09 8:33:01 AM:   local_port = '[UNDEF]'
abr 09 8:33:01 AM:   remote = 'petrosoft.no-ip.org'
abr 09 8:33:01 AM:   remote_port = '2194'
abr 09 8:33:01 AM:   remote_float = DISABLED
abr 09 8:33:01 AM:   bind_defined = DISABLED
abr 09 8:33:01 AM:   bind_local = DISABLED
abr 09 8:33:01 AM:   bind_ipv6_only = DISABLED
abr 09 8:33:01 AM:   connect_retry_seconds = 1
abr 09 8:33:01 AM:   connect_timeout = 120
abr 09 8:33:01 AM:   socks_proxy_server = '[UNDEF]'
abr 09 8:33:01 AM:   socks_proxy_port = '[UNDEF]'
abr 09 8:33:01 AM:   tun_mtu = 1500
abr 09 8:33:01 AM:   tun_mtu_defined = ENABLED
abr 09 8:33:01 AM:   link_mtu = 1500
abr 09 8:33:01 AM:   link_mtu_defined = DISABLED
abr 09 8:33:01 AM:   tun_mtu_extra = 0
abr 09 8:33:01 AM:   tun_mtu_extra_defined = DISABLED
abr 09 8:33:01 AM:   tls_mtu = 1250
abr 09 8:33:01 AM:   mtu_discover_type = -1
abr 09 8:33:01 AM: NOTE: --mute triggered...
abr 09 8:33:01 AM: 221 variation(s) on previous 100 message(s) suppressed by --mute
abr 09 8:33:01 AM: OpenVPN 2.6.19 Windows [SSL (OpenSSL)] [LZO] [LZ4] [AEAD]
abr 09 8:33:01 AM: library versions: OpenSSL 3.0.19 27 Jan 2026, LZO 2.10
abr 09 8:33:01 AM: Virtual Adapter Version: 0.10.2.1023
abr 09 8:33:01 AM: Resolving address: "petrosoft.no-ip.org"
abr 09 8:33:01 AM: Valid endpoint found: petrosoft.no-ip.org:2194:udp
abr 09 8:33:01 AM: WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
abr 09 8:33:02 AM: Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
abr 09 8:33:02 AM: Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
abr 09 8:33:02 AM: Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
abr 09 8:33:02 AM: Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
abr 09 8:33:02 AM: LZO compression initializing
abr 09 8:33:02 AM: Control Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1250 tun_max_mtu:0 headroom:126 payload:1600 tailroom:126 ET:0 ]
abr 09 8:33:02 AM: Data Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1500 tun_max_mtu:1600 headroom:136 payload:1768 tailroom:562 ET:0 ]
abr 09 8:33:02 AM: TCP/UDP: Preserving recently used remote address: [AF_INET]177.129.15.94:2194
abr 09 8:33:02 AM: Socket Buffers: R=[65536->65536] S=[65536->65536]
abr 09 8:33:02 AM: UDPv4 link local: (not bound)
abr 09 8:33:02 AM: UDPv4 link remote: [AF_INET]177.129.15.94:2194
abr 09 8:33:02 AM: State changed to Autenticando
abr 09 8:33:02 AM: TLS: Initial packet from [AF_INET]177.129.15.94:2194, sid=63cda791 3c5487a9
abr 09 8:33:02 AM: VERIFY OK: depth=1, CN=alhena
abr 09 8:33:02 AM: VERIFY OK: depth=0, CN=alhena
abr 09 8:33:02 AM: Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, peer certificate: 2048 bits RSA, signature: RSA-SHA256, peer temporary key: 256 bits ECprime256v1
abr 09 8:33:02 AM: [alhena] Peer Connection Initiated with [AF_INET]177.129.15.94:2194
abr 09 8:33:02 AM: TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
abr 09 8:33:02 AM: TLS: tls_multi_process: initial untrusted session promoted to trusted
abr 09 8:33:02 AM: State changed to Connecting
abr 09 8:33:02 AM: SENT CONTROL [alhena]: 'PUSH_REQUEST' (status=1)
abr 09 8:33:02 AM: PUSH: Received control message: 'PUSH_REPLY,route 192.168.211.0 255.255.255.0,redirect-private,dhcp-option DNS 192.168.211.101,dhcp-option DOMAIN petrosoftdesign.com,route-gateway 10.9.0.1,topology subnet,ping 10,ping-restart 120,ifconfig 10.9.0.12 255.255.255.0,peer-id 5,cipher AES-256-GCM'
abr 09 8:33:02 AM: OPTIONS IMPORT: --ifconfig/up options modified
abr 09 8:33:02 AM: OPTIONS IMPORT: route options modified
abr 09 8:33:02 AM: OPTIONS IMPORT: route-related options modified
abr 09 8:33:02 AM: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
abr 09 8:33:02 AM: interactive service msg_channel=0
abr 09 8:33:02 AM: ROUTE_GATEWAY 192.168.2.1/255.255.255.0 I=3 HWADDR=88:c9:b3:bc:04:f6
abr 09 8:33:02 AM: Awaiting adapter to come up...
abr 09 8:33:02 AM: Third-party filters attached to network interface: "Npcap Packet Driver (NPCAP) (INSECURE_NPCAP)".
abr 09 8:33:03 AM: TAP-WIN32 device [alhena] opened: \\?\root#net#0001#{adda4c48-c32e-4ef6-9602-b3252f082583}, index: 32
abr 09 8:33:03 AM: TAP-Windows MTU=1500
abr 09 8:33:03 AM: Waiting for DNS Setup to complete...
abr 09 8:33:04 AM: Successful ARP Flush on interface [32] {F6657F00-259B-45F2-BDD5-CD3CC7F093A4}
abr 09 8:33:04 AM: do_ifconfig, ipv4=1, ipv6=0
abr 09 8:33:04 AM: Data Channel MTU parms [ mss_fix:1399 max_frag:0 tun_mtu:1500 tun_max_mtu:1600 headroom:136 payload:1768 tailroom:562 ET:0 ]
abr 09 8:33:04 AM: Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
abr 09 8:33:04 AM: Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
abr 09 8:33:04 AM: Data Channel: cipher 'AES-256-GCM', peer-id: 5, compression: 'lzo'
abr 09 8:33:04 AM: Timers: ping 10, ping-restart 120
abr 09 8:33:04 AM: TEST ROUTES: 2/2 succeeded len=1 ret=1 a=0 u/d=up
abr 09 8:33:04 AM: Route addition via service succeeded
abr 09 8:33:04 AM: Route addition via service succeeded
abr 09 8:33:04 AM: Initialization Sequence Completed
abr 09 8:33:04 AM: DNS set to Split, report follows:
Server: [2804:5c:65f7:bd00:be24:11ff:feee:ff4c]:53, Lookup Type: Any, Domains: localdomain.
Server: 192.168.2.52:53, Lookup Type: Any, Domains: localdomain.
Server: 192.168.211.101:53, Lookup Type: Split, Domains: petrosoftdesign.com.
abr 09 8:33:04 AM: State changed to Conectado

I can Ping fd53:7061:726b:4c61:6273:5669:7344:4e66

Adaptador desconhecido alhena:

   Sufixo DNS específico de conexão. . . . . . : petrosoftdesign.com
   Endereço IPv6 . . . . . . . . . . : fd53:7061:726b:4c61:6273:5669:7344:4e66
   Endereço IPv6 de link local . . . . . . . . : fe80::dd40:b128:b0a9:5869%32
   Endereço IPv4. . . . . . . .  . . . . . . . : 10.9.0.12
   Máscara de Sub-rede . . . . . . . . . . . . : 255.255.255.0
   Gateway Padrão. . . . . . . . . . . . . . . : 10.9.0.1

Config Data:

#-- Config Auto Generated By Viscosity --#

#viscosity protocol openvpn
#viscosity name alhena
#viscosity autoreconnect false
#viscosity dns split
#viscosity usepeerdns true
#viscosity manageadapter true
#viscosity startonopen false
remote petrosoft.no-ip.org 2194 udp
nobind
dev tun
persist-tun
persist-key
compress lzo
pull
auth-user-pass
tls-client
ca ca.crt
cert mateus.silva.crt
key mateus.silva.key
tls-crypt alhena.tlsauth
proto udp
auth-nocache
port 2194
cipher AES-256-GCM
dev-node {F6657F00-259B-45F2-BDD5-CD3CC7F093A4}
verb 5
4

Thanks for posting those additional details. A few things stand out that I recommend taking a look at:

  1. The log indicates that a third-party filter driver is attached to the VPN network interface: Third-party filters attached to network interface: "Npcap Packet Driver (NPCAP) (INSECURE_NPCAP)". Npcap is a network packet capture driver that is typically installed by network analysis tools (such as Wireshark) to enable network packets to be captured and read. I recommend making sure that any such tools aren’t accidentally configured to remove or modify DNS-related traffic, which could be the cause of the failures. It may be a good idea to try temporarily uninstalling any such software and see if the issue persists.

  2. The OpenVPN server is pushing the redirect-private command, which depending on the local configuration can result in loss of some local connectivity. It may be worth instructing Viscosity to ignore it by adding the command pull-filter ignore redirect-private as an advanced command for your connection.

  3. The fd53:7061:726b:4c61:6273:5669:7344:4e66 IPv6 address is Viscosity’s local DNS server for your connection, and you should always be able to ping that. However there is a different IPv6 address set on your local connection (2804:5c:65f7:bd00:be24:11ff:feee:ff4c) that may have connection issues while the VPN is connected. I recommend testing you can perform DNS lookups against it while connected, to see if there is a traffic issue there.

  4. I also recommend checking Viscosity’s “Block IPv6 traffic while connected to IPv4-only VPN connections” option under the Advanced section of the Settings window. This may come into play due to the redirect-private command use. You may want to try turning it off if it is on, and reconnecting your VPN connection, and see if there is any change in behaviour.

It may also be a good idea to try temporarily setting your computer’s normal DNS servers to something else (for example, Google’s DNS server’s of 8.8.8.8 and 8.8.4.4) just to rule out any issues with the local DNS server.

Cheers,
James

5

What happend was that the IPV6 from local DNS server had changed and viscosity is trying to resolve DNS using it, even if I mark “Block IPv6 traffic while connected to IPv4-only VPN connections”. After updating the DNS server ip in the router it worked.

6

Glad to hear you solved it. Thanks for posting your solution.

The “Block IPv6 traffic while connected to IPv4-only VPN connections” option is designed to block IPv6 traffic when connected to an IPv4-only VPN connection that is redirecting all traffic into it (rather for split-routed setups). We have some more information at the link below.

Cheers,
James