Yes, others are having this problem.  See here: https://forum.pfsense.org/index.php?topic=77637.0

Yes.  I responded in the thread you linked, OP.

When you say "My DC pfsense is acting oddly", what does the "DC" reference?

It's difficult to help troubleshoot without details.

1. Change your FW rule to any/any on the openvpn tab
2. Post your server1.conf.

Add any/any rules to both sides on the openvpn tab.

Post the server1.conf from the server end and client1.conf from the client end.

AFAIK you can only have one OpenVPN Server and one OpenVPN Client pair using the shared key method. You can have multiple Server/Client pairs for each remote network though, if that makes sense. The remote computers will just need to use the pfSense fw running the OpenVPN Client as their gateway, that or you would need to setup a static route on each remote PC.

Have you configured a rule to allow access in Firewall > Rules > OpenVPN tab?

My bad….
looks like I looked at the wrong line, when setting the extension to NAT=yes (it didn't want the other subnet to register) the phone was working just fine.

I need to say that the pfsense Router acts as a VPN Client

I noticed that when I ran with that config, that my Windows PC no longer had any routing information in it for the remote networks. I returned it the two simple push statements.

I no longer believe that the problem is in the OpenVPN configuration, but rather, is in the lack of static routes in the gateway and router at each of the sites. Your link https://community.openvpn.net/openvpn/wiki/RoutedLans pretty well documents the problem in the section called, "ROUTES TO ADD OUTSIDE OF OPENVPN".

Thanks for the links! They were very helpful in my understanding of what iroutes really do.

So after 5 straight days of connectivity, one of the VPN clients died again.

Service is up Last log entry for the openvpn client is sequence completed, many hours before. Can't ping monitor IP through the vpn gateway. pfSense dashboard / gateway monitor shows the gateway as down.

Now that the issue has happened again, regardless of the cause, I was able to test my watchdog script. It successfully matched the gateway that was down to a vpn client and restarted the corresponding service. If I run it again, it sees scans the gateways, sees they are up and does nothing.

I downloaded the cron package, added the script to check the gateways every minute and I'll monitor to make sure it rebounds.

Here is an example of what pfSense reports for a downed gateway when calling a function that gets all gateway statuses:

[1.2.3.4] => Array         (             [monitorip] => 8.8.8.8             [srcip] => 5.6.7.8             [name] => VPN0             [lastcheck] => Wed, 13 Aug 2014 21:02:31 -0400             [delay] => 0ms             [loss] => 100%             [status] => VPN0down

Where 1.2.3.4 is the gateway. I noticed 2 bugs in status. When gateways are up, status shows none. When its down, as you can see, the string has more than just down, so my script checks if the status string simply contains down.

If it matches this gateway to one used by a vpn, it restarts the corresponding vpn service, and you get an output like so:

VPN Gateway 1.2.3.4 for VPN id 0 is reporting as being down. Looking for VPN service associated with vpn id 0 Found corresponding service: OpenVPN client: MyVPN. Restarting...

otherwise, if everything is fine, you get:

All vpn client gateways are up.

Attached is the script in case it helps someone, gets turned into a package, incorporated into the watchdog package or into pfSense.
PS It can be optimized, it doesn't have to go the extra mile to find the service object to get the description, that's just for clarity when running from the shell.

Hopefully this will solve the rest of my vpn connectivity issues.

openvpn_hb.php.txt

What does it show you for auth..  Send the capture to me and be happy to take a look.  Email me and attach or email me or PM and will give you my personal email, etc.

The scripts must be local.

If you need more clarification, you may need to check with the OpenVPN project directly.

Here is the option explained in their documentations.

–script-security level
              This  directive offers policy-level control over OpenVPN's usage
              of external programs and scripts.  Lower level values  are  more
              restrictive,  higher  values  are more permissive.  Settings for
              level:

0 -- Strictly no calling of external programs.
              1 -- (Default) Only call built-in executables such as  ifconfig,
              ip, route, or netsh.
              2  --  Allow  calling  of  built-in executables and user-defined
              scripts.
              3 -- Allow passwords to be passed to scripts  via  environmental
              variables (potentially unsafe).

OpenVPN  releases before v2.3 also supported a method flag which
              indicated how OpenVPN should call external commands and scripts.
              This could be either execve or system.  As of OpenVPN v2.3, this
              flag is no longer  accepted.  In  most  *nix  environments  the
              execve() approach has been used without any issues.

To run scripts in Windows in earlier OpenVPN versions you needed
              to either add a full path to the script  interpreter  which  can
              parse  the  script  or use the system flag to run these scripts.
              As of OpenVPN v2.3 it is now a strict requirement to  have  full
              path  to  the  script  interpreter  when running non-executables
              files.  This is not needed for executable files, such  as  .exe,
              .com,  .bat  or  .cmd  files.  For example, if you have a Visual
              Basic script, you must use this syntax now:

--up 'C:\Windows\System32\wscript.exe C:\Program\ Files\OpenVPN\config\my-up-script.vbs'

Please note the single quote marks and the escaping of the back-
              slashes () and the space character.

The reason the support for the system flag was removed is due to
              the security implications with shell expansions  when  executing
              scripts via the system() call.

I should add that I worked around this issue by using the tls auth feature that is expressly built into the edit page and then adding the key-direction directive in the advanced section alone like:

key-direction 0;

So perhaps my specific case is a trivial one.  But, it should be possible to do these "inline keys" (and possibly other inline features that I don't know about) and we'd want the handling of that text to be correct.  At the very least, the behavior I've described is unexpected and may cause someone to think their configuration is wrong when it's not. (Hopefully they would check the logs as their first debugging step, though, like I did.)

UP!