Not sure about ubuntu clients, but on Win7 were you running the client as Administrator? When connected, go to a CMD prompt, and type "route print" and see if you have a route to your home network that has an IP in the OpenVPN address pool as its gateway.

The client doesn't need dh parameters. As for the other problem, on the road warrior server config, in the custom options, put: push route 192.168.2.0 255.255.255.0; And then on the site2 client for site-to-site, in the custom options, put: route 10.0.0.0 255.255.255.0; The first part should tell the clients that they can reach site2 via the OpenVPN connection. The second part will tell site2 how to route back to the OpenVPN road warrior subnet.

and the other part of my config [image: 4.jpg] [image: 4.jpg_thumb] [image: 5.jpg] [image: 5.jpg_thumb] [image: 6.jpg] [image: 6.jpg_thumb] [image: 7.jpg] [image: 7.jpg_thumb]

A few simple tests could confirm this behavior, but I'm not sure offhand. I haven't tried this myself, but you could require having a CSC entry, and use the directive ccd-exclusive; In the custom options to enforce the requirement that a client exists on the CSC tab before they can connect. The OpenVPN man page doesn't really clarify whether or not the ifconfig-push directives for the CSC entries are taken into account during general pool assignment.

Thx i think i got it now. I ve changed Address pool to 10.0.8.0/24 (on servers side) an on client side Interface IP: to 10.0.8.0/24 and now i can ping from hosts on A site to host on B site. Now I am going to play with DNS. Thx once again.

It's resolved. There were two different problems. One was with Tunnelblick. I switched to a different VPN client on the Mac (Viscosity) which worked right away. The problem with the Windows PC was that I was using a different VPN config, who's alias was mistakingly being blocked from DNS via a firewall rule.

This was solved on IRC, I believe. He switched to using a real PKI setup (not shared key/PSK), and adding route/iroute statements as needed, and it started to work.

Never mind, I figured it out. It is base64 encoded, just without line breaks. I just removed all the line breaks from my encoded string.

I'm not sure how it goes on Windows, but on unix, you have to run a different program first that sets variables that makes sure it's reading all of the proper files and such.

Can you try some packet captures to see if the traffic makes it across the tunnel on tun0 and actually leaves (and re-enters) your LAN interface?

Never mind , i will skip the VPN settings for now

Thanks , it works , i was thinking i could just copy them  :- anyway thanks again , it solved the problem

Ok, I figured this out. I needed to configure the DNS forwarder to be authoritative for the blah.com domain. Also, on the same setup screen, I needed to set the local IP for server.blah.com. Now, I can use the fqdn if I am at the home office or on the road. I LOVE pfsense !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Your config isn't fine until you've made sure that the tunnel network (what I recommended to be 10.x.y.0/24) and the two office networks are all separate subnets. After that you need to make sure you have proper routes in place. On the server (office1) the remote network should be set to the subnet of office2 (192.168.3.0). On the client(office2) the remote network should be set to the subnet of office1 (192.168.0.0/24). If you need additional routes on top of those they should go to advanced options as "route subnet netmask" (e.g. "route 192.168.100.0 255.255.255"), push "route …" doesn't work in PSK mode, it's for PKI roadwarrior mode.

The available options change depending on the other options chosen. You probably need to use PKI instead of Shared Key

Starting with pfSense 1.2.3 you can assign the OpenVPN interface and you can do NAT and such on it. http://doc.pfsense.org/index.php/OpenVPN_Traffic_Filtering_on_1.2.3