TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

Usually means that there was no response from the remote end, which often is because the remote end is not reachable.

UDPv4 link remote: [AF_INET]10.0.2.15:1194

It is trying to reach a server that is in private IP address space. If this is a real link across the public internet, then you have got the setting of the remote address wrong.

Jim,

I got it.  We dont have that many users so I think we will use the certificates.
Thank you for taking the time.

H.

@Derelict:

It would be nice to be able to set defaults for client export in a particular vpn instance.  I understand this pretty much means incorporating client export into pfSense instead of it being a package, but it sure would be nice.

I raised a feature on Redmine a while ago: https://redmine.pfsense.org/issues/3478

There is nothing to stop the OpenVPN Client Export package from being able to save some default settings. I thought about doing it but have not got around to it. I want 2.2 to happen more than I want this  ;)

Sorry just worked it out, i thought you needed to download openvpn but pfsense comes already with openvpn i just needed to download the package "openvpn client export" to download the clients for my different devices

@Derelict:

System->User Manager->Servers

Of course is located there.
its the only place I didnt look  ;D

Thank you..

You might have to create three different OpenVPN Servers, each with it's own defined LDAP server with different authentication containers for your groups.

I don't think there's a way to pass group membership from LDAP into OpenVPN and change behavior, such as what traffic is allowed.

With three OpenVPN servers and assigned interfaces it'd be pretty easy.

Try adding this to your OpenVPN server:

reneg-sec 43200;

I believe I also put reneg-sec 0; in my client export so I can change it at the server and affect everyone the same.

I have reneg-sec 0; in my client specific overrides but I'm not sure it can be pushed like that.

Exchanging login credentials again is part of the renegotiation.  My Duo starts firing after an hour if I don't do this.  12 hours seems to be long enough to get me through every session.

This doesn't affect site-to-site since there's no manual 2-factor auth.

This did it for me :

Marked this in the OpenVPN conf :

Strict User /CN Matching : When authenticating users, enforce a match between common name of the client certificate and the username given at login.

I'm with jimp - the 2.2-BETA really has got out all the bugs I can think of in the parts I use. I also think that 2.2-RC will not need to live for long before an official release.

Happy to help.
The addresses checked in rules are the real source and destination addresses of the packets arriving on the interface, which often (usually) are not in the interface subnet itself.

This only gets "messed up" when there is NAT happening somewhere - if you are receiving packets that have been NATed somewhere by the sender then the source IP (destination when heading back to the NAT) will be whatever the NAT rewrote it to.

Ahh - Remote Networks is not displayed for that sort of "Road Warrior" server, because that sort of server is not designed to be routing from the server out to some client "office" subnet. The wizard gives all the fields to type in, I don't think it has script to hide/display various fields depending on the type of server you have picked.\

That reachability should be just a matter of checking that all routers along the way know routes to/from all the various subnets, and that firewalls along the way are permitting packets to/from those subnets.
On pfSense OpenVPN server:
Local Networks - put something like 192.168.1.0/24,192.168.15.0/24,10.10.0.0/16
OpenVPN firewall rules - pass all that stuff (and more if that is then the way to the whole internet), and pass 10.15.0.0/16 as it comes back from Linux OpenVPN server.

Linux OpenVPN server:
Tell it that the pfSense client has 192.168.1.0/24,192.168.15.0/24,10.15.0.0/16 (whatever those networks are) reachable behind it.
Pass all the relevant networks.

traceroute/tracert should be your friend - use that to/from parts of the network and see where the traffic is hopping, and where it is not returning. That will give clues about which hop has router or firewall issues.

There is no way to get it "ported".

The problem is a DoS only, so you could use the Service Watchdog to keep an eye on the server and restart it.

Sure it's possible for malware to target it, but it's highly unlikely for it to do so. And if you know the service stopped, you can check your logs and see who the last person was to connect before it died, revoke their certificate and then send some hired help to beat them up. Or do it personally. Your choice.

Or just upgrade to 2.2-RC when it drops shortly and stop worrying about it.

found out, wasnt a server certificate i used, this walkthrough works:

https://www.highlnk.com/2013/12/configuring-openvpn-on-pfsense/

Is there fix for 2.1.3 ? I've made TUN bridge but vpn gateway is down.

Glad I could be of help..