Same Problem here

OpenVPN Server log:
openvpn[]: 91.xx.xx.xx:1194 TLS: Initial packet from [AF_INET]91.xx.xx.xx:1194, sid=81e8d10a
openvpn[]: 91.xx.xx.xx:1194 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
openvpn[]: 91.xx.xx.xx:1194 TLS Error: TLS handshake failed
openvpn[]: 91.xx.xx.xx:1194 SIGUSR1[soft,tls-error] received, client-instance restarting

Try the Securepoint OpenVPN client software, instead of using the OpenVPN Windows client.

@cmb:

OP bought support and I ended up working through this issue with him. Turned out the problem was a Windows server involved in routing was blocking the traffic.

CMB you rock brother! Thank you for the help and yes it was a damned Windows server that was blocking the RTP traffic from ports 10k-20k. Once i created a rule on the windows server it opened it all up and everything is rocking.

Thanks again!

Well as stated if your not redirecting your gateway and just handing out the routes to your networks then browser wouldn't use the vpn connection for IPs not behind the vpn.  Also if your browser is using a proxy could cause you the problem as well.

Have a look at the log from the client.

2015-06-18 15:54:03 EVENT: CONNECTION_TIMEOUT [ERR]
2015-06-18 15:54:03 EVENT: DISCONNECTED
2015-06-18 15:54:03 Raw stats on disconnect:
BYTES_IN : 13432
BYTES_OUT : 50104
PACKETS_IN : 76
PACKETS_OUT : 105
KEEPALIVE_TIMEOUT : 1
CONNECTION_TIMEOUT : 1
N_RECONNECT : 1
2015-06-18 15:54:03 Performance stats on disconnect:
CPU usage (microseconds): 446501
Network bytes per CPU second: 142297
Tunnel bytes per CPU second: 0
2015-06-18 15:54:03 EVENT: DISCONNECT_PENDING
2015-06-18 15:54:03 –--- OpenVPN Stop -----

It must already be running but somehow disconnected from the management socket.

If you look in the output from "ps uxawww" it is probably showing up there still.

If you manually kill the process and then restart it from the GUI it should work.

Sorry for the hijack.  After more reading through other threads in the CARP section, I think I will try a downgrade to something like 2.2 on each box.

Never gives one much confidence when things "just start working", but I hate to argue with success!

That said, I've had a few scenarios while debugging OpenVpn issues that required a "hard restart" of the OpenVPN server (find and kill the process or reboot the box).

If learned over the years to be a little more diligent with checking the OpenVPN changes I make to ensure they actually get applied when I think they do.

Glad you got it up and running.

I'm not expert enough on VM setups to pinpoint the issue with your setup.

Perhaps someone else will chime in or try in the VM section: https://forum.pfsense.org/index.php?board=37.0

aes-ni is supported but,currently, the advantage is minimal afaik.

the problem is that openvpn 2.3.X doesn't support aes-gcm (https://community.openvpn.net/openvpn/ticket/301)
once openvpn 2.4 gets released, this should be included and then we might be able to get the same speed increase like we have seen with IPSEC

thanks for the hint.
I don't find anything regarding advanced setting for logging. Would that be the advanced textbox on the openvpn settings page? (vpn_openvpn_server.php?act=edit&id=0)
That is empty.

I checked the conf in /var/etc and there is:

[2.2.2-RELEASE][admin@pfSense.localdomain]/root: grep verb /var/etc/openvpn/server1.conf verb 3

perhaps I overlook something? (still pfsense noob)

The PFSense wizard just rocked. The PFSense router could handle multiple connections if needed, easily.

Definitely, I run many routers with 3-6 Server/Client connections each (Site2Site and RoadWarrior).
My main router is currently hosting 6 Servers and 35+ client connections.

The hardware is only a 64bit AMD Athlon dual core 4800 w/ 3GB RAM
It typically runs at ~ 15% RAM and 12% CPU.

Not much bandwidth requirement 50/5, but still a very capable setup.

If they change their password using "passwd" or similar at the CLI, that does not change it in the pfSense configuration.

You can grant them a password change permission and then they can login to the GUI to change their own password.

Giving them shell access is fairly dangerous though. Keep in mind it's a firewall not a general purpose multi-user shell server.

And hence my "hours of work" remark.
I would not even know where to start. hosts-file, firewall rules, NAT-table?

I "know" a rulebased setup of some kind should work.

if bbc.co.uk use ovpnc1
if play.svt.se use ovpnc2
if netflix.com, hulu.com use ovpn3
else use WAN (em0)

I have 5 client connections included with my PIA subscription (I can use it on 5 machines).
So I'm thinking 5 regions on my pfSense box ;-)

I'm going to try unblock.us today and see how that goes.
This seems a bit easier.

But you have to agree that it's a good thought, and if anyone has a working example of this, I would love to pick your brain?

Thanks for your input, again.

@sparkynerd:

Thanks for the help so far- My setup is fairly simple:
Modem–>pfSense-->Router

While it should be

Modem (bridge mode) -> pfSense

and you'd have no issue like this with settings things in 3 different places.

@viragomann:

Configure your Android VPN client to use a public DNS server or set up the OpenVPN server to provide DNS servers to clients which are capable to resolve the hostnames.

Thanks for the reply.

I was using the OpenVPN connect and this did not have the option to change DNS (that i could see).

so i tried OpenVPN for Android and set google DNS - but same issue.

Any ideas?

Thanks for the nudges in the right direction.  verb 3 wasn't giving me the info I needed, so I went after verb 4 and finally got more granular logs in my openvpn.log file.

The first and big pointer was

ERROR: could not read Auth username from stdin

My auth-user-pass config didn't specify any txt file with the credentials in it, which makes me think the Synology's passing of the GUI entered credentials is fubar'd.  I commented the auth-user-pass config out, and of course, I got all sorts of TLS handshake errors. The connection requires a user/pass.

Connected as we speak as long as I pass the credentials as a file.

I really appreciate your help.  It says something when an OpenVPN thread in the Syno forum needs to be approved by a mod before it gets posted.  Lots of ambiguity on their front end presentation to a very robust VPN.

Just in case anybody else is sharing the same problem -

changing the unix socket in openvpn.inc to tcp socket solved my problem.

Update

Actually there was no privileges issue. The script could not execute the root commands because it couldn't recognize them.

I could fix the problem by specifying the full path to the commands. Examples:

/usr/local/sbin/bgpctl reload (using just 'bgpctl reload' inside the script wasn't working)

/sbin/route add -net $ifconfig_pool_remote_ip/30 -interface $dev -static

Now it works.