Thanks a bunch. That did the trick. -Ivar

That sounds like a nice "dummy proofing" patch. I sometimes start going cross-eyed when staring at my lists of subnets for all the various tunnels / VLANs / etc.  I often make use of a handy tool called subnetcalc to check for overlapping IP ranges. If you're on a Mac and use Homebrew it's available via brew install subnetcalc

NAT is not a security mechanism, you can accomplish exactly the same thing with firewall rules and no NAT.

Good… Mainly, these things need to match on both ends.

If your VPN server works in "SSL/TLS + user auth" mode and you have checked "Strict User/CN Matching" you have a 2FA. However, if "Strict User/CN Matching" isn't checked connection is established if user/pw combination matches to any entry in users database and certificate matches to servers CA. With other words, any user who has an available certificate can login with any username in database.

Yes.  The connections allowed into a pfSense node from the other end of an OpenVPN connection are on Firewall > Rules, OpenVPN tab. So on the pfSense server, you would simply not pass connections from 10.0.2.0/24 or 10.0.3.0/24.  On Clients 1 & 2 you would pass connections from 10.0.1.0/24. You can also assign interfaces to OpenVPN servers so you can have a firewall rule tab for each server, instead of all OpenVPN servers combined.  This gives you a little more granularity and lets you do things like NAT out a VPN tunnel, etc. It doesn't have to be three different servers either.  You could do it with one Remote Access (At least I think that's what you're describing as Server A) and one Site-to-Site (to go to Clients 1 & 2).

…And so I fixed the issue, kind of.  Reading through the forum, I realized that I did not "Run as Administrator".  Curious though, why would it work for a while and just stop, unless now, running the program as Administrator, where as before, my users did not have to "Run as Administrator", until today.  Puzzling indeed.

nevermind it's fixed i redid the openvpn config and the ruleset got updated.

Kindly click the Client Specific Overrides tab…

On your LAN and OpenVPN "road warrior" server, use more obscure private IP address/subnets. Do NOT use 192.168.0.0/24 192.168.1.0/24 Then when you sip coffee and VPN in from your phone at your local cafe which already uses something like 192.168.0.0/24 there will be no conflict.

If there are pass rules on LAN, then the traffic is going to get out of the source end. But if you really disabled all OpenVPN rules on the remote end, then the traffic must be dropped on arrival at the remote pfSense. That should stop any intranet-based Skype connection from being set-up, and Skype should end up finding its way out to public internet Skype servers to make the connection. If you are just using the site-to-site OpenVPN for traffic to servers at other sites (like you say, using RDP, or file-shares or…) then you can make the rules on LAN to pass to just those remote server IPs and block to the rest of the remote intranet subnet/s. And similar rule/s on the OpenVPN incoming at the end for good measure. That should stop client-to-client stuff across the OpenVPN.

Solved! Thanks everyone for the great hints - especially CMB about the IPSec overlapping addresses. Prior to setting up OpenVPN, I had an IPSec tunnel working but wanted to try OpenVPN for data compression.  While I disabled the IPSec tunnel on my home router, it appears I forgot to disable it on the office router.  Thus, the remote router had a route back to my home network via the IPSec tunnel and not the OpenVPN tunnel. Appreciate all the good replies!

Fantastic, this is exactly what I was looking for. Thank you for the help!

@Tired2: I guess it translates all the IPs on the HQ subnet over to a different range maybe? Yes of course, that is the whole point… you point the remote site to the NATed ones, instead of the conflicting subnet.

Figured it out, went back in to OpenVPN settings and changed my DNS Servers to Goggle's Public DNS Servers 8.8.8.8 and 8.8.4.4 and restarted OpenVPN service just in case - Now working perfectly! So my initial DNS entry was my pfSense IP which had I thought about it, would have realized that won't work.

SOLVED

Sigh. Selecting three absolutely worst IP ranges is quite an unique achievement in itself. Hope you never ever need any roadwarriors stuff working on any of those.

I used this same configuration to set up a pfsense here using my pfsense in the USA as server. I'd bet you can use your certs and MTU settings etc from your current vpn and use the strongvpn set up instructions to get what you want.