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!

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.

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

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.

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.

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.

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.

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.

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

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?

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

Windows11 connects but will not pass traffic

cheffcook

Hi again.
After post above my friend who belong VPN server told me what he not set up server to working with IPv6. And we together tried to test it and switched off IPv6 on my PC.
When IPv6 on

C:\WINDOWS\system32>tracert google.com
Tracing route to google.com [2a00:1450:4010:c06::71]
over a maximum of 30 hops:
  1    <1 мс    <1 мс    <1 мс  2a00:1370:8188:c5b:72f8:2bff:fe3c:ad40
  2     6 ms     6 ms     6 ms  2a00:1370:8088::
  3    15 ms     9 ms     9 ms  a197-cr04-as25513.msk.mts-internet.net [2a02:28:1:2::42:2]
  4     *        *        *     Request timed out.
  5     *        *        *     Request timed out.
  6     6 ms     *        *     mag9-cr02-be10.77.msk.mts-internet.net [2a02:28:1::12b:1]
  7     *        *        *     Request timed out.
  8     7 ms     7 ms     *     mag9-cr02-be13.77.msk.mts-internet.net [2a02:28:1::19b:1]
  9     *        *        7 ms  a197-cr01-ae10.77.msk.mts-internet.net [2a02:28:1::12b:2]
 10     9 ms     6 ms     9 ms  a197-cr04-be31.77.msk.mts-internet.net [2a02:28:1::1b7:2]
 11     7 ms    10 ms     7 ms  a197-cr03-ae0.16.msk.mts-internet.net [2a02:28:1::e3:62]
 12     7 ms     6 ms     6 ms  2a02:28:1::e3:102
 13     9 ms     6 ms     7 ms  a197-cr04-be18.10.msk.mts-internet.net [2a02:28:1::e3:72]
 14     8 ms     *        7 ms  2a02.0028.000100000000000001b70001.bbn.ip6.mtsws.net [2a02:28:1::1b7:1]
 15     8 ms     7 ms     7 ms  mag9-cr02-be10.77.msk.mts-internet.net [2a02:28:1::12b:1]
 16     *        *        *     Request timed out.
 17    23 ms    21 ms    21 ms  2001:4860::cc:4001:16c7
 18    22 ms    23 ms    20 ms  2001:4860:0:1::38f3
 19     *        *        *     Request timed out.
 20     *        *        *     Request timed out.
 21     *        *        *     Request timed out.
 22     *        *        *     Request timed out.
 23     *        *        *     Request timed out.
 24     *        *        *     Request timed out.
 25     *        *        *     Request timed out.
 26     *        *        *     Request timed out.
 27     *        *        *     Request timed out.
 28    20 ms    20 ms    20 ms  lj-in-x71.1e100.net [2a00:1450:4010:c06::71]

And after IPv6 off

C:\WINDOWS\system32>tracert google.com
Tracing route to к google.com [64.233.163.139]
over a maximum of 30 hops:
  1    45 ms    41 ms    41 ms  192.168.63.1
  2    48 ms    44 ms    45 ms  gw.bacloud.info [85.206.160.1]
  3    42 ms    42 ms    41 ms  3-240-206-85.bacloud.info [85.206.240.3]
  4    41 ms    42 ms    42 ms  1-240-206-85.bacloud.info [85.206.240.1]
  5    42 ms    47 ms    43 ms  et002.RT.OMT.SQQ.LT.retn.net [87.245.242.233]
  6    52 ms    52 ms    52 ms  ae0-13.RT.LDC.WAW.PL.retn.net [87.245.233.56]
  7    53 ms    53 ms    58 ms  72.14.203.82
  8    52 ms    54 ms    54 ms  108.170.250.217
  9    67 ms    65 ms    65 ms  209.85.142.125
 10    65 ms    65 ms    65 ms  142.251.238.70
 11    67 ms    64 ms    65 ms  216.239.62.15
 12     *        *        *     Request timed out.
 13     *        *        *     Request timed out.
 14     *        *        *     Request timed out.
 15     *        *        *     Request timed out.
 16     *        *        *     Request timed out.
 17     *        *        *     Request timed out.
 18     *        *        *     Request timed out.
 19     *        *        *     Request timed out.
 20     *        *        *     Request timed out.
 21    85 ms    84 ms    85 ms  lj-in-f139.1e100.net [64.233.163.139]

