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

I have had the same experience as jimp and Cry have said. The only time I've ever had to use route-delay is because ICS was configured on the machine. Is this perhaps the case for you?

Thanks everyone.

I tried again on a fresh install with a different scenario. Still does not function as I want. Also use the same configuration file generated by pfSense to the OpenVPN server on a machine with CentOS linux and got the same result.

I will spend time reading the documentation for OpenVPN again.

Greetings and thanks again for responding.

Thank you very much. That solved the problem with the script!
I do not know why I thought that script-security was a server parameter.

Great!  That did the trick.

Now to figure out my other issues, but I'll post another thread if I get really stuck.

Thanks a bunch for your help.

@jimp:

That outbound NAT rule goes on WAN, not OPT2.

Thank you; it's transferring data now!  I'll put on a packet sniffer so I can see with my own eyes that data and DNS are both encrypted, but at this juncture I'm quite pleased.

I do appreciate your very quick and entirely correct response; I'm sorry I wasted your time.  Is there a wiki I can document this at, so others can find the right information more easily?

For anyone else going through this, the final configuration:
Current major setup:
Client: Windows XP, OpenVPN 2.1.1 with OpenVPN GUI 1.0.3
Netgate ALIX board with pfSense 1.2.3-RELEASE installed.
 LAN (192.168.1.13/27) ethernet goes nowhere, or to a computer for logging into the web interface.
  WAN (xxx.yyy.zzz.qqq/24) ethernet goes to the cablemodem (which is set for static IP use)
    WAN gateway xxx.yyy.zzz.nnn
 OPT1 (192.168.1.113/27) goes to wireless
   OPT1 is not bridged
   OPT1 gateway is blank
   OPT1 is set as an Access Point, WPA2 only, Pre-shared-key, Open System Auth, and works fine right now.
 OPT2 (192.168.2.1/24) goes to tun0, the OpenVPN
   OPT2 general config is Type Static
   OPT2 is not bridged
   OPT2 gateway is blank
 VPN OpenVPN is set up as "Server"
   VPN Protocol UDP
   VPN Dynamic IP unchecked
   VPN Local Port 1194
   VPN Address Pool 192.168.2.0/24
   VPN Use Static IPs is not checked
   VPN Local Network is blank
   VPN Authentication method is PKI
   VPN Custom Options:
     push "redirect-gateway def1"
 Firewall - based on a forum search here, I set:
   NAT - Outbound to Manual mode, and added
     NAT Outbound Interface WAN    Source 192.168.2.0/24 * * * * * NO
     NAT Outbound Interface WAN    Source 192.168.1.0/27 * * * * * NO  - Auto created rule for LAN (matches .13/27)
     *** nothing for 192.168.1.96/27, the OPT1 Wireless IP range, because I deliberately want to force all wireless to use VPN.
   Rules - OPT2
     Block TCP/UDP * * to destination (all firewall IP's, ports 80 and 443 - to prevent vpn clients form accessing WebGUI)
     ALLOW TCP from * * to destination * ports 80 and 443 gateway *

Ok, I have fixed that up as well.  Thanks for all your help!

I was testing openvpn on Pfsense, yesterday and stumbled across you post….
I had previously worked with Openvpn using the Openvpn how-to which specifies using .crt, .key, and dh.pem files

Like you, I was not sure how to use certs generated by IPCOP on pfsense openvpn....

It turned out that I was able to past the IPCOP PEM files into the PFSense openvpn config (I had wondered if I needed to convert to .crt file)
Then I was able to use the downloaded IPCOP client package as it was.
There was no need to convert pk12 to pem or crt.

After some reading i turned off captive portal… and now it works :)

Allthough captive portal is a nice feature im woundering if its supposed to behave this way or if its a bug?
Kinda want both openvpn > lan and captive portal to work.