That was it, thank you!

Good that it works. On that note - is your system clock sane? Cannot imagine why'd something say it's uptodate when it's ages behind.

You have to enter the server sides local subnet or the particular hosts you want to access in "IPv4 Local network(s)". Try to access the file share by its IP, e.g. \192.168.1.25\share Bear in mind that Windows firewall blocks access from other network. So allow the access in the Windows firewall or disable it.

Thanks jimp, that did it. Didn't occur to me since I didn't need to do that for my LAN subnets, but now that I've added an allow for the VPN subnet they can resolve.

Hi, Answering to myself ;) There is no need of "local network" option anymore and my problem was a switching issue !!!

I made a firewall rule to allow 10.8.0.0/24 in windows firewall. That works, but it would be better If I could get it to show private, and not have all traffic go through the vpn.

Publicly signed certs have no business being on OpenVPN and no client would have problems because of that. You're making things much more difficult for no benefit.

Closing comment: My initial testing was done using Windows 7 clients. However, the laptop clients in use are actually Windows 10. When I tested the W10 clients, everything worked out of the box - browsing and sharing, as if they were on the same physical network. So yes, a Peer to Peer (shared key) connection is a viable setup for me.

aha!  Got it!  In addition to those two links in my initial post, getting OpenVPN to start and connect at CentOS 7 system start was nigh impossible, but for this! https://ask.fedoraproject.org/en/question/23085/how-to-start-openvpn-service-at-boot-time/ "It seems this is a known bug/limitation in the design of the Systemd framework in combination with OpenVPN. " Once again, without derailing this topic, thanks for nothing Systemd!  And, I've figured it out.  Whew!  Hope these links are helpful to someone else.

There is no automated way to accomplish that, you'd have to create the certificates individually. You could create the certificates using OpenSSL outside of pfSense, but to use the export package you'd still have to import them to pfSense.

Ah.. Yeah and somewhat current nas disk should be easy to saturate a 100mbps network.. So sure if you need to share the load across multiple networks for performance, then yeah makes sense spread the load so you can get say 300mbps to move stuff to and from your disk as long as the clients are coming from different networks. The only concern with such a network is possible asymmetrical or hairpins ;) Glad you got it sorted.

Do you run snort? I've found these instances and it typically happens when I use the TCP and TCP Strong/4096 configs, on a OpenVPN client PC, and the connection to PIA would drop.  On the regular IP config file, connection to PIA can and have lasted for weeks. I ask about snort because I'm noticing this alerts/blocks…which I believe may be related to a "keep alive" from the server or more likely, client side [?]  Please pardon my ignorance as a hobbyist. These are alerts/blocks from snort on the LAN side. 209.222.18.222  53 1:28039 INDICATOR-COMPROMISE Suspicious .pw dns query 209.222.18.218  53 1:28039 INDICATOR-COMPROMISE Suspicious .pw dns query 209.222.18.51  502 1:2018378 ET CURRENT_EVENTS Possible OpenSSL HeartBleed Large HeartBeat Response (Server Init Vuln Client) Suppressing or even disabling these rules are easy enough but I'd like to know what I'm disabling first.

Add the tunnel subnet of the respectively other vpn server to the "Local Networks" of each server.

@Pippin: with openvpn 2.4 and AES GCM on AES-NI hardware Even without AES-NI capable hardware it will improve I would think. It'll improve, but the difference won't be as dramatic as for the AES-NI hardware (because you're not replacing a software MAC with a hardware-assisted MAC, you're replacing one software MAC with a somewhat more efficient software MAC.) And really I'm using AES-NI as a more familiar shortcut here, the real differentiator is the PCLMULQDQ operations, which are only on CPUs with AES-NI, but there are AES-NI CPUs (like the avotons/rangeleys) which lack PCLMULQDQ and aren't as efficient for AES-GCM on an instructions-per-byte basis.

It's working now, I can ping the vps, and reach it throught 10.0.8.3 from my LAN :) Dunno what I did…just uploaded the config again, restarted, and suddenly it worked.