Thanks for pointing this out. Manually adding pfSense address to the resolv.conf did the trick. As mentioned in the thread you posted a simple trick should be able to do that automatically.

Thanks again.
alphazo

Nice.. thank you very much. When I put 192.168.100.8/30 in the client config, I was able to set filtering rules for the IP 192.168.100.9.

IT WORKS !!!

I don't know the WHY details, but it works.
what I did ?
    First, I upgraded to 1.2.3 release nanobsd on both sides.
    Since there was messages in the log saying there was an error trying to add the routes in my custom options, I tryed first to remove all routes in custom options to see what append !  The result is that it works without any custom option anywhere!

From both sides, I can take control of PC on other side (ultravnc) by using their respective IP addresses (192.168.0.* or 192.168.1.*)

And now I have to do the bridging stuff, just waiting for the tutorial to be updated.

PS:    By the way, I discovered that the firewall in windows XP SP3 prevents the PC to respond to pings if activated. silly thing :)

Patrice

@GruensFroeschli:

I'm not sure if this works with a bridged setup.
You could use the command:
redirect-gateway def1

Hmmm.
Just read up a bit on the openVPN man-pages:
http://openvpn.net/index.php/open-source/documentation/manuals/65-openvpn-20x-manpage.html

It seems redirect-gateway def1 really doesnt work with a bridge.
But you have to option to use
push "route-gateway x.x.x.x"

Thanks,  I'll try the push "route-gateway x.x.x.x".  I should just add it to the "extra options" area on the OpenVPN page?

I'll let you know if it works.

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