OpenVPN Support Forum

windows10 installed openvpn-connect-3.4.2.3160.The vpn server send a dns address.Then network address cannot be resolved.
The openvpn-install-2.4.4-I601 is normal. I think there might be a bug.


[olog]
[Sep 6, 2023, 12:40:02] Connected via TUN_WIN
⏎[Sep 6, 2023, 12:40:02] LZO-ASYM init swap=0 asym=1
⏎[Sep 6, 2023, 12:40:02] Comp-stub init swap=0
⏎[Sep 6, 2023, 12:40:02] EVENT: CONNECTED cm.dedpp.com:41775 (160.123.153.171) via /UDP on TUN_WIN/192.168.200.10/ gw=[192.168.200.1/] mtu=(default)⏎[Sep 6, 2023, 13:14:44] OpenVPN core 3.8.2connect1 win x86_64 64-bit OVPN-DCO built on Aug 21 2023 16:29:24
⏎[Sep 6, 2023, 13:14:44] Frame=512/2112/512 mssfix-ctrl=1250
⏎[Sep 6, 2023, 13:14:44] NOTE: This configuration contains options that were not used:
⏎[Sep 6, 2023, 13:14:44] Unsupported option (ignored)
⏎[Sep 6, 2023, 13:14:44] 7 [persist-tun]
⏎[Sep 6, 2023, 13:14:44] 11 [mute] [3]
⏎[Sep 6, 2023, 13:14:44] EVENT: RESOLVE ⏎[Sep 6, 2023, 13:14:44] Contacting 160.123.153.171:41775 via UDP
⏎[Sep 6, 2023, 13:14:44] EVENT: WAIT ⏎[Sep 6, 2023, 13:14:44] WinCommandAgent: transmitting bypass route to 160.123.153.171
{
"host" : "160.123.153.171",
"ipv6" : false
}

⏎[Sep 6, 2023, 13:14:44] Connecting to [cm.dedpp.com]:41775 (160.123.153.171) via UDP
⏎[Sep 6, 2023, 13:14:44] EVENT: CONNECTING ⏎[Sep 6, 2023, 13:14:44] Tunnel Options:V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 1,cipher AES-128-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-client
⏎[Sep 6, 2023, 13:14:44] Creds: UsernameEmpty/PasswordEmpty
⏎[Sep 6, 2023, 13:14:44] Peer Info:
IV_VER=3.8.2connect1
IV_PLAT=win
IV_NCP=2
IV_TCPNL=1
IV_PROTO=990
IV_MTU=1600
IV_CIPHERS=AES-128-CBC:AES-192-CBC:AES-256-CBC:AES-128-GCM:AES-192-GCM:AES-256-GCM:CHACHA20-POLY1305
IV_LZO=1
IV_LZO_SWAP=1
IV_LZ4=1
IV_LZ4v2=1
IV_COMP_STUB=1
IV_COMP_STUBv2=1
IV_AUTO_SESS=1
UV_ID=c78d1928c07e4332bde36d0cfbea787e
UV_UUID=EDC251DF-BE95-11EB-80F0-38F3ABEE7C80
UV_NAME=evening-fields-8445
UV_ASCLI_VER=3.4.2-3160
IV_GUI_VER=OCWindows_3.4.2-3160
IV_SSO=webauth,openurl,crtext
IV_HWADDR=4c:79:6e:49:81:da
IV_SSL=OpenSSL 3.0.8 7 Feb 2023

⏎[Sep 6, 2023, 13:14:44] SSL Handshake: peer certificate: CN=64b537ad67e595e42f54dcf5, 4096 bit RSA, cipher: TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD

⏎[Sep 6, 2023, 13:14:44] Session is ACTIVE
⏎[Sep 6, 2023, 13:14:44] EVENT: GET_CONFIG ⏎[Sep 6, 2023, 13:14:44] Sending PUSH_REQUEST to server...
⏎[Sep 6, 2023, 13:14:44] OPTIONS:
0 [comp-lzo] [no]
1 [route-gateway] [192.168.200.1]
2 [topology] [subnet]
3 [ping] [10]
4 [ping-restart] [60]
5 [dhcp-option] [DNS] [8.8.8.8]
6 [ifconfig] [192.168.200.10] [255.255.255.0]
7 [peer-id] [4]
8 [cipher] [AES-128-GCM]

⏎[Sep 6, 2023, 13:14:44] PROTOCOL OPTIONS:
cipher: AES-128-GCM
digest: NONE
key-derivation: OpenVPN PRF
compress: LZO_STUB
peer ID: 4
control channel: tls-auth enabled
⏎[Sep 6, 2023, 13:14:44] EVENT: ASSIGN_IP ⏎[Sep 6, 2023, 13:14:44] CAPTURED OPTIONS:
Session Name: cm.dedpp.com
Layer: OSI_LAYER_3
Remote Address: 160.123.153.171
Tunnel Addresses:
192.168.200.10/24 -> 192.168.200.1
Reroute Gateway: IPv4=0 IPv6=0 flags=[ IPv4 ]
Block IPv4: no
Block IPv6: no
Add Routes:
Exclude Routes:
DNS Servers:
8.8.8.8
Search Domains:

⏎[Sep 6, 2023, 13:14:45] SetupClient: transmitting tun setup list to \\.\pipe\agent_ovpnconnect
{
"allow_local_dns_resolvers" : false,
"confirm_event" : "1c0f000000000000",
"destroy_event" : "780f000000000000",
"tun" :
{
"adapter_domain_suffix" : "",
"block_ipv6" : false,
"dns_servers" :
[
{
"address" : "8.8.8.8",
"ipv6" : false
}
],
"layer" : 3,
"mtu" : 0,
"remote_address" :
{
"address" : "160.123.153.171",
"ipv6" : false
},
"reroute_gw" :
{
"flags" : 256,
"ipv4" : false,
"ipv6" : false
},
"route_metric_default" : -1,
"session_name" : "cm.dedpp.com",
"tunnel_address_index_ipv4" : 0,
"tunnel_address_index_ipv6" : -1,
"tunnel_addresses" :
[
{
"address" : "192.168.200.10",
"gateway" : "192.168.200.1",
"ipv6" : false,
"metric" : -1,
"net30" : false,
"prefix_length" : 24
}
]
},
"tun_type" : 0
}
POST np://[\\.\pipe\agent_ovpnconnect]/tun-setup : 200 OK
TAP ADAPTERS:
guid='{F1008B7E-5373-416C-B503-5756AE2E8B9E}' index=28 name='本地连接'
Open TAP device "本地连接" PATH="\\.\Global\{F1008B7E-5373-416C-B503-5756AE2E8B9E}.tap" SUCCEEDED
TAP-Windows Driver Version 9.26
ActionDeleteAllRoutesOnInterface iface_index=28
netsh interface ip set interface 28 metric=1
确定。
netsh interface ip set address 28 static 192.168.200.10 255.255.255.0 gateway=192.168.200.1 store=active
netsh interface ip set dnsservers 28 static 8.8.8.8 register=primary validate=no
NRPT::ActionCreate names=[.] dns_servers=[8.8.8.8]
ActionWFP openvpn_app_path=C:\Program Files\OpenVPN Connect\OpenVPNConnect.exe tap_index=28 enable=1
permit IPv4 DNS requests from OpenVPN app
permit IPv6 DNS requests from OpenVPN app
block IPv4 DNS requests from other apps
block IPv6 DNS requests from other apps
allow IPv4 traffic from TAP
allow IPv6 traffic from TAP
ipconfig /flushdns
Windows IP 配置
已成功刷新 DNS 解析缓存。
TAP: ARP flush succeeded
TAP handle: 980f000000000000
⏎[Sep 6, 2023, 13:14:45] Connected via TUN_WIN
⏎[Sep 6, 2023, 13:14:45] LZO-ASYM init swap=0 asym=1
⏎[Sep 6, 2023, 13:14:45] Comp-stub init swap=0
⏎[Sep 6, 2023, 13:14:45] EVENT: CONNECTED cm.dedpp.com:41775 (160.123.153.171) via /UDP on TUN_WIN/192.168.200.10/ gw=[192.168.200.1/] mtu=(default)⏎

[/olog]

The problem has not been solved. I have been modified：
setting>advanced settings>Allow use local dns reselovers

You can work around this by adding explicit route statements for each DNS server, but there is clearly a bug in OpenVPN Connect:

EITHER (and I think this is the case) the bug is in OpenVPN Connect for Windows, which doesn't allow connections to a DNS server it knows about, OR the OpenVPN Connect clients for iOS/Android/macOS/ChromeOS have a bug in that they ignore allow_local_dns_resolvers=false, because all other platforms work fine except Windows.

Hello,

From what I can see a DNS server 8.8.8.8 is being pushed. The assumption is made that when you push a DNS server through VPN, that DNS requests are sent and are reachable through the VPN tunnel. But the logs look like it is set up as split-tunnel and no routes are being added. The DNS server you are pushing to go through the VPN server, is not reachable through the VPN tunnel. So it seems to me that the simple solution is to have the VPN server push a route for the DNS server, or do full-tunnel redirection.

If you're using OpenVPN to change DNS resolution on the client, without actually using OpenVPN to transport this DNS traffic, you might want to consider simply changing the DNS server in the client computer's network configuration.

Edit: if I've misunderstood the use-case, please explain it more clearly?

Kind regards,
Johan

We had similar problems when we updated the client to version 3.4.x, even version 3.3.7 worked without problems. We used SoftEther VPN 4.42 Build 9798 RTM as a server, and we identified that the client only resolved names from the domain that was registered in the SecureNAT DHCP settings through the internal DNS, we resolved the problem by leaving the domain name field blank in the SecureNat DHCP settings in the server. After that, the client returned to resolving all domains using the internal DNS.

Best Regards,

Fernando Sanz