Windows11 connects but will not pass traffic

Michiganbb

Hi-
I'm First time poster/asker here.

Am using Openvpn Connect (version 3.3.6 *2752*)
On clean Windows 11 pro install which is fully up to date.
Along with PFSense OpenVPN server.

Server is remote and we are accessing a LAN behind it at the remote location.
Client is local(here) and is running on Windows 11 and is behind a PFSense NAT device here.

The client connects to the server without any issue but will not pass any traffic right after connecting consistently and repeatably.
If I reboot the Windows 11 computer it always seems to work just fine if I connect the vpn client to the vpn server right after rebooting.

It also seems to work fine after that until some time period passes or I reboot again.

I can recreate the problem by rebooting and not using the vpn client immediately after reboot.
If I reboot and then try to use the vpn client 1-2 hours after reboot the issue happens where it connects but cannot pass any traffic.
And the only way I can get it to work is to reboot the computer and connect immediately after rebooting.

Windows firewall is turned off on the computer, and there are no power save or sleep features turned on.
The PC does not go to sleep ever. nor does it log off or turn on a screen saver.

I do not have this problem in Windows 10 booted up on the same computer same IP same scenario.

I've made my network config as simple as possible, single ethernet and the TAP-Windows adaptor created by openvpn connect.

1. Is this a known issue? I'm looking around for anything like this.
2. Also looking for hints on troubleshooting this further.

I will keep looking and thanks!

Michiganbb

Disconnected and waited about an hour, reconnected and does not pass any traffic at all.
reconnected several times nogo.
Only way to get it to connect again is to reboot and connect after freshly rebooting.
I'll try a few other things restarting services, disabling/enabling interfaces etc. to see if I can narrow it down any further than an entire reboot.

Michiganbb

disabling and re-enabling the ethernet interface on the client PC does not make it work.
Enabling and disabling the Windows firewall does not make it work.
So far only rebooting it makes it work.

I cannot ping or reach any remote host on the server's network, nor can I reach the far end gateway on the IPSEC
tunnel that is created as a route entry by openVPN when it is not working.
I'm going to reboot and verify that the remote gateway that is setup in the route tables does not change while it is working and is reachable.

I suspect it will look the same while it is working after the reboot.

And the specific route that we are using is of course:

10.74.74.0 255.255.255.0 44.103.31.13 44.103.31.14 257

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 10.73.73.1 10.73.73.124 25
10.73.73.0 255.255.255.0 On-link 10.73.73.124 281
10.73.73.124 255.255.255.255 On-link 10.73.73.124 281
10.73.73.255 255.255.255.255 On-link 10.73.73.124 281
10.74.74.0 255.255.255.0 44.103.31.13 44.103.31.14 257
44.103.31.1 255.255.255.255 44.103.31.13 44.103.31.14 257
44.103.31.12 255.255.255.252 On-link 44.103.31.14 257
44.103.31.14 255.255.255.255 On-link 44.103.31.14 257
44.103.31.15 255.255.255.255 On-link 44.103.31.14 257
P.P.P.P 255.255.255.255 10.73.73.1 10.73.73.124 281
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
127.255.255.255 255.255.255.255 On-link 127.0.0.1 331
224.0.0.0 240.0.0.0 On-link 127.0.0.1 331
224.0.0.0 240.0.0.0 On-link 44.103.31.14 257
224.0.0.0 240.0.0.0 On-link 10.73.73.124 281
255.255.255.255 255.255.255.255 On-link 127.0.0.1 331
255.255.255.255 255.255.255.255 On-link 44.103.31.14 257
255.255.255.255 255.255.255.255 On-link 10.73.73.124 281
===========================================================================
Persistent Routes:
None

Michiganbb

Update:
With the tunnel connection up and waiting what seems to be about ten minutes, it eventually starts workign and passing traffic.

You have to wait *at least 5 minutes* before it starts working.

No change in routing table and .13 is also pingable.

I do not experience this long wait if I reboot the machine and connect.
It always works right away after a reboot of the client PC.

Casual remindter that the client always connects instantly witout issues.
It does not pass any traffic when it's not working.
There is no indication of any problems/issues serverside or client side.
And this problem does not happen with Windows 10. on the same computer in the same scenario.

Michiganbb

Nothing changes or is different in the route table when it is working vs. not working.
Route table has some extra entries (not sure if they are other clients) or ?
.13 is not pingable when it's working either, (shown as the gateway to 10.74.74.0/24)

My client is .14

.12 and .15 also show up in the route table when the client is actively connected.

