"but if you turn on TLS Crypt (new in 2.4, doesn't exist on older versions), then the clients would also have to be 2.4." QFT! This drove me nuts for a bit trying to figure out why my phone could connect to the udp session but not the tcp session.. Seems I had manipulated the settings in the tcp settings and enabled tls-crypt.  While the udp did not have it on ;) The openvpn connect app on the iphone does not support tls-crypt as of yet.  Was like WTF.. My pc connects no issues, but why was the phone not working.. I normally have never had to make any adjustments to the openvpn clients as upgraded over the years.  Currently running 2.4 beta and could connect no problem.  But wanting to check out the settings that were new I did make some adjustments to my tcp settings.  PC clients all working just fine - had not connected from phone in a while using tcp.  But then wanted to connected from work on the wifi and there is proxy.  So you have to use tcp for that - had forgot about the tweaks I had made.  So it threw me for a loop for a bit. So I have highlighted jimp statement - as it could throw you for a loop if you do not pay attention ;)

OpenVPN does not currently perform RADIUS accounting.

Allowing users to download their own VPN installers is not currently possible and not something we are likely to implement until a secure method can be devised. Giving users access to the export package will let any user download an installer for any other user. It does not restrict them to their own installers. The main reason it's a bad idea is that it takes all your extra security/authentication factors (TLS key, certificates, etc) and makes them practically worthless. All someone would need to do is obtain a user's name/password and they could download their VPN installer. Even though we do protect against brute force attacks, that doesn't help if someone gets the user/pass directly by phishing, social engineering, and so on. Search around on the forum and reddit. I've ranted about it several times before.

Bump anyone???

I have looked into that before and it wasn't so easy to deal with. Granted that was a couple years ago, and it might have changed since then. The problem is that all of the other platforms only require us to create a standard style OpenVPN configuration but package it in slightly different ways or add/omit certain directives. Chrome OS requires you to make a specially-crafted file in a completely different format. I'm sure it could be done, but it would require a completely different style than anything else the package has already.

The NAT configuration on the R7000 side looks wrong. You probably do not want NAT there and you do want to define the networks if you expect to be able to directly-address the LAN on that side.

@Mr.: The problem is: in OpenVPN I can not add static IP's for the smartphones. You can set static IP's in OpenVPN using Client Specific Overrides, not necessary to create a specific pfSense interface for that.

For anyone who has this problem in the future, I did a facepalm when I realized it was DNS. We have a local DNS server which the default adapters are set to through DHCP. However, it had to be configured on the OpenVPN server as well. I had done it the first time, but deleted my entire OpenVPN setup as it wasn't working at all - redid it from scratch and forgot to tick the box for specifying a DNS server. I went back and did that, reconnected, and it all works. My eureka moment was trying the file server by its direct IP instead of UNC - it worked flawlessly. I feel like an idiot for not realizing this sooner but hopefully someone who has the same brain fart as me can benefit from my post. I hate DNS….

Doesn't need to be a port forward. Just put a rule above the one that policy routes to PIA for that destination and don't set a gateway on it. https://doc.pfsense.org/index.php/Bypassing_Policy_Routing

If the client is getting proper responses to the keepalive pings I am not sure what to do either, other than change providers.

First, this could merely be a timing issue.  Those syslog messages were logged at ~11:30p last night… when did you disable the interface? Second, after disabling the interface, nothing actually happens until hit the "Apply Changes" button.  Was this done?  If so, when?  If not, that would explain why things are not behaving as you would expect. Third, What interface are those firewall rules on?  Also, when were they disabled?  Same question here.... after disabling the rules, did you hit the "Apply Changes" button?  If so, when?  If not, that would explain why things are not behaving as you would expect. 2. I didn't understand: IF I disable the WAN-firewall rule for the server, server and client shouldn't be able to make contact, so why the VPN-tunnel shows as up in the dashboard, and why does the firewall also report traffic between server and client? I specifically ask because my goal is to have Synology servers sync/backup to eachother via VPN, but I want to add a time schedule to the firewall, disabling the open WAN port firewall rule most of the time.  And hence I noticed when the rule is disabled, the tunnel stays up and traffic keeps on going. There are still some unknowns here so it's hard to offer help when we only have 70% of the info, but these questions depend on what rule(s) we're talking about, on what interface and what your objective is.  Also, are we talking about PFsense boxes being the VPN server and VPN client?  Or are we talking about a server on your network making an outbound client connection?  There are different answers depending on what you're doing.  Post a network map, showing your topology and explain what you're trying to accomplish, so we can offer targeted advice. 3. About that OPT6, would you know: a. Why the tunnel didn't work without adding the OPT6 interface (found it somewhere on Google I had to do this - it didn't work without that interface, honestly). b. Why the firewall log reports traffic passing on OPT6 (previous pic) when that interface isn't even enabled (previous pic), and so it isn't even possible to add firewall rules for OPT6? a.  This goes to my previous point, what is the setup and what are you trying to accomplish?  Is this a site to site tunnel between two PFsense boxes or a tunnel to 3rd party VPN provider?  Depending on what the objective is, assigning a tunnel to an interface is necessary to create a gateway for use with policy based routing b.  Depends on answers to previous questions.

Rebooting pfSense seems to have fixed it :)

I forgot to mention in my setup you also cannot have 'duplicate-cn' set in the advanced settings for the server. Essentially if you allow a single certificate to come in for multiple devices (like phone and laptop) it would not work since the IP would try to be assigned to 2 devices.

So, you're basically looking to build a site to site tunnel.  Have you checked the wiki?  You have two options, Shared Key or PKI: https://doc.pfsense.org/index.php/OpenVPN_Site_To_Site https://doc.pfsense.org/index.php/OpenVPN_Site-to-Site_PKI_(SSL) If you require certificates, then PKI is what you want.

@Gertjan: @Mr.: ….. UNLESS it is on your own LAN and you are both the only sender and receiver. With or without the mail server on the other side of the planet ?  ;)

So as an update, the reason it seems that I could not get to certain sites was due to the machine involved had not been assigned an IP by the Pfsense DHCP server and so it was not routing correctly. I ended up assigning a static IP to the machine and then forcing it to a new IP which resulted in the machine now working as expected. Patrick

I've had a couple random issues in the past when setting up new clients, and what fixed it for me was to uninstall OpenVPN on the machine, use the client export to download again, then reinstall. If this doesn't work (or if you've already tried this), please post the log that shows the errors & someone on this forum should be able to figure out how to resolve this.

The connectivity issues were remote users weren't able to log into any of the servers in the LAN.  They got a "server is not available" error.  All these were virtualized on one particular machine.  When trying to log in to the virtual machine itself via either the vSphere client or web client, the connection timed out.  I logged in via OpenVPN and managed to RDP into the DHCP server, then I could use the web client.  (I installed VMWare tools on the machines that didn't have them already and for some reason they had connectivity again.  Still working on why that happened, too.) The servers are now reachable as they were before, but the vSphere client and web client are still nonfunctional from outside the LAN.  I saw the DHCP address and thought that might have been my issue, but I'm guessing that it isn't. Time to figure out just what else could have made this happen.  I appreciate your time, jammcla.

Sorry for the delay in responding.  The remote user malfunctioned and didn't do it right.  Uninstall of client and reinstall solved the problem.