@heper: the /var/etc file is generated dynamically. (almost) everything in pfSense in written in /conf/config.xml the individual config files for the various services are re-generated each time a change is made in the GUI so, instead of writing to /var/etc/whatever: use a script to make changes towards the config.xml. It's best to use the builtin function for this (check developer shell wiki: https://doc.pfsense.org/index.php/Using_the_PHP_pfSense_Shell) Oh thanks. Can I call /usr/local/sbin/pfSsh.php from the command and feed it commands. I tried the following which didn't work. /usr/local/sbin/pfSsh.php "print_r ( $config, true ) ; exec;" config: Undefined variable. The pfSsh.php file only accepts commands via redirection from another file?

With redirect gateway you do not have to push those routes. If you only want to route certain networks from the client over the VPN then uncheck redirect gateway and you will be able to enter those networks there. Again, you don't need to mess with those push route entries in that case. You have wide-open rules on OpenVPN so it is not that. You can ping so the routing is fine. This will probably end up being something on the servers preventing the connections from the 192.168.2.0/24 network on those services. Capture traffic on pfSense LAN looking for the TCP SYNs going to the servers and nothing coming back. That will point you directly at the server configuration.

The OpenVPN tab is, under the hood, just an interface group containing all OpenVPN instances - all servers and all clients. You can use it to generally control traffic into your firewall from OpenVPN. You cannot, however, get special things like reply-to, which automatically sends reply traffic back out the interface into which it arrived because it is not an interface, but a group. If you assign an interface to an OpenVPN server or client, the rules there apply ONLY to that server or client and you get magic things like reply-to. You can also use it to perform outbound NAT, policy route to it (because the assigned interface has a matching gateway), etc. If you want to take advantage of this, the rules on the OpenVPN tab must NOT match the traffic you are interested in because they are processed first and first match controls. I generally delete all rules on the OpenVPN tab when I start using assigned interfaces. If you want more information I suggest a gold membership and the included OpenVPN hangouts and pfSense book.

Can you describe in more detail how you have the VPN(s) setup? Which specific OpenVPN modes, and how the client/server instances are arranged?

Thanks for the tip. Very interesting results on the speed test. With my setup, using AES-128-CBC (as per PIA) I get a theoretical throughput of 87Mb/s. What I find interesting though is a while back, when I first got PIA, I could get 250Mb/s throughput. I assumed this was due to compression and obviously fake as I only had a 200Mb/s connection. I'm still baffled as to how this has changed… I'll have to rethink my firewall then if I want to move up ;)

@mhertzfeld: Curious why you are not pointing unbound to the PIA DNS servers. If privacy is your concern those are the servers you should be using. I have nearly all my traffic going through a single PIA tunnel and have never had DNS performance issues. They don't appear to support DNSSEC.  I've got a pair of bind9 servers up and running with full recursion + DNSSEC authentication now, and everything is good.  Average query times are sub 200ms now for uncached entries. They're talking to the root servers via PIA, so I'm ok with that. Never could get unbound to behave right, even leaving the tunnels out of the equation.  There were multiple addresses it would not resolve for me, forwarding or recursion didn't matter.  Not sure what's up with that.

@viragomann: Have you also other services available yet? If not, check if "Block private networks and loopback addresses" is checked in the WAN interface settings and uncheck it if it is. If the issue still persists use the "packet capture" tool from the Diagnostic menu to check if the VPN packets reach the WAN interface. Select WAN interface and enter 1194 at port. It works! It was as simple as unchecking the option you mentioned and forwarding the port from the router to the pfSense WAN interface. Thank you so much, I've been pulling my hair out over this one. Now, I just have to figure out how to pass over DNS settings so that my colleague can resolve local hostnames and access the internet while connected to the VPN. Edit - that was easy, I have now passed DNS settings over to the VPN client, too.

Currently they only VPN in with their AD credentials.  I want them to have to enter their AD credentials and a token code.  Requiring a token code from a separate device is much more secure than a certificate alone especially if a user has their workstation/password compromised.  It also takes away from having to manage individual user/machine certificates.  The last 3 places I've worked required RSA hardware tokens, but the team here wants to try out an application based token such as Google Auth/Duo/Authy.  I'm well aware the ease of using a certificate/credential alone, but that's not the direction we chose to go.  Thank you for your input though :)

I run a number (30+) of DDNS based OpenVPN links continuously with none of the described issues. At least two of the links use free No-IP names without any difficulties. For me, I've never needed to setup a "watchdog" service to ensure the link is up. OpenVPN does a good job all on its own. I'd look at removing the watchdog and then trying to analyze the real reasons for any OpenVPN failures. If you're looking tp try a different free DDNS provider, FreeDNS has worked well for me over the years.

It's the firewall in FreePBX that's blocking non-local IP addresses.

I am using the subnet feature (pfSense) trying to migrate from the net30 architecture.  Some of my clients are 2.1.5 the rest are 2.3.2. have infconfig-push configured properly in the server's client spec override. I believe I have configured this correct because routing seems to work.  However, I cannot find the client tunnel-end address I assigned to any of my clients in their routing tables ovpn or freebsd.  Ifconfig yields only 172.16.64.0 –----> 17216.64.1 (the server) on the relevant interface.  Ovpn status routes shows only 172.16.64.0 for the virtual interface. Is this correct?

Awesome, thanks that answers a lot of questions, I was farting around with settings for the firewall rules and borked something up, once I get it straightened out, I'll try that. Thank you for your reply. Yes, I am limiting the size of the subnet, but I will try increasing the number of IP's available, initially the scope has strictly been to get one tunnel working, but I fully expect there will be multiple clients in the near future. Part of it is that I have to consider if the single server will be sufficient for all our needs or if a 2nd vpn server instance will be needed.

Digging this thread from its grave to post my solution: I enabled "Client Specific Overrides" and literally copy-and-pasted my configuration from the "Servers" tab. I have no idea whatsoever why this would be needed but everything works now. If someone could explain why I needed doing so this could maybe help another poor soul with the same problem.

I changed to 192.168.2.1/24 but after of this i lost wan ip on pfsense, but i can ping it.. http://prntscr.com/cpnhll http://prntscr.com/cpnjdk

At a high level: You need to push the Site 2 Lan subnet (192.168.4.0/24) to your clients in the roadwarrior's OpenVPN config You need to add a route for the roadwarrior's tunnel network (192.168.2.0/24) in the Site 2 OpenVPN config