10.74.74.1 is the far end openvpn server and is reachable when it is working.

10.74.74.0 255.255.255.0 44.103.31.13 44.103.31.14 257
44.103.31.1 255.255.255.255 44.103.31.13 44.103.31.14 257
44.103.31.12 255.255.255.252 On-link 44.103.31.14 257
44.103.31.14 255.255.255.255 On-link 44.103.31.14 257
44.103.31.15 255.255.255.255 On-link 44.103.31.14 257

Please do not get confused by the address space being used internally.
This is not a factor in the issue we are having 🙂
And is a bit beyond the scope of this discussion why it is being used.
I know some people will be curious about this and will not be able to resist asking or pointing it out.

Michiganbb

I also logged into the local pfsense firewall NAT providing device and cleared any lingering states to the remote openvpn server,
Just as an additional troubleshooting measure.
So that establishing a new connection was assured to create a set of fresh new states and assure me that the old lingering states were not somehow
being re-used, as PFSense does some nifty port randomizations on the source port coming from the internal host on and outbound connection by default.

This was not the issue either.
Getting the same result...
Have to wait 5-10 minutes with the client connection up before any traffic starts to pass from the PC here to the far end LAN host.

I'm just testing with a Ping test and an SSH session to a remote host when the connection is working.

Michiganbb

Did further analysis:
Determined for sure it was not a multi session issue or port randomization issue by configuring outbound static port for this type of traffic (UDP1194)
and watched at the far end server to be assured that there was no issue with outbound port changing in transit or in stale NAT states.
Friendly Reminder: this is not happening with Windows 10 and openvpn client.

Also confirmed that settings on server allow multiple sessions from same user/IP address without issue.

Update: the delay is NOT 5-10 minutes before it works. It is EXATCLY one minute ten seconds from time of connect until it starts working passing traffic.

This is REALLY looking like a bug or incompatibility in the VPNConnect software with Windows 11.
I have seen several other posts about this but NONE of them have any kind of response or followup to them so I started THIS thread.
And I actually DO follow up on my posts whether fixed or not.

So far this is not fixed on my own and it's looking possibly like bug report time if I don't hear anything back.

I've only been troubleshooting this for about an hour so far.
I'll see what kind of feedback this gets before concluding it's actually a bug or compatibility issue.

Michiganbb

Bump,
Not much help or interest here it looks like-
I'm going to go ahead and report this as a bug that is easily reproduceable.

Galimage

Hello,

Did you find a solution regarding this issue? I'm having the same kind of problem and I can't find a way to get this right.

Kind regards

Michiganbb

No I did not. and not even an acknowledgement of any kind here.
My customer's solution was to NOT use Windows 11.
It is many months later and I just tried this now on a fresh Windows 11 Install.
The problem is still present for me in Windows 11.
And since March 22 2022 There have not been any update released for OpenVPN connect. it is still the same version.

Did you find anything out?

openvpn_inc

Hello there,

I do see your posts here, but, at the same time, we have no other reports and Windows 11 tests okay on our end here. Now that doesn't mean there is not a bug, but it's also a problem, because in order to solve the problem, we need to be able to reproduce it here. So far it seems to just pass QA without seeing this issue.

Based on experiences in the past, it could be some particular configuration being used or a particular antivirus/firewall solution that can cause problems. Can you guys provide any information about what device is being used to connect to - are you both using PFsense's OpenVPN server? And is there an antivirus/firewall program that both of you are using? Did you try uninstalling that, did you try connecting to another OpenVPN server? Because we need to find out what the common thing is that you two are experiencing, so we have something to investigate.

The only thing I see here that's a bit out of the ordinary is the public IP being used for routing. Normally OpenVPN just uses the OpenVPN server's internal VPN IP as the gateway address, and it then takes care of routing it to the right place. Maybe this is also something you could consider doing.

So, sorry, I don't have an answer, but it seems a pretty isolated problem, and therefore hard to do anything with it. Maybe with more information we'll get somewhere.

Kind regards,
Johan

Michiganbb

Thanks for the reach back.
I will do some more testing.

In both cases the one at the beginning of the year and the one just now,
It's after a fresh Windows 11 install and brought fully up to date (both instances) the more recent one is of course "more up to date" compared the test toward the beginning of the year using the same release version of OPenVPN Connect.

The VPN client works/passes traffic after waiting one full minute after it shows successfully connected
Always and consistently one full minute after connecting almost right on the mark.

There is no software or 3rd party firewall software involved on the computer running the client.

In fact I can turn off the built in Windows 11 firewall Or turn it back on /reboot and the problem still persists in exactly the same way.
I do not have any such problem testing under Windows 10 same computer same set of externals.

