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

Hello, sorry for my late reply, Christmas time was a bit hectic :( Thanks again and you were right again. There was a policy based routing rule I didnt thinkt about, something like this: iptables -t mangle -A PREROUTING -s 10.0.0.0/24 -j MARK –set-mark 2 And I set anoher one which solved the issue: iptables -t mangle -A PREROUTING -d 192.168.1.0/24 -j MARK --set-mark 1 But now I have nother problem :/ I read myself into why I should use tun instead of tap and not bridging, because like you said it would produce lots of broadcast traffic for example. So I changed my server config to this: config 'openvpn' 'lan' option 'enable' '1' option 'port' '1194' option 'proto' 'udp' option 'dev' 'tun2' option 'ca' '/etc/easy-rsa/keys/ca.crt' option 'cert' '/etc/easy-rsa/keys/server.crt' option 'key' '/etc/easy-rsa/keys/server.key' option 'dh' '/etc/easy-rsa/keys/dh2048.pem' #option 'ifconfig_pool_persist' '/tmp/ipp.txt' #option 'ifconfig-pool' '10.8.0.2 10.8.0.10 255.255.255.0' option 'keepalive' '10 120' option 'comp_lzo' '0' option 'persist_key' '1' option 'persist_tun' '1' option 'status' '/tmp/openvpn-status.log' option 'verb' '3' #option 'server_bridge' '192.168.1.1 255.255.255.0 192.168.1.200 192.168.1.205' option server "10.8.0.0 255.255.255.0" list push "route 192.168.1.0 255.255.255.0" But again I cant get it to work, and it's even worse now than before with the bridging, where in the end I got it to work. First confusing thing is that it shows this on the client: tun2      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00           inet addr:10.8.0.6  P-t-P:10.8.0.5  Mask:255.255.255.255 And on the server: tun2      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00           inet addr:10.8.0.1  P-t-P:10.8.0.2  Mask:255.255.255.255 Why two adresses for each? and why does the client get 6 (and 5?) and not 2? Also I cant even ping from side to side from the client to the server. My routing table looks a little bit weird too: Kernel IP routing table Destination    Gateway        Genmask        Flags Metric Ref    Use Iface default        10.0.1.1        0.0.0.0        UG    0      0        0 eth1 10.0.0.0        *              255.255.255.0  U    0      0        0 br-lan 10.0.1.0        *              255.255.255.0  U    0      0        0 eth1 10.8.0.1        10.8.0.5        255.255.255.255 UGH  0      0        0 tun2 10.8.0.5        *              255.255.255.255 UH    0      0        0 tun2 172.20.16.0    *              255.255.248.0  U    0      0        0 tun0 172.20.24.0    *              255.255.248.0  U    0      0        0 tun1 192.168.1.0    10.8.0.5        255.255.255.0  UG    0      0        0 tun2 And on the server: Kernel IP routing table Destination    Gateway        Genmask        Flags Metric Ref    Use Iface default        188-194-- 0.0.0.0        UG    0      0        0 eth1 10.8.0.0        10.8.0.2        255.255.255.0  UG    0      0        0 tun2 10.8.0.2        *              255.255.255.255 UH    0      0        0 tun2 172.20.24.0    *              255.255.248.0  U    0      0        0 tun1 172.20.24.0    *              255.255.248.0  U    0      0        0 tun0 188.194.*.0  *              255.255.255.0  U    0      0        0 eth1 192.168.1.0    *              255.255.255.0  U    0      0        0 br-lan

Hey Phil! Thank you for your response, I always appreciate your help. I didn't find the address in /cf/conf/config.xml but I believe it came from the cache of my ISP which kept this address that I used as a proxy/gateway a few days before! (It may have been kept in my adsl box cache, or remotely in my ISP proxy cache). I turned my box off for a few hours and now everything's back to normal! BTW I am a Unicef donator. Regards, Dennis http://www.unicef.org https://www.eff.org

Look at this post - http://forum.pfsense.org/index.php/topic,70683.0.html - it is a very similar thing. In your OpenVPN server you need to add the friend's subnet(s) in Local Network/s, then the OpenVPN client will be told that the OpenVPN is a route to those places. On your friend's system you will also need to tell it that the IPsec VPN back to your house is also a route to your OpenVPN tunnel subnet. And add rule(s) on the relevant interfaces to allow the traffic.

I believe chroot isn't an option because of the script we need to run for auth to work and other tasks, but I may be wrong on that. Certainly worth testing if someone wants to try it. The user/group set might be viable, but may also have script issues or route addition issues. Also worth trying, but may or may not work.