Internet is broken on Windows with VPN

I’ve made a home physical server at the ubuntu 20.04 desktop.
The physical server is connected with wi-fi router. I provided my server with the static ip by means of DHCP.
My Internet-provider also provides me with static ip.
On the physical server I deployed a simple web-app and installed pritunl version 1.30.3354.99.
In pritunl I made the openvpn server and customized the route to my subnet, where the web-app is deployed.
My server config:

ignore-unknown-option ncp-ciphers
port 9026
proto tcp6-server
dev tun1
management /var/run/pritunl_63de8f8464f4e53a10a077c3.sock unix
topology subnet
tls-version-min 1.2
max-clients 2000
ping 10
ping-restart 80
cipher AES-256-CBC
ncp-ciphers AES-256-GCM:AES-256-CBC
auth SHA256
status-version 2
script-security 2
sndbuf 393216
rcvbuf 393216
reneg-sec 2592000
hash-size 1024 1024
txqueuelen 1000
verb 4
mute 8
comp-lzo no
push "comp-lzo no"
push "route"

When I connect to openvpn server from OS Windows I have problems with DNS name resolved.
But ping ip (google) operates successfully. It is also exellent in pinging and it loads my web-app.


Pinging with 32 bytes of data:
Reply from bytes=32 time=39ms TTL=110
Reply from bytes=32 time=40ms TTL=110
Reply from bytes=32 time=42ms TTL=110
Reply from bytes=32 time=56ms TTL=110

Ping statistics for
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 39ms, Maximum = 56ms, Average = 44ms

Ping request could not find host Please check the name and try again.


Pinging with 32 bytes of data:
Reply from bytes=32 time=3ms TTL=64
Reply from bytes=32 time=3ms TTL=64
Reply from bytes=32 time=11ms TTL=64
Reply from bytes=32 time=5ms TTL=64

Ping statistics for
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 3ms, Maximum = 11ms, Average = 5ms

My windows client config:

setenv UV_ID e7127548b0b64a52a6d7036dcd099c2a
setenv UV_NAME ancient-skies-2316
dev tun
dev-type tun
remote 9026 tcp-client
cipher AES-256-CBC
auth SHA256
verb 2
mute 3
ping 10
ping-restart 60
hand-window 70
server-poll-timeout 4
reneg-sec 2592000
sndbuf 393216
rcvbuf 393216
remote-cert-tls server
comp-lzo no
key-direction 1

If I change the route for all net, the problem disappears.
Unfortunately, OpenVPN begins to pass thought itself all traffic, but I need it to be only my subnet with the web-app.
Settings of DNS physical server:

sudo cat /etc/resolv.conf 
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.


Log Pritunl: (enable client VPN Windows)