PFsense firewall is in place at both locations client and server.
Relatively simple configurations regarding firewall and openvpn settings, using pretty much out of the box configurations and VPN server setups.

Same problem with different remote openvpn PFSense servers.

It always works/ is suddenly able to pass traffic through the tunnel one full minute after connecting.

If you'd like me to provide further specific information or perform any specific tests /packet captures or detailed logging once it is turned on during the one minute of not able to pass any traffic through the tunnel that shows that it is up and working on the client versus once it start passing traffic I can.

I can also try different computers and different Internet connections/providers/hardware border firewalls as well on my end.

I am only seeing this behavior in Windows 11, clean install/updated with no 3rd party software yet installed (or after it is).

All things being exactly the same except with a clean windows 10 install - the problem does not occur.

Thanks!
Steve

toggenation

I am seeing this 1m10s behaviour with Windows 11 and a pfsense OpenVPN server.

Could this be a pfsense thing?

I had another self installed and configured OpenVPN server with Windows 11 and I believe it came up immediately. This only started happening when I switched to pfSense.

Michiganbb wrote Update: the delay is NOT 5-10 minutes before it works. It is EXACTLY one minute ten seconds from time of connect until it starts working passing traffic.

openvpn_inc

Hello,

Not sure. Possibly. It might be good to see the client log and see when for example the push_reply stuff comes in. The client will repeatedly request the server for instructions. If the server is uncharacteristically slow it may take some time before it gives instructions, after which the client will then implement those instructions. These instructions are usually about routing traffic through. But without logs I am just speculating. Maybe if the logs show that such a push_reply comes very late, then yeah, this may be a server-side issue.

Kind regards,
Johan

pormiston

I have the same problem.

I will connect to the VPN and it will work then after some time it will stop sending traffic until I disconnect and then re-connect.

This started happening after a fresh re-install of Windows 11 22H2.

openvpn_inc

Hello pormiston, and others,

Can you give any information on what for example the routing table looks like when it is working correctly and when it has stopped working? There may be a clue in there. Something might be removing routes. To be honest we're just guessing at this point. Our tests work but we see people reporting issues but we are not getting any logs or data that indicates where the problem might be. If the logs contain any sensitive data submit a ticket on https://openvpn.net/support instead.

Kind regards,
Johan

vdrag

Greetings. I can also confirm the problem and wish to contribute my findings towards the solution.

I use openvpn connect client version 3.3.6 (2752). I am using a mikrotik router for openvpn server.

Initially i had no problems. The clients were getting IP from the 192.168.89.0/24 subnet. This was NATed through the servers IP. Everything was working OK.

I changed the clients' subnet to 192.168.156.0/22. Then the problems started. Traffic was not passing through VPN. I tried with and without NATing this subnet, the result was the same. Occasionally, after adding static routes to client config, routing would work, but not always. After restarting PC problem would return. I must also note that currently the mikrotik openvpn server does not support route pushing.

When switching back to the previous /24 subnet, everything is working ok.

The problem does not seem to exist in android devices with the use of openvpn connect client and same config.

I installed openvpn community 2.5.9 . With the use of this client, everything is working normally. Strangely enough, after the above installation, openvpn connect client started routing the traffic properly as well. Maybe some driver got updated/downgraded?

I am not able to reproduce the problem from this PC now. However i might be able to reproduce it from another PC, so if i can be of any help somehow, let me know!

sniperkitten

Hi

I face a similar issue to what Michiganbb experiences.
Using Open VPN connect 3.3.6 (2752) on Windows 11 Pro 22H2.

As Michiganbb described:

"The VPN client works/passes traffic after waiting one full minute after it shows successfully connected
Always and consistently one full minute after connecting almost right on the mark."

In my configuration only a part of the traffic related to the corporate network is redirected through the VPN.
I checked what route was used to reach the <destination IP> using

tracert <destination IP>

Right after the VPN connection for one minute the non-VPN gateway is still used.
After one minute the VPN gateway is finally used.

I checked the routing table using 'route print' and the required VPN routes were active. But for some reason it took one minute for Windows to actually use them.

Regards

vdrag

After running some more tests I can add the following observations:

The problem exists in windows 10 as well.

Does not seem to exist in other (non-windows) OS.

After modifying the clients' subnet from 192.168.156.0/22 το 192.168.156.0/24, everything seems to work normally. Consequently, for my case I conclude that the /22 subnet mask somehow messes up the windows routes.