All worked now. But the question remained: why did everything stop working the day before yesterday? Maybe some Windows update forced pass traffic via IPv6? I dont know. I'm very bad at networking.

AlexAT

+1 there
Experiencing similar symptoms on one of client machines with OpenVPN Connect (3.3.6 (2752)).
Symptom reasons are: connection to OpenVPN server is ok and Connect client shows IP address assigned, but there is no IP address on TAP interface, it stays 169.254.x.x. Tried reinstalling OpenVPN Connect, deleting driver and reinstalling, to no avail.

Don't exactly have the logs, but there is one strange thing I've noticed:
- netsh command that sets interface IP address takes several seconds to execute, with no errors -

(the command in question is netsh interface ip set address <ifnum> static <ip> <mask> gateway=<gw> store=active)

After netsh execution, IP address on TAP interface still remains autoconfiguration one (169.254.)

I have copied netsh command from logs and tried executing it again both under user and administrator privileges, to no avail. Same stuff - no error, no output, takes several seconds to execute, no effect on interface. Checking Windows event logs gave absolutely nothing.

I also noticed TAP driver in Connect is from 2019. Any chances it's missing something from newer TAP driver versions that makes it Windows 11 netsh-incompatible?

It seems Connect client does not allow to use IPAPI or DHCP for autoconfiguration either instead of netsh, changing ip-win32 setting has no effect.

pormiston

openvpn_inc wrote 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

Ok sorry slow response, but still happening will log a case.

Michiganbb

I just logged in and see this routing table question.
I will do as requested.

Please keep in mind that it does not simply "stop working"
It never works for the first 60 seconds exactly of the session.
After 60 seconds it begins to pass traffic.

I will tape snapshots if the routing table both before and after as you have asked.
Also can you or the other person update here if a case was submitted as indicated above?
And any progress? Thanks.

--------------------------------------------------------------------------------------------------------------------
Same problem remains one full year later, there have been no software updates to the V3 release version client in all this time.

I have since tried on many different systems computers and firewalls..
And with PFSense OpenVPN server 2.6.0 and 2.7 beta
Same problem.
Client connects but does not pass any traffic through VPN.
EXACTLY one minute (60 seconds) later it begins to pass traffic and works.

Frustrating enough that I have put everyone on the old V2 client that actually works properly.

NikolayK

Hi guys,
I also had a problem: after installing updates on February 2023, the openvpn client stopped working (the connection is established but the traffic does not pass).
Solution: disable virtual network adapter "OpenVPN Data Channel Offload" in windows device manager

sniperkitten

Michiganbb wrote
Frustrating enough that I have put everyone on the old V2 client that actually works properly.

Hi Michiganbb

Does it work for you with Windows 11 and the v2.7.1 OpenVPN connect client which is still available for download on this url?

https://openvpn.net/client-connect-vpn-for-windows/

Thanks

altitude

I've seen this problem on both Windows 10 (for years) and 11. On some computers it always works fine and on some others there is always a delay. With both OpenVPN Connect clients v2 and v3. Looks like it takes Windows 60 or 70 seconds to route the traffic correctly.

Try this: disable IPv6 on the TAP adapter (or even on all adapters)

Never seen this issue when using OpenVPN Community build

Michiganbb

It looks like a new Windows client was recently released as I just now saw a notification from the software itself.
This prompted me to uninstall the client and go get the latest and install it.
And I have never before seen a notification from the client like this that there is a new version available.
Installed the new client on a windows 11 machine and it connects to a distant PFSense 2.6.0 openvpn server and passes traffic right away.
It's my first test but it looks like this very long ongoing issue with Win11 might be fixed in this release.
I have been meaning to file a bug report on this versus just living with it or installing the older V2 client to get around it.
Sorry for being so lazy on my end.
I am looking around for release notes for the new 3.3.7 (2979)
Not found them yet.
No "about" or links within the software client itself.
Here's the link to release notes.
No fixes or anything are mentioned.
Only changes since Feb. 2022 are "Updated information exchange for OpenVPN Cloud users."

