@nogbadthebad amen brother that worked thank you. not the wife can work and stop giving me the side eye as to why the network is going up and down..lol

I was waiting for a "fix" of the pSense software, hoping this would fix it.
After installing the latest version of the software, which I installed on the Netgate device from scratch, I found that actually the culprit is not the Netgate/pfSense firmware, but the problem is related to pfBlockerNG.
After the installation of the new firmware, I re-loaded my latest configuration from backup, and everything seemed to be working when I checked, impatiently, when actually the software was still installing my (to be) installed packages, like pfBlockerNG.

All in all I found that pfBlockerNG needs to be de-activated when rebooting the device, and then activated after startup. Then everything works as it should.
Next step is trying to find out why pfBlockerNG is giving me this problem.

pfBlockerNG is blocking based on IP (geo-IP) and based on DNSBL (DNS black listing).
I definitely did not block my country (NL) and I just use (a lot) of very common DNSBL lists.

Any ideas/suggestions are welcome.

@sjgieson

Nevermind, I figured out routing all Internet at least. The solution is to make sure you default gateway is your Virtual Wan on your Default allow LAN to any rule. In my case it was called "DHCP_WAN", so now I can send all traffic out.

I tried this earlier but I had a custom config line in the client side of OpenVPN, that was told to do to force all traffic out the VPN. This custom config was tripping up my LAN rules/routes. So don't do that.

I appear to be back in business now.

@daddygo said in Degraded OpenVPN connectivity to NordVPN after upgrade 2.4.5 to 2.5.2:

Other people would be very happy with your results (6 / 14 ms and 7.5 / 15.4), so let it go, because everything is perfect.

BTW:
These differences depend mostly on the load on the network (I think of everything here), check between 3 and 5 at night or during peak hours.

+++edit:
do not insist on numbers so rigidly

Hi,

I think my last response got interpret in a way I did not intended it to.

My last email with the graphs/data, was not about showing how the numbers support my experience that 2.5.2 in my situation has degraded OpenVPN connectivity. But was in response to your email on September 24th. In that email you showed your graphs/data and stated that OpenVPN works just fine for you on 2.5.2. The intention of my last email with the graphs/data, was exactly to demonstrate that these graphs/data do not show what I am experiencing in OpenVPN degradation and therefore not helpful in investigating my issue with OpenVPN. Indeed when looking at the graphs/data for 2.4.5 and 2.5.2 and comparing them, there is little difference and one could think there is no issue. However, I still am having an issue with OpenVPN on 2.5.2.

That is why I ended my last response with 'So these graphs/data do not point me into a direction as where the cause could be. Or am I overlooking something?'.

So if you have other suggestions as in how to investigate, please share your thoughts on this.

Thank you so far!

@wisheh
I suspect, that your outbound NAT is in manual mode. So you might have to add a rule to the OpenVPN interface.

@sysgi1 Anyone? Is there any issue with OpenVPN in a multi-ip environment?
I think something is broken in the last version (I never had this problem prior to 21.05 upgrade)

Thank you

I'm going to make the assumption that HOME is an interface that you assigned to the VPN client. In pfSense, traffic applies to the interface where the traffic arrives. So in this case, on HOME you need to allow traffic from source 192.168.0.0/24, but instead you have source as LAN net. LAN net will never be the source for traffic arriving at that interface.

@bcruze
Guess not.
Showing version numbers is important to know, I agree, and is also important for hackers.

Most "payware" VPN services compile their own VPN version from the open source tree.

Bah, I hate posting and then saying Nevermind, but I already found some closure.

After multiple attempts on my Linux Desktop, I decided to just get the Certificate data straight out of terminal with the openssl command without the -noout.

Entering this text in the text box (the BEGIN CERTIFICATE / END CERTIFICATE contents) with absolutely no modification worked.

I compared the two entries side by side, and it looks like my Text Editor was still adding markup language. It's a silly thing, but if someone searches for this in the future, all I can say is keep trying to make sure your certificate data is getting imported with absolutely no modification from your text editor.

@audiobahn This is just an OpenVPN server on the NetGate with various devices connecting. I resolved my issue by redoing the OpenVPN server without the use of a TLS cert. Oddly enough, the DNS resolver suddenly stopped working and still has issues even after restarting the service. Haven't been able to reboot it yet. hmmmm... glad you got yours working

@mucip said in Site to Site and Server-Client VPN in same Pfsense?:

very helpfull drawing

Your more than welcome - yeah if more people would post up drawings right off the bat, stuff would go some much quicker in figuring out the issues..

I always like to have a drawing - even if just for reference on what trying to accomplish.. It helps to make sure everyone on the same page if you will ;)

@bob-dig said in unable to access surfshark via openvpn:

@vjer2021 First it is SHA512 not SHA-3 512.

low and behold, that solved. it. thank you Bob. You're a gentleman and a scholar. and curse my eyesight.

@fairy Examining how your computer connects to your VPN can help you determine why and where the connection is slowing down.