nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Child Item

VPN worked great until a week ago.

Frustrated CM

I had zero problems with connecting using "Automatic". EVERY single website worked. Lately the VPN is blocking even common sites. I changed nothing. I read a suggestion to add the offending site to the exception list in split tunneling. No go. If I have to add a dozen websites every day then why use this product? I'll just cancel my subscription and use a competitor. What did Bitdefender change in the last couple of weeks? This is beyond ridiculous. I literally was just on the ESPN page and clicked a link to look at the newest AP college football poll. No………that site is way too dangerous. I get this lovely message (which is becoming a common theme with this product):

Secure Connection Failed

The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.

What can you do about it?

The issue is most likely with the website, and there is nothing you can do to resolve it. You can notify the website’s administrator about the problem.

Error Code: PR_CONNECT_RESET_ERROR

Yet if I turn off Bitdefender I can visit just fine. I refuse to add espn.com to some exception list. This product is becoming unusable. I have tried Firefox and Chrome browsers with the same tired result. I have cleared caches, etc, etc, etc. None of the changes to the Chrome or Firefox browser settings make a bit of difference. It's the VPN. Simple and easy. I turn it off and the websites work. It would be nice to have a functional VPN that doesn't block a ton of sites, especially when the are harmless. Can anyone share some settings to change within the VPN? That's the only thing that I can think that might help. If this doesn't clear up or improve I will cancel the VPN and the antivirus subscriptions as they near expiration. I don't mean my first post to be so negative but good grief folks. I use this product for six months and it was amazing. Then a couple of weeks ago it goes haywire. I hope someone will help or at least try to help.
Thank you for reading.

Find more posts tagged with

Comments

Frustrated CM

In my frustration I tried an experiment. The VPN was set to "Connect VPN at Windows Startup". I turned this off and rebooted. I manually turned the VPN on and then browsed to the same site. Now the ESPN article that was previously blocked suddenly loads with no issues. Could that setting have anything to do with this continual blockage of legitimate sites?

Alexandru_BD

Hello and thanks for joining us here.

Sorry to hear of this hassle.

Based on what you describe, obviously adding that many websites to Split Tunneling is not a solution. That feature can be useful when one particular website or service deliberately refuses VPN traffic, but if multiple unrelated and otherwise legitimate websites suddenly stop loading, I think it makes more sense to investigate the VPN connection itself.

The PR_CONNECT_RESET_ERROR message generally means that the connection was unexpectedly reset while the browser was communicating with the destination. Since this happens in both Firefox and Chrome, but disappears when the VPN is disconnected, the VPN tunnel, routing, protocol or DNS path would be the areas I would look at first.
Patience will be required in order to get to the bottom of this, as there can be several things causing it and you need to take it step by step and by elimination.

One of the most important tests here would be to change the VPN protocol instead of leaving it on Automatic.

Go to the VPN settings and locate Protocol, then try the available protocols individually. I would start with WireGuard, disconnect/reconnect the VPN and test the affected websites again. If the problem remains, try OpenVPN. On Windows, OpenVPN also allows TCP/UDP and port selection; OpenVPN TCP on port 443 can be particularly useful as a compatibility test because TCP/443 closely resembles ordinary HTTPS traffic and tends to work well on networks where other VPN traffic encounters interference.

The protocol matters because it determines how the encrypted tunnel is established and how traffic is transported through it. A connection can therefore behave very differently depending on whether Automatic selects WireGuard, OpenVPN or another available protocol.

I would also test DNS, because DNS-related problems can sometimes appear as websites failing only while a VPN is active. If you are currently using your ISP's DNS servers, you could temporarily test a well-known public DNS service such as Cloudflare (1.1.1.1 / 1.0.0.1) or Google (8.8.8.8 / 8.8.4.4) and see whether the behavior changes.

Now, since both Chrome and Firefox can also use their own Secure DNS/DNS-over-HTTPS configuration, it may be worth temporarily disabling that feature in the browsers while testing. This helps ensure that DNS requests are not taking a different path from the one expected by the VPN.

A few other useful tests would be:

manually select a different VPN server/location
temporarily disable the VPN Kill Switch, if enabled, just for testing
test the same VPN connection on another network, such as a mobile hotspot
reset the VPN settings and reconnect
after changing a protocol, always disconnect and reconnect the VPN before testing again

I think your observation about connecting VPN at windows startup could also be relevant. If the VPN starts while windows is still initializing the network adapter, DNS and other networking components, the initial tunnel may not be established in exactly the same circumstances as when you connect manually after windows has fully loaded. The fact that the same ESPN page worked immediately after rebooting and manually establishing the VPN connection is therefore worth investigating rather than dismissing as coincidence.

For now, I would actually leave the option to connect VPN at windows startup disabled and test for a while using a manually selected protocol, preferably WireGuard first. If the issue comes back, try OpenVPN TCP/443 and note whether there is any difference.

If numerous unrelated websites continue producing connection resets regardless of protocol, DNS, server location and network, then this would deserve further investigation by Bitdefender Support because that would indicate something broader than individual websites rejecting VPN connections.

And I completely agree with your point regarding Split Tunneling. Having to exclude a growing list of normal websites would defeat much of the purpose of using the VPN in the first place. Ideally, we should identify what changed in the connection path rather than work around each affected site individually…

I hope this helps, let me know how it goes.