Thank you  jimp … I will test it....

The OpenVPN config files look reasonable. You do not mention firewall rules - what rules do you have to allow traffic into pfSense end OpenVPN? And same for Windows Server firewalling (however you do that using OpenVPN client on Windows Server).

I never did update this post…. everything is working well. Thanks, jimp!

I had a full clean install Windows8 on an old HP laptop (from Vista days - worth $US40 to get rid of Vista. At some point it started intermittently refusing to connect to my home WiFi - a reboot would (usually) get it going again. After online upgrade to 8.1 I haven't had the problem again. Maybe some dodgy Windows Update in the Win8 series? that was fixed in 8.1? YMMV - mine certainly has. But when the underlying connections are up, OpenVPN client has been doing its thing fine.

You have to put the subnet at the other end in IPv4 Remote Network/s field on both server and client - then it will make a route across the OpenVPN tunnel to the subnet at the other end.

Switched to using TCP instead of UDP and the tunnel came up OK.

The usual fix on Windows 8 is to uninstall both the OpenVPN client and the TAP driver and then install them again. There are other weird things that can happen with OpenVPN on Windows 8 but thankfully I haven't hit any of them so far. https://community.openvpn.net/openvpn/ticket/316 Step 13 here: http://www.vpntutorials.com/tutorials/openvpn-client-setup-tutorial-for-windows-8/

Until I set the client LAN to use MultiWAN by setting the Pass any any rule to use a gateway group. That rule now pushes all traffic to the highest tier member interface(s) of the gateway group. The packets are not given to the normal routing table. Add a rule above that to pass traffic with destination 172.22.81.0/24 and no gateway group. Then those packets will be passed to the ordinary routing, and will find their way through the OpenVPN tunnel. I can fix this by adding: Client OpenVPN: IPv4 Remote Network/s: 172.22.81.0/24 I don't understand why that works for you - the client end OpenVPN routing settings should still end up just in the ordinary routing table and have the same issues as doing it in the server-end settings.

Hi jimp, thanks for your reply. I went to the Diagnostics > Backup/Restore tab you told me, and made a diff between the current configuration and an older one about the time when I deleted the certificate in question. That helped me to locate the "" fragment with the certificates I need. I managed to import the certificate and private key, and to put them in revocation. Guess that's it, I'm marking this topic solved. Thank you! :) UPDATE: It appears that the user is able to connect despite that. Any clues why? UPDATE2: I rechecked my settings again and found that I overlooked the "Peer Certificate Revocation List" in the "Cryptographic Settings" section of OpenVPN settings (VPN->OpenVPN->edit the network in question). It was set to "none" instead of my revocation list. Changed that and now revocation is working perfectly. Thank you again :)

If you can make a separate OPTn local subnet then you can put the NAS in that (and even use the actual subnet that the NAS will finally sit in at the remote end). That way the NAS should first see the route back to your LAN advertised through the tunnel and use that, rather than going locally straight to pfSense on OPTn. You are going to have to change the NAS IP anyway when you send it, so this way you can change it and test that also. When finished testing, cleanup your OPTn or you might run into some other confusion when the NAS really does connect from the remote site. An added question: Does this configuration have any issues? You are effectively putting the remote NAS as a device on your (logical) private internal network. It is just the same as having it in a different real subnet on an interface on your local pfSense. You can use firewall rules to restrict which local LAN IPs can even reach the remote NAS IP. Of course, at the remote location the NAS is going to have a local IP there, which it uses to establish the OpenVPN tunnel back to you. I guess you can restrict local access to the FreeNAS box however you like from FreeNAS. But someone is going to have physical hardware/console access at the remote site and so you have all those things that require the remote site also be physically secure.

Thanks phil. I enjoy working through it. Best of luck for the new year.  8)

Damn… that was it.  Forgot to copy the TLS key from one to the other.  Works like a champ! You are correct the connection tags are not necessary, they do come in handy if you need to set a proxy for just one of the remote entries though.  So I leave them there. Thanks jimp!

uninstall the client and tap driver, then reinstall making sure to use the latest client. Odds are, you have the 2.2.x OpenVPN windows client installed and not 2.3, so the verify-x509-name parameter is tripping it up.

Thank you very much. I'm not much of a networking tech ;) Problem solved. /Peter @heper: did you notice the "Redirect Gateway' checkbox in your server config ? Force all client generated traffic through the tunnel.

route 10.10.20.0 255.255.255.0; push "route 10.10.20.0 255.255.255.0; You don't need (or want) both statements, because it might one day mess something up at the other end, your client trying to push the route to the server at the other end. I think you just want at the client: route 10.10.20.0 255.255.255.0; which tells the client itself that this VPN is a route to 10.10.20.0/24 You should also be able to add 10.10.20.0/24 to the Local Network/s field at the server end - and that information will be pushed from the server to each client, so they get to know the server is a route to 10.10.20.0/24. That way removes any need to use the Advanced box. But if it's working and you don't want to risk breaking it, then leave it as is!

I would like to give it a try. Currently i run TorGuard with dd-wrt on an old router.

Phil, I really don't know what happened but since I rebooted, it now works! Sorry for the waste of time! Regards