@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)

@GruensFroeschli:

Are you sure about this?

Yes i am sure.
Your setup is the classic stumbling block if you're not really familiar with routing.

I just tried the manual nat as well, but it didnt change anything Sad

Please describe a little more detailed what you did.
Can you show a screenshot of your AoN rules?

Hi there, i just got it to work :) The NAT rule i added yesterday had the subnets configured. Now  just tried adding a new NAT rule for the vpn interface and any subnet, now everything works :)

thanks for your support :)

It's up and running.  I scrapped what I had correlated my subnets to the ones in the sticky you mentioned and followed it step by step.

Thank you so much for your help!

To be blunt, I think you need to bring in somebody with more experience than you have.  If DNS didn't work then you wouldn't be able to map the share.  From what you've said it all sounds like an authentication problem.  When you map the share across the VPN:

a) Is the remote device on the domain?
b) Are you providing a username and password?