Anyone?
This is still an issue, we are getting desperate!

The only solution right now seems to be a scheduled restart every night.
But to me that is like peeing your pants to stay warm, not solving the problem.

So are there really no one out there, that has any idea, how to solve this issue?

@viragomann I think I may have solved it. Initial tests are positive, but want to do further diagnostics to be sure. Wanted to post what I found now so I don't forget.

I compared the ARP cache tables between the gateway and the TrueNAS box. Both tables showed the correct respective IP addresses for everything. However, in the gateway ARP table the MAC address for the TrueNAS box was incorrect (the IP address was correct). As soon as I deleted the listing in the gateway for the TrueNAS box that had the incorrect MAC address, I was able to ping both directions between the gateway and the TrueNAS box.

Thanks for your guidance. I figured it had to be something like this, it was just unfamiliar territory for me.

Jeff

Disabling VPN server and it's interface (I have both VPN client and server on PF) solves this issue, is it not supposed to work both of them one time or just something wrong with outbound NAT?

@gertjan
Thanks for the reply. Yes, I searched the OpenVPN forums prior to posting but was unable to find a solution that has resolved the issue. I have also confirmed the time settings on both ends are correct according to the system time and log timestamps.

@cmrt said in pfSense as OpenVPN Client - cannot reach remote network from local network:

10.4.0.0/24

I cannot thank you enough for this post, THANK YOU. I have spent days on trying OpenVPN clients to access the 'remote lan' whilst using their local connection for the internet. This works! Thanks again.

@dlogan
The client connections to a single instance happen within OpenVPN. pfSense gets no notice if a client is connected or not.

Gateways can only be added to OpenVPN instances and now your goal is to do all connections with a single instance for whatever reason. So you can only have a single gateway for all naturally.

You can monitor the client connections in the OpenVPN dashboard widget or in Status > OpenVPN.
You may also add additional gateways to the OpenVPN instance and monitor a remote IP, but there is no way for pfSense to do a gateway failover as you did before, since there is only a single gateway.

Solved.

We informed the openVPN server running on Debian about the LAN behind the pfsense with iroute stanza in /etc/openvpn/ccd/ and it can access the cloud pcs now.

Thank you

@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.