OpenVPN Connect 3.9 (5008) - DNS Servers, Gateway not applied

reptileqc

I am connecting to a Watchguard VPN with SSL server and the DHCP-options are set properly. I even tried to add them on the client side (into the .opvn file) and I can see in the logs that they then appear twice.

When I connect using the Watchguard VPN client, I get the correct Gateway and DNS info :

Carte inconnue Connexion au réseau local :

   Suffixe DNS propre à la connexion. . . : wow.local
   Description. . . . . . . . . . . . . . : TAP-Windows Adapter V9
   Adresse physique . . . . . . . . . . . : 00-FF-1A-75-4C-F2
   DHCP activé. . . . . . . . . . . . . . : Oui
   Configuration automatique activée. . . : Oui
   Adresse IPv6 de liaison locale. . . . .: fe80::6655:a70c:aca8:ab8%5(préféré)
   Adresse IPv4. . . . . . . . . . . . . .: 192.168.113.5(préféré)
   Masque de sous-réseau. . . . . . . . . : 255.255.255.0
   Bail obtenu. . . . . . . . . . . . . . : 2 octobre 2026 10:05:47
   Bail expirant. . . . . . . . . . . . . : 2 octobre 2027 10:05:47
   Passerelle par défaut. . . . . . . . . :
   Serveur DHCP . . . . . . . . . . . . . : 192.168.113.254
   IAID DHCPv6 . . . . . . . . . . . : 922812186
   DUID de client DHCPv6. . . . . . . . : 00-01-00-01-28-D2-51-EA-DC-41-A9-A9-2C-5C
   **Serveurs DNS. . .  . . . . . . . . . . : 10.1.12.1
                                       10.1.12.2**
   NetBIOS sur Tcpip. . . . . . . . . . . : Activé

But if I connect using the OpenVNC Connect client, I get the following :

Suffixe DNS propre à la connexion. . . :
   Description. . . . . . . . . . . . . . : TAP-Windows Adapter V9 for OpenVPN Connect
   Adresse physique . . . . . . . . . . . : 00-FF-6E-21-63-DD
   DHCP activé. . . . . . . . . . . . . . : Non
   Configuration automatique activée. . . : Oui
   Adresse IPv6 de liaison locale. . . . .: fe80::f0bf:724b:c32e:36a1%65(préféré)
   Adresse IPv4. . . . . . . . . . . . . .: 192.168.113.5(préféré)
   Masque de sous-réseau. . . . . . . . . : 255.255.255.0
   Passerelle par défaut. . . . . . . . . : 
   IAID DHCPv6 . . . . . . . . . . . : 1090584430
   DUID de client DHCPv6. . . . . . . . : 00-01-00-01-28-D2-51-EA-DC-41-A9-A9-2C-5C
   **Serveurs DNS. . .  . . . . . . . . . . : fec0:0:0:ffff::1%1
                                       fec0:0:0:ffff::2%1
                                       fec0:0:0:ffff::3%1**
   NetBIOS sur Tcpip. . . . . . . . . . . : Activé

Any idea what can cause this?

I can still access the domain devices using the IP address only, but it is kind of annoying.

If I do a nslookup while connected on the OpenVPN connection, it obviously won't resolve :

> C:\Users\user>nslookup wowfs.wow.local
> Serveur :   unifi.localdomain
> Address:  192.168.1.1
> 
> *** unifi.localdomain ne parvient pas à trouver wowfs.wow.local : Non-existent domain

If I specify the DNS server, it works fine :

> C:\Users\user>nslookup wowfs.wow.local 10.1.12.1
> Serveur :   wowdc01.wow.local
> Address:  10.1.12.1
> 
> Nom :    wowfs.wow.local
> Address:  10.1.12.3

I also see the following in the logs :

netsh interface ip set address 65 static 192.168.113.5 255.255.255.0 gateway=192.168.113.1 store=active

If I run that command in an elevated cmd prompt, it will effectively add the missing gateway to my configuration. Could it be a permission thing? I tried running the OpenVPN Client Connect as admin before I connected but same results.

If anybody has any idea, let me know.

Thanks

Alex

Mohammad Montazeri

Your explicit-server lookup succeeds, so there is already a useful comparison to preserve. Does the same internal FQDN also fail in the application you need, or have you tested only with nslookup so far?

Could you compare one clean connection in each client and share the redacted log section containing the received DNS/domain options and the subsequent DNS/interface-configuration messages, including any command exit status or error? Also record the Windows build and the active DNS-server and route state before and after connecting. Please omit credentials, certificates, keys and identifying hostnames. The important distinction is whether Connect receives the setting but fails to apply it, or whether the application is using a different resolver path. Adding the same option a second time makes that comparison harder. I would collect that evidence before treating the missing gateway field as the cause or changing server routing.

AI-assisted reply; I work on a VPN service.

JosephS

First of all I would check the client logs to make sure that the options are listed correctly.
In the "capture options" section you should see:

DNS Servers: 
Priority: 0 
Adresses:
10.1.12.1
10.1.12.2
DNS Search Domains:
wow.local

If that matches then it would be good to know if the DNS settings you pushed actually applied onto the your machines Windows NRPT.

Check if the DNS settings are present in the following registry via regedit:

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\DnsPolicyConfig

With Regards,
Joseph