[restless-plains-3431] 2023-02-04 20:26:47 us=198576 MULTI: multi_create_instance called
[restless-plains-3431] 2023-02-04 20:26:47 us=198642 Re-using SSL/TLS context
[restless-plains-3431] 2023-02-04 20:26:47 us=198753 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
[restless-plains-3431] 2023-02-04 20:26:47 us=198771 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
[restless-plains-3431] 2023-02-04 20:26:47 us=198850 Control Channel MTU parms [ L:1624 D:1170 EF:80 EB:0 ET:0 EL:3 ]
[restless-plains-3431] 2023-02-04 20:26:47 us=198874 Data Channel MTU parms [ L:1624 D:1450 EF:124 EB:406 ET:0 EL:3 ]
[restless-plains-3431] 2023-02-04 20:26:47 us=198921 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1572,tun-mtu 1500,proto TCPv4_SERVER,comp-lzo,keydir 0,cipher AES-256-CBC,auth SHA256,keysize 256,tls-auth,key-method 2,tls-server'
[restless-plains-3431] 2023-02-04 20:26:47 us=198934 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1572,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,keydir 1,cipher AES-256-CBC,auth SHA256,keysize 256,tls-auth,key-method 2,tls-client'
[restless-plains-3431] 2023-02-04 20:26:47 us=198977 TCP connection established with [AF_INET6]::ffff:
[restless-plains-3431] 2023-02-04 20:26:47 us=198992 TCPv6_SERVER link local: (not bound)
[restless-plains-3431] 2023-02-04 20:26:47 us=199005 TCPv6_SERVER link remote: [AF_INET6]::ffff:
[restless-plains-3431] 2023-02-04 20:26:47 us=199112 TLS: Initial packet from [AF_INET6]::ffff:, sid=315e8f01 56113d8a
[restless-plains-3431] 2023-02-04 20:26:47 us=269677 VERIFY OK: depth=1, O=63d6a660871fd84ef80dafcb, CN=63d6a660871fd84ef80dafd0
[restless-plains-3431] 2023-02-04 20:26:47 us=270124 VERIFY OK: depth=0, O=63d6a660871fd84ef80dafcb, CN=63d6a660871fd84ef80dafe4
[restless-plains-3431] 2023-02-04 20:26:47 us=270709 peer info: IV_VER=3.git::d3f8b18b
[restless-plains-3431] 2023-02-04 20:26:47 us=270730 peer info: IV_PLAT=win
[restless-plains-3431] 2023-02-04 20:26:47 Client conf 63d6a660871fd84ef80dafe4:
[restless-plains-3431] 2023-02-04 20:26:47 us=270760 peer info: IV_NCP=2
[restless-plains-3431] 2023-02-04 20:26:47   push "ping 10"
[restless-plains-3431] 2023-02-04 20:26:47 us=270773 peer info: IV_TCPNL=1
[restless-plains-3431] 2023-02-04 20:26:47   push "ping-restart 60"
[restless-plains-3431] 2023-02-04 20:26:47 us=270783 peer info: IV_PROTO=30
[restless-plains-3431] 2023-02-04 20:26:47   push "dhcp-option DNS"
[restless-plains-3431] 2023-02-04 20:26:47 us=270795 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305:AES-256-CBC
[restless-plains-3431] 2023-02-04 20:26:47   ifconfig-push
[restless-plains-3431] 2023-02-04 20:26:47 us=270806 peer info: IV_LZO_STUB=1
[restless-plains-3431] 2023-02-04 20:26:47 us=270816 peer info: IV_COMP_STUB=1
[restless-plains-3431] 2023-02-04 20:26:47 COM> SUCCESS: client-auth command succeeded
[restless-plains-3431] 2023-02-04 20:26:47 us=270827 peer info: IV_COMP_STUBv2=1
[restless-plains-3431] 2023-02-04 20:26:47 us=270837 peer info: IV_AUTO_SESS=1
[restless-plains-3431] 2023-02-04 20:26:47 us=270848 peer info: UV_ID=e7127548b0b64a52a6d7036dcd099c2a
[restless-plains-3431] 2023-02-04 20:26:47 us=270858 peer info: UV_NAME=ancient-skies-2316
[restless-plains-3431] 2023-02-04 20:26:47 us=270869 peer info: UV_ASCLI_VER=3.3.4-2600
[restless-plains-3431] 2023-02-04 20:26:47 us=270879 peer info: IV_GUI_VER=OCWindows_3.3.4-2600
[restless-plains-3431] 2023-02-04 20:26:47 us=270890 peer info: IV_SSO=webauth,openurl,crtext
[restless-plains-3431] 2023-02-04 20:26:47 us=270901 peer info: IV_HWADDR=1c:bf:ce:4b:2e:c8
[restless-plains-3431] 2023-02-04 20:26:47 us=270911 peer info: IV_SSL=OpenSSL_1.1.1l__24_Aug_2021
[restless-plains-3431] 2023-02-04 20:26:47 us=271032 TLS: Username/Password authentication deferred for username '' 
[restless-plains-3431] 2023-02-04 20:26:47 us=289488 MANAGEMENT: CMD 'client-auth 2 0'
[restless-plains-3431] 2023-02-04 20:26:47 us=352579 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 4096 bit RSA
[restless-plains-3431] 2023-02-04 20:26:47 User connected user_id=63d6a660871fd84ef80dafe4
[restless-plains-3431] 2023-02-04 20:26:47 us=352640 [63d6a660871fd84ef80dafe4] Peer Connection Initiated with [AF_INET6]::ffff:
[restless-plains-3431] 2023-02-04 20:26:47 us=352680 63d6a660871fd84ef80dafe4/ MULTI_sva: pool returned IPv4=, IPv6=(Not enabled)
[restless-plains-3431] 2023-02-04 20:26:47 us=352786 63d6a660871fd84ef80dafe4/ MULTI: Learn: -> 63d6a660871fd84ef80dafe4/
[restless-plains-3431] 2023-02-04 20:26:47 us=352808 63d6a660871fd84ef80dafe4/ MULTI: primary virtual IP for 63d6a660871fd84ef80dafe4/
[restless-plains-3431] 2023-02-04 20:26:47 us=352826 63d6a660871fd84ef80dafe4/ Data Channel: using negotiated cipher 'AES-256-GCM'
[restless-plains-3431] 2023-02-04 20:26:47 us=352851 63d6a660871fd84ef80dafe4/ Data Channel MTU parms [ L:1552 D:1450 EF:52 EB:406 ET:0 EL:3 ]
[restless-plains-3431] 2023-02-04 20:26:47 us=352964 63d6a660871fd84ef80dafe4/ Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
[restless-plains-3431] 2023-02-04 20:26:47 us=352980 63d6a660871fd84ef80dafe4/ Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
[restless-plains-3431] 2023-02-04 20:26:47 us=353029 63d6a660871fd84ef80dafe4/ SENT CONTROL [63d6a660871fd84ef80dafe4]: 'PUSH_REPLY,comp-lzo no,route,route-gateway,topology subnet,ping 10,ping-restart 60,dhcp-option DNS,ifconfig,peer-id 0,cipher AES-256-GCM' (status=1)
[restless-plains-3431] 2023-02-04 20:26:47 us=353174 63d6a660871fd84ef80dafe4/ PUSH: Received control message: 'PUSH_REQUEST'
[restless-plains-3431] 2023-02-04 20:26:47 us=630160 63d6a660871fd84ef80dafe4/ MULTI: bad source address from client [::], packet dropped

