Got this resolved; apparently a FW rule was moved to a wrong position  ::)

1.2.3 is based on FreeBSD 7.2 Your OpenVPN is a port to FreeBSD 6.0. Either you're not really on 1.2.3 or something went terribly wrong when you updated.

@UnderCover: also note following the books example for site-to-site vpn with a shared key ther eis one step missing on the client side interface ip must be set: 172.31.55.0/30 the configuration file for openvpn client will not let you save anything until an interace ip is set on top of what the book mentions Thanks for catching that. We'll check into it and update the errata page if need be.

I just did the upgrade to 1.2.3.  The tun interface is assigned to opt1 setup the routes and works perfectly. Thanks again for the help.

When I tried it, the "address pool" was messed up.  It chose the same range for two clients and could not distinguish them.  I couldn't figure out a way to force the pool to a specific range for the two clients as the server has only one place to enter the pool and it must be the entire range. Just more stuff to figure out.  If it were easy anybody could do it – and they wouldn't need an overpriced curmudgeon like me! :P

Well well well. The same OpenVPN tunnel definitions that failed before work now.  All I did was update my home router to 1.2.3 RC3 (it was RC1 before).  It's starting to look like there is something amiss between RC1 and RC3 in OpenVPN implementations. Easy enough to fix, if you know about the problem…

got all sorted out. Thank you!

Bump  :) No one at all that can show me which rules they implemented to allow all traffic through the vpn tunnel and reject all other traffic?

Nov 23 11:32:33    openvpn[57852]: [Redacted]:31056 WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo' Nov 23 11:32:33    openvpn[57852]: [Redacted]:31056 WARNING: 'keysize' is used inconsistently, local='keysize 256', remote='keysize 128' Nov 23 11:32:33    openvpn[57852]: [Redacted]:31056 WARNING: 'cipher' is used inconsistently, local='cipher CAMELLIA-256-CBC', remote='cipher BF-CBC' Nov 23 11:32:33    openvpn[57852]: [Redacted]:31056 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1559', remote='link-mtu 1544' You have mismatched settings between client and server. Cipher (keysize is determined by choice of cipher) and lzo compression settings have to match exactly.

Two options: 1: Create a static route on the default gateway of your server 2: NAT from the OpenVPN subnet to the servers subnet. 1 is IMO the easier and more proper way.

Hi, if i understand you… What protocol did you specify on the server? AD: ldap OpenVPN Server: TCP The default is UDP, but i see you have TCP in your client config (which is a bad idea btw). In my fpsense in production, use TCP, the configuration you see is only for test in a virtual machine, but i take your suggestion Any idea? Regards

Funny thing is that I had this same error and solved it by switching from UDP to TCP.

Is there a method of turning my Lan Port to bridge mode to become apart of my neighboring subnet? Then potentially VPN connect through Wan to the Bridged network on the LAN side? thanks

Follow this howto: http://doc.pfsense.org/index.php/Using_OpenVPN_With_FreeRADIUS (except replace the RADIUS server on pfSense with your own RADIUS server)