https://openvpn.net/vpn-server-resources/openvpn-connect-for-windows-change-log/

Michiganbb

I mispoke, it still does not work and has the problem.
And I don't know why I thought it might be fixed.
It seems that immediately after install it worked, giving me an impression it may have been fixed.

I have since tested on three different systems and locations.
Same exact problem persists.
I guess after two years I should actually gather details and file a bug report on this.

Sappin

Hello,
I'm new to this forum, but I want to try to add some light to this post.

In a nutshell. When I go to look at the traffic on the interfaces I can't see any inbound, only outbound, so, I do an experiment. I don't know why I have 4 VPN adapter connections on my windows.

OpenVPN Data Channel Offload (what is this...)
OpenVPN TAP-Windows6 (TAP-Windows V9 Adapter)
OpenVPN Wintun
VPN - VPN Client

So, I've disabled all networks except the main one, and tried to enable one by one. If I leave only the OpenVPN TAP-Windows6 network along with the main Ethernet the VPNs work normally again.

I hope this helps someone.

BryanS

I had the same problem on Win11, but not on Win10. It was not an antivirus issue, nor a firewall issue.

I resolved the issue by installing the x86 version of OpenVPN on Win11.
😃

oncoman

Yes, I've been battling with this for a couple of weeks now. The Win 11 client is definitely broken. It worked fine for a year on Win 10. I've tried everything suggested in this thread (not sure how he loaded the 32 bit client though?) and it still does not work.

To test further, I loaded my old Nord VPN and it functions perfectly so it is not my machine. I really like OpenVPN but this new client almost certainly has a Windows 11 "feature".

Any suggestions?

sniperkitten

Hi

Thank you for the suggestion. Will try the x86 version of the client, which is available on the Downloads page.
Going to test for a while and come back with the results.

Chfp145

I was also having this issue, worked great in win10, however win11 it would connect but would not pass traffic. Tried disabling IPv6 with no change (although I did not restart so perhaps that was not a good test)

Then I installed the x86 version on win11 and this time it passed traffic immediately.

Michiganbb

It's been a couple of years now and this problem still fully persists in the 64bit version.
Am I only one of like 5 people using this client software in Windows 11?
I should have filed a real bug report well over a year ago.
Guess I need to seriously pick this back up.

-SteveG

cameronduff

Hi,

I think I had this problem, found a fix was to disable dco.

In the openvpn config file, add the

disable-dco

setting.

My symptoms:

* Windows 11 as Client
* OpenVPN GUI Client (Not OpenVPN Connect)
* Connection to VPN Server Succeeds, no errors in logs on client or server
* Client is using most up to date Windows DCO drivers (0.9.3), can see its using DCO in control panel network adapters
* Route table appears correct
* No IP connectivity over the tunnel
* Reboot and waiting some time did not clear the problem for me

Once DCO was disabled I could see the TAP driver was being using in the control panel network adapters page, and connectivity worked perfectly as expected.

Fredyy

I currently experience the same issue on windows 11.
tried openvpn gui, and open vpn connect on both versions 32/64bit.

it always connects fine, but no traffic is tunneled over the vpn, can't access my home network anymore, some setup worked fine 6 months ago.

adding disable-dco to the config didn't help.

[deleted]

Hi all,
This seems to be going on for a long time now.

I thought I had the same issue (VPN tunnel working perfectly on win10 and not on win11 were it would only be able to connect but there would be no traffic).

Routes were set fine on both computers, disabled IPV6, disable other network interfaces, nothing would make it work (unable to ping devices on the other side)
Until I compared the OpenVPN 64bit client versions we have.

After installing the latest version on my win10 it also stopped working. So I installed the latest older version that works on both machines (2.5.9), and it works now.

I hope this will solve someones problems for now, but something must be different or buggy after the 2.5.9 version. Maybe extra parameters that needs to be set in the config?

[deleted]

@openvpn_inc

Are the client versions backward compatible with older OpenVPN servers?
Could that be the issue?

« Previous Page