layout of components:

port of openvpn server is opened by the command:
ufw allow 9026
Firewall in OS Windows is off.
What can be the reason of such operations, problems?

The VPN connection is likely disrupting access to the DNS server configured on the client, possibly from the route pushed. The client will need to be configured to use a different DNS.

1 Like

Thanks a lot for your answer!
It happens to every client on OS Windows. Shall I customise every client separately?
It sounds like a strange way to solve my problem.

DNS can be pushed from the server with push "dhcp-option DNS"

How can I make it in interface pritunl? I’ve been looking for it for a very long time but I didn’t find

The DNS server is configured in the server settings.

1 Like

I’ve tried everything pictured on the screenshot:

The option push “dhcp-option DNS” can’t be added to server configuration.
I watch server configuration this way (During started server):
ps -ef | grep openvpn
cat /tmp/pritunl_xxx/openvpn.conf

It is configured to send the DNS server. This is sent on connection to the client, it wouldn’t be shown in the server configuration.

This is some other issue. There may be a static DNS server configured on the Windows device that would take priority over the DNS server from the VPN connection. You could also try adding to the server routes.

1 Like

The point is, I can connect to other VPN servers and DNS works correctly.

You could also try adding to the server routes.

Does it indicate that major part of traffic will pass through OpenVPN?

No that would route DNS traffic.

1 Like

Your idea works great. Thanks a lot!