When checking the corresponding route in the windows routing table, the /22 subnet's mask appeared to be 255.255.255.0 when it should be 255.255.252.0 .

I hope the above will help somehow. I may be able to provide more info and testing if needed.

cheffcook

Hi. I think I have the same or similar issue on Windows 10 Pro 22H2 19045.2486. OpenVpn connected to the server without any issue but look like it will not pass traffic via VPN.
I used remote VPN server which belongs to my friend. He gave me two key to use it from my Android mobile and from PC. From molibe all worked fine with OpenVPN Connect application. But it not worked from Windows PC with the same settings.
Last summer I installed OpenVPN Connect application fof Windows but this application not worked: it connected to server but not pass traffic via VPN. After several attempts to fix it with my friends I stopped trying and removed the application. But I found on site OpenVPN application here https://openvpn.net/community-downloads/ Surprisingly, but it started work and I used it till 13.01.2023. I dont know that happend but on that day Windows Update installed KB5022282 update. I don't know if this is related or not.
Now it not worked, connected but not pass traffic via VPN. I reinstalled and updated OpenVPN to v2.5.8 (OpenVPN GUI v11.31.0.0) but there was no effect.

Connection log:

Sun Jan 15 23:26:24 2023 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning.
Sun Jan 15 23:26:24 2023 OpenVPN 2.5.8 [git:none/0357ceb877687faa] Windows-MSVC [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Dec  2 2022
Sun Jan 15 23:26:24 2023 Windows version 10.0 (Windows 10 or greater) 64bit
Sun Jan 15 23:26:24 2023 library versions: OpenSSL 1.1.1s  1 Nov 2022, LZO 2.10
Sun Jan 15 23:26:24 2023 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Sun Jan 15 23:26:24 2023 Need hold release from management interface, waiting...
Sun Jan 15 23:26:24 2023 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Sun Jan 15 23:26:24 2023 MANAGEMENT: CMD 'state on'
Sun Jan 15 23:26:24 2023 MANAGEMENT: CMD 'log on all'
Sun Jan 15 23:26:24 2023 MANAGEMENT: CMD 'echo on all'
Sun Jan 15 23:26:24 2023 MANAGEMENT: CMD 'bytecount 5'
Sun Jan 15 23:26:24 2023 MANAGEMENT: CMD 'state'
Sun Jan 15 23:26:24 2023 MANAGEMENT: CMD 'hold off'
Sun Jan 15 23:26:24 2023 MANAGEMENT: CMD 'hold release'
Sun Jan 15 23:26:24 2023 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Sun Jan 15 23:26:24 2023 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Sun Jan 15 23:26:24 2023 TCP/UDP: Preserving recently used remote address: [AF_INET]213.252.245.204:1194
Sun Jan 15 23:26:24 2023 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun Jan 15 23:26:24 2023 UDP link local: (not bound)
Sun Jan 15 23:26:24 2023 UDP link remote: [AF_INET]213.252.245.204:1194
Sun Jan 15 23:26:24 2023 MANAGEMENT: >STATE:1673814384,WAIT,,,,,,
Sun Jan 15 23:26:24 2023 MANAGEMENT: >STATE:1673814384,AUTH,,,,,,
Sun Jan 15 23:26:24 2023 TLS: Initial packet from [AF_INET]213.252.245.204:1194, sid=88a2861a abc1162c
Sun Jan 15 23:26:24 2023 VERIFY OK: depth=1, CN=OpenVPN-CA-openvpn-gate.bacloud.locky.me
Sun Jan 15 23:26:24 2023 VERIFY KU OK
Sun Jan 15 23:26:24 2023 Validating certificate extended key usage
Sun Jan 15 23:26:24 2023 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Sun Jan 15 23:26:24 2023 VERIFY EKU OK
Sun Jan 15 23:26:24 2023 VERIFY OK: depth=0, CN=OpenVPN-Server-openvpn-gate.bacloud.locky.me
Sun Jan 15 23:26:24 2023 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bit RSA, signature: RSA-SHA256
Sun Jan 15 23:26:24 2023 [OpenVPN-Server-openvpn-gate.bacloud.locky.me] Peer Connection Initiated with [AF_INET]213.252.245.204:1194
Sun Jan 15 23:26:25 2023 MANAGEMENT: >STATE:1673814385,GET_CONFIG,,,,,,
Sun Jan 15 23:26:25 2023 SENT CONTROL [OpenVPN-Server-openvpn-gate.bacloud.locky.me]: 'PUSH_REQUEST' (status=1)
Sun Jan 15 23:26:25 2023 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 1.0.0.1,dhcp-option DNS 1.1.1.1,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,route 192.168.62.0 255.255.255.0,route 192.168.63.0 255.255.255.0,topology net30,ping 5,ping-restart 30,ifconfig 192.168.63.18 192.168.63.17,peer-id 1,cipher AES-256-GCM'
Sun Jan 15 23:26:25 2023 OPTIONS IMPORT: timers and/or timeouts modified
Sun Jan 15 23:26:25 2023 OPTIONS IMPORT: --ifconfig/up options modified
Sun Jan 15 23:26:25 2023 OPTIONS IMPORT: route options modified
Sun Jan 15 23:26:25 2023 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sun Jan 15 23:26:25 2023 OPTIONS IMPORT: peer-id set
Sun Jan 15 23:26:25 2023 OPTIONS IMPORT: adjusting link_mtu to 1624
Sun Jan 15 23:26:25 2023 OPTIONS IMPORT: data channel crypto options modified
Sun Jan 15 23:26:25 2023 Data Channel: using negotiated cipher 'AES-256-GCM'
Sun Jan 15 23:26:25 2023 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Sun Jan 15 23:26:25 2023 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Sun Jan 15 23:26:25 2023 interactive service msg_channel=584
Sun Jan 15 23:26:25 2023 open_tun
Sun Jan 15 23:26:25 2023 tap-windows6 device [OpenVPN TAP-Windows6] opened
Sun Jan 15 23:26:25 2023 TAP-Windows Driver Version 9.24 
Sun Jan 15 23:26:25 2023 Notified TAP-Windows driver to set a DHCP IP/netmask of 192.168.63.18/255.255.255.252 on interface {924AB633-B74D-44BA-B150-1808AF723228} [DHCP-serv: 192.168.63.17, lease-time: 31536000]
Sun Jan 15 23:26:26 2023 Successful ARP Flush on interface [11] {924AB633-B74D-44BA-B150-1808AF723228}
Sun Jan 15 23:26:26 2023 MANAGEMENT: >STATE:1673814386,ASSIGN_IP,,192.168.63.18,,,,
Sun Jan 15 23:26:26 2023 IPv4 MTU set to 1500 on interface 11 using service
Sun Jan 15 23:26:28 2023 TEST ROUTES: 3/3 succeeded len=2 ret=1 a=0 u/d=up
Sun Jan 15 23:26:28 2023 C:\WINDOWS\system32\route.exe ADD 213.252.245.204 MASK 255.255.255.255 192.168.1.254
Sun Jan 15 23:26:28 2023 Route addition via service succeeded
Sun Jan 15 23:26:28 2023 C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 192.168.63.17
Sun Jan 15 23:26:28 2023 Route addition via service succeeded
Sun Jan 15 23:26:28 2023 C:\WINDOWS\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 192.168.63.17
Sun Jan 15 23:26:28 2023 Route addition via service succeeded
Sun Jan 15 23:26:28 2023 MANAGEMENT: >STATE:1673814388,ADD_ROUTES,,,,,,
Sun Jan 15 23:26:28 2023 C:\WINDOWS\system32\route.exe ADD 192.168.62.0 MASK 255.255.255.0 192.168.63.17
Sun Jan 15 23:26:28 2023 Route addition via service succeeded
Sun Jan 15 23:26:28 2023 C:\WINDOWS\system32\route.exe ADD 192.168.63.0 MASK 255.255.255.0 192.168.63.17
Sun Jan 15 23:26:28 2023 Route addition via service succeeded
Sun Jan 15 23:26:28 2023 Initialization Sequence Completed
Sun Jan 15 23:26:28 2023 MANAGEMENT: >STATE:1673814388,CONNECTED,SUCCESS,192.168.63.18,213.252.245.204,1194,,

OpenVPN configuration file:

client

tls-client
auth SHA256
cipher AES-256-CBC
remote-cert-tls server
tls-version-min 1.2

proto udp
remote 213.252.245.204 1194
dev tun

resolv-retry 5
nobind
keepalive 5 30
persist-key
persist-tun
verb 3


route-method exe
route-delay 2

key-direction 1
<ca>
-----BEGIN CERTIFICATE-----
//cert here
-----END CERTIFICATE-----

</ca>

<tls-auth>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
//static key here
-----END OpenVPN Static key V1-----

</tls-auth>

<cert>
-----BEGIN CERTIFICATE-----
//cert here
-----END CERTIFICATE-----

</cert>

<key>
-----BEGIN PRIVATE KEY-----
//private key here
-----END PRIVATE KEY-----

</key>