@viragomann
when i check "Redirect IPv4 Gateway" then "IPv4 Local network(s)" is hidden. But I am searching for the field "IPv4 Remote Network" - which never apears.

I just found out that "IPv4 Remote Network" is only shown when Server mode is "peer to Peer (SSL/TLS)" instead of "remote access (SSL/TLS)

was useful to know. I was looking for good vpn service

Ah! That makes sense. I was under the impression that everything under 'Services' -> 'OpenVPN' was server-related, but pfSense can be a client too, of course.

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.