Well, the server is 2.3.4. I used a dummy endpoint for tests with 2.3.7 with the same result, so this is a non-issue. Yes, SHA1 is an auth scheme, not an encryption scheme. What makes me wonder is that the dummy endpoint as well as the actual server, when having no auth defined on both sides (hence SHA1 is to be used), the auth works -as expected- but when there' s a config error in encryption or compression, connection breaks -as expected- with an appropriate error message. In the current config/setup however, no matter how erroneous my encryption config or my compression may be, it doesn't even get to the point of complaining the wrong config. This makes me think that maybe there is something wrong with the auth mechanisms to be used by default by the current pfsense version

Ok, I finally figured it out.  Boy what a reminder on why software drive me insane, its just so imperfect. So after hours of messing with this and checking and rechecking, i got onto a thread where they mentioned the ROUTING TABLE in Pfsense.  Humm I thought.  So I went there  on my SEVER PF box. Well look at that, there is some weird IP of 192.168.0.1 attached to my OVPNSRV2 OpenVPN.  So i compare the entries for the server that works and that just is not right…it should be 192.168.2.0/24! So I DELETE the 2nd server which was from A to C.  Go back to routing table and this entry now refers to" TUN" instead of the deleted OVPNserv2.  What the? I restart the OPENVPN services, nope still there. So I had to reboot the Site A PFSENSE box.  THAT go rid of the rouge routing entry! I re-created my 2nd server at Site A and WA-La!  Its all working!  I can PING away! Ok, thanks self! HAve a good day!

Bump! I too have this same question. I am using PEER to PEER with preshared key.  A second connection to the server never generates an entry in the server the two seem to hack each other (when on is up the other is down) so I went to a separate Server for each client connection too. I used different TUNNEL Ip's if that matters, 172.16 /24 and 172.17/24 for the tunnel ips. Anyway with my multiple Servers at site A, I have established both client connections, to sites B and C.  A to B works fine and I can ping and both directions from A->B and B->A fine.  However I CANNOT do the same for A->C or C->A!!! Can not figure it out.  All Client settings ate the same except for those specific to the client. What would cause this?  I can ping from PFSENSE console at site C to ip's at site A, but from any PC at site C I cannot ping anything at site A. Rules look fine, again everthing is IDENTICAL in Clients/Server settings for B and C.  Cant figure it out! Thanks, MP

Have you added the VPN ip subnet in "Squid Access Control Lists" > "Allowed Subnets"

Then the second link for setting up OpenVPN as a Remote Access Server using the wizard is what you're after.

/var/etc/openvpn It's recommended to make the settings in the GUI. There are drop-downs and input boxes for the most common options, if you need others you can set it in the "Advanced Options" field.

after the change this is still an issue at least i was home this time.  i have been statically connecting to 64.237.37.121 for weeks now.  i think i am going to try another server…

Gateway load balancing seems to work well. I have two PIA VPN tunnels configured on an SG-3100. I have them both as part of a gateway group in tier 1, and my test machine matches a firewall rule that sends all traffic to that gateway group by default. When running a Speedtest, the download test uses both tunnels - one openvpn process on each CPU. During the upload test, it only uses one of the tunnels. If I have the gateway group prefer one tunnel over the other, the download test only uses that tunnel and not the other, and the upload behavior doesn't change. I was able to confirm that by watching top from a console and looking at the bandwidth monitor. I managed to pull down 60 mbit over OpenVPN doing it this way a few times, but on average it was about 50 mbit. I know there's more throughput available here given the hardware specs, so I need to figure out the best encryption algorithm to use. I want to try a real bench test to take the intertubes variable out of the equation to see how this really works.

Thanks Pippin. Doesn't help when you are watching the web page for a reason, huh

Just a followup to those who think about cert based OpenVPN from QNAP (client) to pfSense (server). In foreseeable future - password only. From their tech support: I have received information from PM that there are currently no plans for improving QVPN OpenVPN client security. However, I have created a feature request regarding this, so it will be considered and possibly implemented in future.

Where can I get a simple guide to setup openvpn in pfsense?

bump?

captive portal is not going to work. Can you elaborate?  Why? revoke the certificate if the router is lost/stolen This isn't really a good defense against someone with physical access to the router.  I'm less concerned about theft and more concerned about possible unauthorized use by others who may have physical access to where the router is stored. Use SSL/TLS + User auth How can I do this with a voip phone I'm attaching via one of the ports on an sg-3100 that needs vpn'd access to a non-public phone switch?  I can certainly do openvpn connections with password protected certs - in fact this is what I use for my other remote access clients. I'd like to use the sg3100 to provide vpn services for other hardware that can't do vpn services for itself, and I'd like it to take a user supplied password for initial connection to prevent casual access by unauthorized people. At this point, I'm leaning toward password-saved-in-the-router ipsec vpn for JUST the voip phone and software (openvpn client) on the laptop. I was just hoping to find some way to do both with the hardware.  Thanks for your suggestions.

@techy82 That LAN rule you show a snip of, is there anything above that? If it works with the openvpn off then it really looks like an incorrect rule.

@Derelict: Make sure the inbound traffic is NOT matched by rules on the OpenVPN tab (disable all rules there) and IS matched by rules on the OVPN tab. That will get reply-to functioning. Removing the rules from the OpenVPN tab resolved the issue. Thanks!

Why would you want to do that?  that is just the shared secret.. Really no point in that being any higher.. https://community.openvpn.net/openvpn/wiki/Hardening that is the shared secret key, anything over 2048 is just pointless.. This is the key used to sign the tls packets..  Would be better to set your tls min to 1.2 and enable tls encryption… Keep in mind that the some clients do not support tls crypt - I do not believe the ios openvpn connect app as enabled its use yet, etc.  But really don't see how increasing that would matter..

@viragomann: Since you're directing the QNAP Traffic and also it's DDNS registration through the OpenVPN, it will register the public OpenVN IP in the myQNAPcloud DDNS. However, presumably your VPN provider doesn't forward access to you. So if you want the QNAP traffic to bypass the VPN and go over your WAN gateway, just add a firewall rule for the QNAP internal address as source to your LAN interface, allowing access to public addresses (or only to the myQNAPcloud DDNS) over the WAN gateway. You can select the gateway in the advanced options of the rule settings. Thank you, will give that a try.