About the AES-NI: I just checked, I guess I'm good to go if I'm going to use Intel's 7th gen CPU, now the question is… what speeds? i3 3.9Ghz dual core? i5 4.2Ghz quad-core? : The following processors support the AES-NI instruction set: Intel Westmere based processors, specifically: Intel Westmere-EP (Xeon 56xx) (a.k.a. Gulftown Xeon 5600-series DP server model) processors. Intel Clarkdale processors (except Core i3, Pentium and Celeron). Intel Arrandale processors (except Celeron, Pentium, Core i3, Core i5-4XXM). Intel Sandy Bridge processors: Desktop: all except Pentium, Celeron, Core i3.[5][6] Mobile: all Core i7 and Core i5. Several vendors have shipped BIOS configurations with the extension disabled;[7] a BIOS update is required to enable them.[8] Intel Ivy Bridge processors. All i5, i7, Xeon and i3-2115C[9] only. Intel Haswell processors (all except i3-4000m,[10] Pentium and Celeron). Intel Broadwell processors (all except Pentium and Celeron). Intel Silvermont/Airmont processors (all except Bay Trail-D and Bay Trail-M). Intel Skylake processors. Intel Kaby Lake processors.

Might have answered my own question here. Would it happen to be this option in the GUI under Advanced -> Networking Refer attached image.  

I nuked the install and started fresh.  It works just fine now.  Not sure what happened in the configuration that messed everything up, but it seem fine now.  I appreciate the help.

OpenVPN 2.4.x has its own service and the GUI controls the service – it does not need administrator rights. That works fine on Windows Vista and later. Thus, OpenVPNManager was removed because it no longer was necessary. That said, OpenVPN 2.4.x is not supported on XP. If you must still use XP, you're on your own there.  If you still need OpenVPNManager, you can install it yourself manually separate from the actual OpenVPN client.

Hi, this is the schema of network SITE01                                                                                SITE02 [FORTINET-FW]       ||                                                                    ||                                                                            ______ |          |                          (optical-fiber)                              |          | |LAN01|==[CISCO01]====== ======[CISCO02]==  | LAN02 | |          |                                                                            |            | |          |                                                                            |            | |(192.168.1.0/24)                                                            |(172.16.1.0/24) ||                                                                            |__| But when this SITE02 i execute tracert to mail server (mail.domain.com) this out to internet and down by the Fortinet is for this that i need install pfsense. Thanks for you help

A CA/Cert made with the Wizard should work and show up in the Cert Manager afterward. You can make them yourself, too, but using the Wizard is also fine. There is no specific requirement for the information you put in the CA/Cert so long as you respect the limitations for special characters in the current release. It should be unique but it can be generic. Meaning if you have multiple CA entries or multiple certificates, they should not have identical values for all fields as this can confuse many utilities which locate certificates by subject. The CA/Cert for OpenVPN are self-signed so they don't have to be verified beyond the certificate being made from the correct CA.

I finally got it working. I used a combination of the old "password file" guide, Finger79's settings above, and the packaged ovpn file for the NYC Server, and finally got everything working. (Note, didn't use the OVPN vile, but used the certs it came packaged with.) @Finger79: I'd read some things that crypto acceleration in OpenVPN is automatic and that the "crypto acceleration" drop-down is legacy or doesn't apply to modern CPUs.  If that's off, then let me know. In retrospect this makes a lot of sense.  I tried with it both off and on, and didn't find it made any difference in CPU load during bandwidth tests.

Thanks so much - finally got everything to work!

The point is if that feature is not disabled and the gateway is detected as down, the rule still exists but without the policy routing applied so all that VPN traffic goes to the routing table and out WAN in-the-clear. This is the default behavior. By default, when a rule has a gateway specified and this gateway is down, the rule is created omitting the gateway. This option overrides that behavior by omitting the entire rule instead. tagging/tagged is the best way to ensure traffic that should go over the VPN does not go out WAN. If it should go over the VPN tag it. Do not let anything out WAN with that tag.

Not a problem from 2.3.4 just a nasty route on the wrong place …

https://forum.pfsense.org/index.php?topic=130407.msg718680#msg718680

Uninstall your package and then reinstall it – don't just do a reinstall/upgrade. If you were coming from a much older version there was a bug a couple revs back that could delete the template files, so the template pkg needs reinstalled, which would only happen if you removed it completely then reinstalled it.

Well, reinstalling the openvpn-client-export package added back the Export tabs, but I found out it also changed our client export files. I downloaded a new config file & found that the two bottom lines in the old version's client config file:       tls-auth pfSense-udp-<port>-<username>-tls.key 1       ns-cert-type server Were replaced with the following line:       remote-cert-tls server I updated my config file (instead of right-clicking and selecting "Connect", select "Edit Config") and now VPN connects like normal. I updated the package to 1.4.5 this morning, and it still connects fine after making the change above.  Now I just have to update the config file on the other laptops.</username></port>

Yep. Just create a * * * rule on the OpenVPN interface (or limit it however you want.) Until you do, no traffic will pass on it.