From my reading "HO Router" is now an ASDL router on a phone line dedicated to this test. I do this in quite a few places, happily port forwarding my OpenVPN server listening port from the ADSL router to the pfSense behind it (HO pfSense in your chain of connections). As long as all the following are correct, it will work:
a) You know the correct public IP of the ADSL router (e.g. you have Dynamic DNS set up on HO pfSense and that will set DNS name on the public internet to point to the current public IP that pfSense sees through the ADSL router.
b) The client is using the correct DNS name (no typos:) or IP address.
c) the server end pfSense and ADSL router are talking - that will be obvious if the server end pfSense client/s can browse the net)
d) The ADSL router has a port forward for the correct port, to the pfSense WAN IP
e) firewall rule on server end pfSense WAN to allow incoming on the server listening port, with the correct protocol (e.g. UDP), or all protocols.
f) server is listening on WAN on that port.
Double-check everything yourself, then if you can't spot the problem, post server1.conf and client1.conf plus firewall rules on WAN, relevant screenshots of the ADSL router settings and IP addresses and subnet masks of everything. As this is entirely a test link now, it should be no problem to post this stuff, then we can help spot the missing thing.

You can't port forward across an OpenVPN tunnel on pfSense 2.0.x.

It can be done on pfSense 2.1. On the target side, you need to have the OpenVPN interface assigned and enabled (IP type of 'none') and have the firewall rules to pass in the traffic on the interface tab for the VPN and *not* the 'openvpn' tab -- that tab should not have any rules to match the traffic.

The reason that works is, when assigned, the VPN gets an automatic gateway. And on 2.1, rules on the assigned VPN interface will have reply-to added to send the traffic back out the VPN when it comes in that way.

Without reply-to, the packets go from the source side to the target side across the VPN, but the replies go back out the WAN rather than flowing back through the VPN.

@ahuser - you will need 2.1 at the home end (the "target side" in Jim's comments above). It needs the reply-to at your home end to send the packets back across the OpenVPN. 2.1 works great for me with OpenVPN links, so IMHO a home office upgrade to 2.1-RC0 is low-risk.

On my systems, the Default Auto Update URLs dropdown does not show 2.1-RC. It only shows the usual "stable updates" and "2.1 Development" options. I thought that the dropdown list is built at run-time from an online source, so should do its thing automatically. Am I missing something or?

Yep, an image with 2 bootable partitions (plus a partition for the config) is written. So you can even go back and forth if an upgrade is troublesome.
Instructions here: http://doc.pfsense.org/index.php/HOWTO_Install_pfSense

Do you get anything in logs on the HO server end? Check that you have a firewall rule on the HO WAN to allow the connection, and I guess you have port-forwarded 1194 from the production HO router to your pfSense HO test router, and that the port on the production HO router is not blocked...
Post a diagram of all the hops in your network, OpenVPN config at each end and firewall rules...

a) Point Windows Server DNS to the pfSense as its upstream DNS server. Both mydomain.com and public names will all be passed up to pfSense, and the pfSense DNS forwarder will answer or on-forward as needed. That is what I do. ; or
b) Point Windows Server DNS to an external DNS (OpenDNS, google, your ISP...) as its upstream DNS server. Add a conditional forwarder that refers ad.mydomain.com to the pfSense LAN IP.

I think this will work:
a) Use Interfaces->Assign to make an actual interface for the OpenVPN client.
b) Add a gateway on that OpennVPN interface, pointing at the IP at the other end of the tunnel network.
c) Add a policy-routing rule on LAN2, source 192.168.8.0/24, destination !192.168.1.0/24, gateway from step b.
The policy route should be in effect all the time, so that traffic will never go to the default gateway - but test that with the OpenVPN down.
Also, I have a feeling that some of this might be for 2.1 - I haven't done this stuff on 2.0.n for a long time.

Quick question on nanoBSD before this thread dies. Can I install all the heavy packages with no logging.. like Snort, Squid (null cache config), Dans..etc and still be able to run everything ?

Yes, as long as the system has enough real memory.
e.g. Alix 2D13 with only 256MB is not enough - when interfaces go up/down, events happen that cause check_reload_status to do a bunch of stuff and the system needs enough spare memory to run a few extra processes, so you can't keep installing packages to fill up 90% of the real memory.
I suspect that 512MB might also prove to be insufficient for the above packages, which rules out the 512MB memory Soekris low-power boxes. Please comment if you have experience of that.
I am hoping that the new Alix board for 2013 will be an option soon - http://forum.pfsense.org/index.php/topic,59555.0.html

