Ok, site to site, PFsense on both ends, forget the iroute.  I don't see a route to the 192.168.10.x/24 network on your server…. that's why you can't get to the client-side.  Although, I do see a route to the 192.168.194.0/24 network.... which looks like the LAN on the client-side.... are you sure the client is on the 192.168.10.0/24 network?  Might want to double check... cause it doesn't look like it. Post your server1.conf and client1.conf. On the client-side, it looks like you're double NATing, so you'll have to either remove it or keep your static route in place (someone correct me if I'm wrong)

"TLS key negotiation failed to occur within 60 seconds" just means that it can't reach the server, or the server rejected it. Check the server log for OpenVPN and you may find the answer, or at least more info we can use to help. If that log shows nothing, then it is either a connectivity issue or a firewall rule issue.

@phil.davis: On his end, assign an interface to the OpenVPN site-to-site link. Leave the IPv4 type as "none" (the system will organise the existing IP of the OpenVPN link…). Then a gateway should appear that goes to the other end of the site-to-site link. Add a firewall rile on his LAN selecting the relevant source IP, destination all, and in the advanced section select the gateway for the site-to-site link. At your end you probably need to: a) make sure the OpenVPN link has a pass rule allowing the special source IP, destination any. b) NAT the traffic from him heading to the internet (automatic outbound NAT is only going to do it for traffic from your LAN to WAN) Others, what have I forgotten? This did the trick! Makes sense now. I think I was making it out to be a little more complex than it turned out to be. Thanks for the info!

galgier, v1.5.5 is a version of OpenVPN Access Server, which PFsense does not use.

Glad it's working.  It looks like you're using split tunnel, so my thought was it had to be on the client end, but you're also double NATing and using port 443 instead of 1194… that probably has something to do with it. Also, I'm curious to know why you're pushing out google DNS with a split tunnel deployment.

Thanks for the reply.  I ended up figuring out that a UAC permission was blocking the installation. FYI for anyone else running into this problem that has all UAC's turned on, disable only these two: User Account Control: Detect application installations and prompt for elevation User Account Control: Only elevate executables that are signed and validated I'm not sure exactly which one did the trick because even after forcing policy updates it still took a while for some replication, but I know for a fact that with these two disabled I am now able to install any application. Justin

started over from scratch and got it to work by making sure all of my port forwarding worked before I configured openvpn access.

OK, update on this. Applied all windows updates (there were about 80) and now it seems to work. Would be good/interessting to know wich KB that did solve this (if any? magical things have happened before). Will try on another client when possible.

I don't know what you have now as your office router, but if it is not pfSense already, then I would replace it with pfSense. Then you have 1 router that can do it all easily. If you put a separate pfSense router in your office LAN somewhere, then you will have to add static route/s to your office router telling it about the pfSense and what subnets are reached through that. Also, I would change 192.168.0.0/24 at home to some other less popular private subnet - e.g. use something in 10.0.0.0/8. That will avoid pain when you take your laptop to a cafe that uses 192.168.0.0/24 and try to VPN back home.

Thank you for your feedback :)

Hi, just to make sure what you have: You have one WAN connection and one (or more) LAN connections? Some traffic from LAN to the internet should go through the VPN and other should go through your origin WAN, right? It could be usefull to see your firewall LAN rules and if you have really PortForwarding enabled then the firewall rules on your WAN interface - at least for the PortForwarding rule.

I deactivate the windows firewall and the AVAST firewall. Best regards Thierry

@NOYB: Does not prevent account from WebConfigurator login.  Just restricts access to WebConfigurator pages. Check cmb's post…  that was exactly my point.... don't put them in group that has access. Only works for OpenVPN connection access. You can put those rules on any interface. Not difficult to find the changed and non disclosed WebConfigurator port. So, change it and install firewall rules to harden access.  Not difficult to keep people out with firewall rules.

I was able to figure out a script to replicate the behavior that occurs when the save button is clicked on the client.  This is a little bash script for those who need to restart a client cleanly (i lose 1 ping during the restart).  Save this as a .sh file, chmod +x that file and add it to cron or trigger it however you would like.  I'd like to somehow trigger this by an Apinger Down event, but I don't know how to do that.  Can anyone help with that? #Determine the PID of the running client (assumes there is only one) clientpid=$(pgrep -lf /openvpn/client | awk '{print $1}') #Collect path of openvpn and client openvpnpath=$(pgrep -lf /openvpn/client | awk '{print $2}') clientpath=$(pgrep -lf /openvpn/client | awk '{print $4}') #Kill client process kill $clientpid sleep 2 #Restart the Client $openvpnpath --config $clientpath

If both sites run PFsense, why are you doing Road Warrior and not Site to Site?

That looks like a certificate verification error, so something in the CA/Cert doesn't match or isn't right between the client and server, or it's invalid in some other way.