@divsys:

Or to put it another way, if I define 192.168.100.0/28 as the allowed network within my 192.168.100.0/24 LAN

How will you do this??

Not with the "Local Network/s" option in the OpenVPN server settings, do you? That's just for pushing routes, it's not for securing your internal network.

@divsys:

It would be much nicer if I could securely specify the subnets allowed at the granularity of each client as they connect.

You can realise this with "client specific overrides" to allocate a specific tunnel address to a certain vpn client. Then you can use this tunnel address as source address in your firewall rules. It's a bit of work, but it's doable.

Happens to me as well, once or twice a day or so, seems to be related to VPN reconnects/renegs as I always ses a couple of TLS handshake errors in the logs around the same times.
I don't bother restarting the service all the time, as it still works and I see that the connection is up under gateways. It will still lose sync sooner or later.
I would be nice if it where fixed though… :)

Regards, Wish

So I stopped my OpenVPN server and my routing tables looked like this

default xx.xxx.xx.xxx UGS 354394 1500 em0 4.2.2.3 xx.xxx.xx.xxx UGHS 3 1500 em0 10.0.1.0/24 link#1 U 9835635 1500 re0 10.0.1.1 link#1 UHS 0 16384 lo0 10.0.2.0/24 link#3 U 428520 1500 em1 10.0.2.1 xx.xxx.xx.xxx UGHS 0 16384 em0 xx.xxx.xx.xxx/30 link#2 U 206541 1500 em0 xx.xxx.xx.xxx link#2 UHS 0 16384 lo0 127.0.0.1 link#8 UH 1542 16384 lo0 208.67.222.222 xx.xxx.xx.xxx UGHS 15 1500 em0

and started the OpenVPN client without any luck.

0.0.0.0/1 10.21.3.185 UGS 4 1500 ovpnc1 default xx.xxx.xx.xxx UGS 354728 1500 em0 4.2.2.3 xx.xxx.xx.xxx UGHS 3 1500 em0 10.0.1.0/24 link#1 U 9836394 1500 re0 10.0.1.1 link#1 UHS 0 16384 lo0 10.0.2.0/24 link#3 U 429113 1500 em1 10.0.2.1 xx.xxx.xx.xxx UGHS 0 16384 em0 10.21.0.1/32 10.21.3.185 UGS 0 1500 ovpnc1 10.21.3.185 link#11 UH 68 1500 ovpnc1 10.21.3.186 link#11 UHS 0 16384 lo0 xx.xxx.xx.xxx/30 link#2 U 206881 1500 em0 xx.xxx.xx.xxx link#2 UHS 0 16384 lo0 127.0.0.1 link#8 UH 1551 16384 lo0 128.0.0.0/1 10.21.3.185 UGS 134 1500 ovpnc1 173.244.55.5/32 xx.xxx.xx.xxx UGS 169 1500 em0 208.67.222.222 xx.xxx.xx.xxx UGHS 19 1500 em0

do you mean 10.0.3.145? In that case my guess is that it is the virtual IP i get from the client, so it shouldn't be static.
I haven't configured anything regarding 10.21.3.xxx

https://forum.pfsense.org/index.php?topic=76015.0

Thanks again for all your help.

@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.