On nanoBSD CF-card systems, bandwidthd now stores all its data in /var/bandwidthd on the memory-disk. So the CF card remains read-only. When you reboot the bandwidthd data goes in the bit-bucket.
I was intending to add an option to save that data to the CF card at a user-specified interval (like you can do for RRD dat) and reload it during startup, but I have been busy with other upgrades/installs of non-pfSense stuff, so haven't got around to it. If anyone else wants to work on that, feel free to submit on GitHub

It sounds like the WAN and LAN are connected together on one single layer-2 network. And that you have WAN and LAN subnets the same - 10.0.0.0/24. The LAN client is probably getting DHCP from the ADSL gateway, rather than pfSense.
1) Make your LAN subnet different from the WAN subnet.
2) If you have 2 NICs in your pfSense hardware, then connect the ADSL gateway directly to 1 NIC and use that as WAN, completely separate from the VLAN stuff;
otherwise you have to configure the VLAN switch, and use a VLAN for WAN devices and separate VLAN for LAN devices, with pfSense trunk port between them. That way a DHCP request from pfSense WAN is only seen by the ADSL gateway, and a DHCP request from a LAN device is only seen by the pfSense virtual LAN interface.

If 10.2.1.199 has a subnet mask 255.0.0.0 in it (/8 from the past) then it will think that the OpenVPN tunnel is part of the /8 and will expect it to be on the LAN,  which it is not. Hopefully it is just simply fixing up the subnet mask on the unpingable machines to use /9.

As long as you put the right networks in Local Network and Remote Network (and they are the correct way around from the point of view of the end you are at), OpenVPN will add routes for you. Use Diagnostics->Routes to see what routes you have at each end.
And I just noticed your rules are TCP+UDP only - for ping you will need to allow ICMP. The easy way is to change the TCP+UDP to any, then any other more obscure IP protocols can also pass.

LAN subnet behind the server - 10.0.0.0/8 for you
Typically pick something unlikely to be used in someone's home or cafe - 10.111.222.0/24

I just noticed an inconsistency in the example subnets I posted. If you really are going to use 10.0.0.0/8 as your LAN, then it uses the whole "10" address space. You have to use something else for your tunnel subnet - e.g. 192.168.157.0/24 - (pick a "random" number in the upper range of 0-255 for "157").
Of course, there is usually no need to have that much address space on LAN - make it 10.0.0.0/16 - then you can use 10.1.0.0, 10.2.0.0 etc... for other purposes.

Ok, a further question, I have set up the connection according to your hint, I got rid of the tls handshake
problem but I cannot reach any host in the 10.0.0.0/8 network.
where is my problem here ?

You need firewall rules on the OpenVPN tab to allow traffic - e.g. allow all source IP any, destination network 10.0.0.0/8. (Edit: fixed 10.0.0.0/8 typo here)

Exactly what is the LAN-side network?
You have 10.0.0.0/9 in your standard routing table, so I guess there is just 1 big flat LAN hanging off the pfSense LAN interface.
But then in your server conf file:

Code:

push "route 10.2.1.0 255.255.255.0"
push "route 10.0.0.0 255.255.255.0"
push "route 10.1.0.0 255.255.255.0"

You only push routes to little pieces of the 10.0.0.0/9
What LAN IPs do not ping from across the OpenVPN?

*** Welcome to pfSense 2.1-BETA1-pfSense (i386) on gw ***

 WAN1 (wan)      -> sk0        -> v4/DHCP4: 72.197.240.138/22
 LAN (lan)       -> sk1        ->

Now that I read this thread, I did have a case a few days ago when a system had lost its static LAN IP. The banner output on the console was just like the above. I ended up rebooting to get it back.
Maybe my change to /etc/rc.linkup at https://github.com/pfsense/pfsense/commit/8e47f55b6ec58fa287b9cfb0815aa47ff9d4b069 has caused a problem with hotplug events on LAN. The change does make interface_configure do more stuff when a physical interface comes up again - that will be causing the "updating dyndns lan" messages (even though it will find no dyndns entries using LAN). It would be worth reversing the "true" to "false" from that GitHub diff and seeing if it helps you. Then we can look at what is special about a LAN hotplug event that needs handling better in interface_configure.

On the physical side, why are the hotplug events happening "randomly" in the first place? Is a switch on the LAN side having short power cycling, or???