The NAT is only in effect when the traffic is being routed out that interface.  That's the standard method of NAT when Multi-WAN. This is probably the PIA pushed default route AGAIN. Check the Don't pull routes checkbox in your PIA client config.  It will then be up to you to policy route traffic to PIA. I have no idea what that rule is on your PIA interface.  Delete it. You need to policy route traffic by matching it on the interface it is RECEIVED ON (DMZ, whatever the 192.168.2.0/24 interface is) and set the GATEWAY to PIA for that traffic.  Read the tutorial again. https://doc.pfsense.org/index.php/What_is_policy_routing

@SLIMaxPower: So it looks like afterall I will have to pay for a VPN. Most likely yes. I'm aware of no such service being free. Let's say I want AU traffic to go through an AU server, and the remaining go through an International server (same VPN provider) and gaming to bypass VPN altogether how to I accomplish this ? By very careful configuration. ;) Your requirements aren't exactly simple and straightforward so I'm not sure someone is willing to give you a complete tutorial on everything. It's usually much easier to get assistance when you present a specific problem you run into when trying to configure something yourself. What I would do if it was me: 1. Search the forum for threads about these kinds of configurations. I have noticed several lately so they shouldn't be to hard to find. 2. Research the market for possible anonymizing VPN-providers. Check the suppliers recommendations on client-side configuration, maybe some of them even have specific examples for pfSense? 3. Try to configure it myself or hire someone to do it for me. 4. Return here with more specific questions if something is still unclear when the above homework was done.

PIA has the equivalent of your "Force all client generated traffic through the tunnel" setting.  This amounts to them pushing a default route to you.  So, naturally, all traffic is going to go to them when it's connected. Add route-nopull; to the advanced settings of the PIA client instance or, if on 2.2, just check the Don't pull routes checkbox and bounce the VPN. It will then be up to you to policy route the traffic you want to go to PIA. This is the default route: Internet: Destination        Gateway            Flags      Netif Expire 0.0.0.0/1          y.y.y.5            UGS      ovpnc2

Ah ha.  The additional data I see being returned to me is because the Azure Multi-Factor Authentication server is NOT backended by Active Directory directly, but through a Network Policy Server running RADIUS - and returning client options that the OpenVPN client doesn't accept, apparently.  I started another thread on how to setup 2 factor using Azure MFA and OpenVPN using the results I've found troubleshooting this week.  Thanks for you response!

Unless you are a network supergenius, keep things on /24s just for simplicity until you really have a great understanding of subnets and subnet masks.

WAN is a failover-group of three conections. Not round-robin, the fastest is tier1, the slowest is tier3. LAN network is 10.10.10.0/24 where the gateway to WAN is 10.10.10.252 (CARP vIP) VPN network is 10.10.90.0/24 Clients with an IP from this network don't get a gateway-IP during connection. Clients from VPN can access the LAN Without gateway Windows blocks all incoming traffic from VPN-TUN, so Clients from LAN can't access VPN-Clients (if the windows-firewall is OFF they can, but this is no solution) As you told me, there is no DHCP. Then - in my case - 10.10.90.1 is the right IP for the VPN-Clients as gateway? Clients get an IP via VPN, also they get the configured DNS, but no gateway and I can't find where I can manage that. regards

couldn't setup a simulated leased vpn circuit so i implemented the lab settings on to the production environment after office hours… removed the static route from office1 lan to office2 lan on the office1 pfsense and everything was still working... until i disable the static route from office2 lan to office1 lan on the office2 pfsense. when i return the static route, everything works again (had to connect to one of the office2 terminals via teamviewer). might have to check out ospf... thanks!!

Well no, unless you check "Strict User/CN Matching"… Still, much better practice.

It appears that this was an issue with the clients being on the same network as the DEMO lan (the clients have more than one network adapter).  After I moved them to a different network, everything worked as expected. Thanks for assisting.  This is resolved.

It seems the NAT settings were the culprit. I changed to the new outbound nat hybrid mode, and removed a "catch all" rule I had entered (which I think was a bad idea), and things are working good now.

Nm figured it out. All I had to do was to add the subnets to the local/remote network(s) in the OpenVPN configuration.

I figured it was something like this. I have over 60 sites, but have narrowed it down to geographical areas. I plan on implementing this in three sites first and then breaking the rest up. Most data will still be going to our data canter, so removing the remote LAN is not an option at the data center. I think I can just setup routes or administrative distances. Thanks for your reply, Dilster

You seem to have forgotten what type of vpn you are using…

You need rule/s on Firewall->Rules, OpenVPN tab, to allow traffic from source OpenVPN tunnel 192.168.30.0/24 to destination LANnet 192.168.20.0/24 - or for a start put a pass all rule (protocol all source any destination any).

Did you figure this out or find a solution?  I think am trying to figure out the same exact thing but having a hard time figuring it out at this time.

Assuming there is a straight forward setup at each end, you either have a routing, firewall, NAT, DNS or application (phone system) issue.  You've stated that both sides can access each other's resources, so the networking should be in place, but I hate to assume, so we need more details: Post a network map, so we have a better idea of how things are connected. Post the server1.conf from server and the client1.conf from the client. Post a screen shot of the firewall rules from the LAN tab and OpenVPN tab on each end What kind of phone system is being used and what is it running on? Are there any blocks in the logs at either end?

@Derelict: Those look like changes so the VPN clients can get out to the internet (not sure about the WAN_DHCP on the OpenVPN tab). You asked about being able to get to hosts on LAN, not the internet. Initially I couldn't ping the LAN or the internet. Somewhere along the way the LAN started working, but the internet held out for a while. While I was able to figure out how I enabled the internet (per the above), I have no idea what I did that got the LAN working. It could have been as simple as rebooting the box (instead of just the OpenVPN service). Thanks for your help.