Solved  :P

I must be blind to not see it before. But maybe my blindeness may be helpful to someone with similar case:
The directive 'iroute' (the one stored in common name file of client in) was not loaded by OpenVPN daemon.
That's why routing was working until virtual adapter of remote box. OpenVPN simply did not know how to route to physical Adapter on remote LAN.

The reason was that first letter of the common name (taken from cert) was uppercase - and the filename displayed was whole lower case.

No i mean you should in the field: "custom options" on the openVPN config page add two commands along the lines of:

route 192.168.1.0 255.255.255.0; route 192.168.150.0 255.255.255.0

(add this only on the "right side" in your diagram)

Read the openVPN documentation on http://openVPN.net on how routes are being added and removed on linkup and linkdown of the tunnel

Now I have rebooted Windows server 2003 and I have this:

Sun Apr 26 13:10:13 2009 us=126730 PUSH: Received control message: 'PUSH_REPLY,route 192.168.1.0 255.255.255.0,route 192.168.200.1,ping 10,ping-restart 60,ifconfig 192.168.200.6 192.168.200.5'
Sun Apr 26 13:10:13 2009 us=126819 OPTIONS IMPORT: timers and/or timeouts modified
Sun Apr 26 13:10:13 2009 us=126836 OPTIONS IMPORT: –ifconfig/up options modified
Sun Apr 26 13:10:13 2009 us=126849 OPTIONS IMPORT: route options modified
Sun Apr 26 13:10:13 2009 us=261435 TAP-WIN32 device [OPENVPN] opened: \.\Global{933562DC-7552-4E46-9CB0-D438512717F5}.tap
Sun Apr 26 13:10:13 2009 us=261499 TAP-Win32 Driver Version 8.4
Sun Apr 26 13:10:13 2009 us=261517 TAP-Win32 MTU=1500
Sun Apr 26 13:10:13 2009 us=261544 Notified TAP-Win32 driver to set a DHCP IP/netmask of 192.168.200.6/255.255.255.252 on interface {933562DC-7552-4E46-9CB0-D438512717F5} [DHCP-serv: 192.168.200.5, lease-time: 31536000]
Sun Apr 26 13:10:13 2009 us=262281 Successful ARP Flush on interface [2] {933562DC-7552-4E46-9CB0-D438512717F5}
Sun Apr 26 13:10:13 2009 us=263469 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Sun Apr 26 13:10:13 2009 us=263489 Route: Waiting for TUN/TAP interface to come up…
Sun Apr 26 13:10:14 2009 us=376652 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Sun Apr 26 13:10:14 2009 us=376694 Route: Waiting for TUN/TAP interface to come up...
Sun Apr 26 13:10:15 2009 us=501623 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Sun Apr 26 13:10:15 2009 us=501667 Route: Waiting for TUN/TAP interface to come up...
Sun Apr 26 13:10:16 2009 us=626626 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Sun Apr 26 13:10:16 2009 us=626669 Route: Waiting for TUN/TAP interface to come up...
Sun Apr 26 13:10:17 2009 us=751744 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Sun Apr 26 13:10:17 2009 us=751788 Route: Waiting for TUN/TAP interface to come up...
Sun Apr 26 13:10:18 2009 us=883471 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Sun Apr 26 13:10:18 2009 us=883512 Route: Waiting for TUN/TAP interface to come up...
Sun Apr 26 13:10:20 2009 us=1604 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Sun Apr 26 13:10:20 2009 us=1649 Route: Waiting for TUN/TAP interface to come up...
Sun Apr 26 13:10:21 2009 us=127135 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Sun Apr 26 13:10:21 2009 us=127184 Route: Waiting for TUN/TAP interface to come up...
Sun Apr 26 13:10:22 2009 us=376649 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Sun Apr 26 13:10:22 2009 us=376813 Route: Waiting for TUN/TAP interface to come up...
Sun Apr 26 13:10:23 2009 us=324641 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Sun Apr 26 13:10:23 2009 us=324694 Route: Waiting for TUN/TAP interface to come up...
Sun Apr 26 13:10:24 2009 us=564152 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Sun Apr 26 13:10:24 2009 us=564204 Route: Waiting for TUN/TAP interface to come up...
Sun Apr 26 13:10:25 2009 us=814132 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Sun Apr 26 13:10:25 2009 us=814183 Route: Waiting for TUN/TAP interface to come up...
Sun Apr 26 13:10:27 2009 us=64137 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Sun Apr 26 13:10:27 2009 us=64187 Route: Waiting for TUN/TAP interface to come up...
Sun Apr 26 13:10:28 2009 us=340006 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Sun Apr 26 13:10:28 2009 us=340057 Route: Waiting for TUN/TAP interface to come up...
Sun Apr 26 13:10:29 2009 us=579819 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Sun Apr 26 13:10:29 2009 us=579859 Route: Waiting for TUN/TAP interface to come up...
Sun Apr 26 13:10:30 2009 us=829821 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Sun Apr 26 13:10:30 2009 us=829874 Route: Waiting for TUN/TAP interface to come up...
Sun Apr 26 13:10:31 2009 us=970398 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Sun Apr 26 13:10:31 2009 us=970448 Route: Waiting for TUN/TAP interface to come up...
Sun Apr 26 13:10:33 2009 us=111046 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Sun Apr 26 13:10:33 2009 us=111099 Route: Waiting for TUN/TAP interface to come up...
Sun Apr 26 13:10:34 2009 us=251700 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Sun Apr 26 13:10:34 2009 us=251754 Route: Waiting for TUN/TAP interface to come up...
Sun Apr 26 13:10:35 2009 us=392271 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Sun Apr 26 13:10:35 2009 us=392323 Route: Waiting for TUN/TAP interface to come up...
Sun Apr 26 13:10:36 2009 us=532823 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Sun Apr 26 13:10:36 2009 us=532871 Route: Waiting for TUN/TAP interface to come up...
Sun Apr 26 13:10:37 2009 us=674250 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Sun Apr 26 13:10:37 2009 us=674299 Route: Waiting for TUN/TAP interface to come up...
Sun Apr 26 13:10:38 2009 us=814116 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Sun Apr 26 13:10:38 2009 us=814162 Route: Waiting for TUN/TAP interface to come up...
Sun Apr 26 13:10:39 2009 us=954733 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Sun Apr 26 13:10:39 2009 us=954788 Route: Waiting for TUN/TAP interface to come up...
Sun Apr 26 13:10:41 2009 us=95387 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Sun Apr 26 13:10:41 2009 us=95445 Route: Waiting for TUN/TAP interface to come up...
Sun Apr 26 13:10:42 2009 us=142249 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Sun Apr 26 13:10:42 2009 us=142308 Route: Waiting for TUN/TAP interface to come up...
Sun Apr 26 13:10:43 2009 us=189139 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Sun Apr 26 13:10:43 2009 us=189209 route ADD 192.168.1.0 MASK 255.255.255.0 192.168.200.5
Sun Apr 26 13:10:43 2009 us=189683 Warning: route gateway is not reachable on any active network adapters: 192.168.200.5
Sun Apr 26 13:10:43 2009 us=189702 Route addition via IPAPI failed
Sun Apr 26 13:10:43 2009 us=189719 route ADD 192.168.200.1 MASK 255.255.255.255 192.168.200.5
Sun Apr 26 13:10:43 2009 us=190186 Warning: route gateway is not reachable on any active network adapters: 192.168.200.5
Sun Apr 26 13:10:43 2009 us=190204 Route addition via IPAPI failed
Sun Apr 26 13:10:43 2009 us=190220 Initialization Sequence Completed With Errors ( see http://openvpn.net/faq.html#dhcpclientserv )

Any suggestions ?

(Actuall you're getting as subnet /30, as IP .6 and as gateway .5).

Read up on http://openvpn.org/ how openVPN in a PKI works.
This is how it is intended.

i think it simply it takes a while to reload the ruleset, i used monitoring.

thanks.

Hi,

Thanks for the reply - things are certainly different in regards to achieving this using pfSense

I think I have now set this up the correct way , just using the OpenVPN Client settings in the pfSense GUI.

From a remote host connected to the VPN server , I can now ping the pfSense box and a device on the internal network.

Currently there is no 'user mgmt' GUI for OpenVPN in pfSesne.  There have been many requests, and it might be forthcoming in the 2.0 release.  Search around the VPN forum here and you should find something.

http://forum.pfsense.org/index.php/board,39.0.html

Okay!

Some more progress just after posting! Making the previous post made me find a misspelling of:
crt /var/etc/openvpn_client0.cert;

Which should have been

cert /var/etc/openvpn_client0.cert;

Now when I fixed that I get this error instead…

Apr 19 17:00:05 openvpn[9203]: Options error: Unrecognized option or missing parameter(s) in /var/etc/openvpn_client0.conf:33: script-security (2.0.6)
Apr 19 17:00:05 openvpn[9203]: Use –help for more information.

Set this option to push an IP to the client's interface. Expressed as a CIDR range (e.g. 10.5.0.0/16). The first IP in the range will be used as the remote IP of the interface, and the second IP will be used as the local IP of the interface.

In a PKI setup each client connects within its own /30 subnet.
The range you provide in the overall config defines how many such /30 subnets you can have.
ie: If you provide a /24 subnet for all clients there can actually 256/4 = 64 clients be connected at one time.

With the client specific config you can manually define which of these /30 subnet a client will use.

Doesn't matter, just got it working.  I tried using TCP port 80 and it worked (whereas TCP port 443 hasn't).  Funny old thing Open VPN but it does the job!

Wanted to close the loop on this one …
Did a fresh install on both ends and used my hand-coded confs (above) and it worked!

presumably there was something sticking around from the 1.2.x upgrade to 2.0 ...

These confs work but the ones produced from the GUI do not.

Updated - I had the syntax wrong, and didn't include my changes to vars.  This should be complete now.
–-----------------
I've got this working now, using a revoke-full script and some changes to the vars file.  Steps to revoke are:  run 'source ./vars' first, then ./revoke-full username, then post the new keys/crl.pem file to the configuration through the GUI.

Here is the script:

#!/bin/sh # revoke a certificate, regenerate CRL, # and verify revocation CRL="crl.pem" RT="revoke-test.pem" if [ $# -ne 1 ]; then     echo "usage: revoke-full <common-name>";     exit 1 fi if [ "$KEY_DIR" ]; then     cd "$KEY_DIR"     rm -f "$RT"     # set defaults     export KEY_CN=""     export KEY_OU=""     # revoke key and generate a new CRL     $OPENSSL ca -revoke "$1.crt" -config "$KEY_CONFIG"     # generate a new CRL -- try to be compatible with     # intermediate PKIs     $OPENSSL ca -gencrl -out "$CRL" -config "$KEY_CONFIG"     if [ -e export-ca.crt ]; then         cat export-ca.crt "$CRL" >"$RT"     else         cat ca.crt "$CRL" >"$RT"     fi fi</common-name>

And the changes to vars:

. . # Changes to allow for revoke-full option setenv KEY_OU "$KEY_ORG" setenv KEY_CN "my.servername.com"  #This should match the servername in your server cert setenv PKCS11_MODULE_PATH "$PKCS11TOOL" setenv PKCS11_PIN "dummy"

Hi Cry,

No it doesn't. The one I've blanked out is the ISP's gateway (which is on pfsense 2's WAN).

Still confused about how the other hosts connected to pfsense2 can reach the pfsense1 subnet

sigh

Got it sorted.

I was using policy based routing which screwed this up

Hello Micha,

Your issue seems very similar to mine.  See the thread below.

http://forum.pfsense.org/index.php/topic,15300.0.html

So far, I have not been able to resolve the issue.  However, I have made a similar discovery.  I had a terminal ping going in a session for 36 hours.  Once the tunnel is up it seems to be very stable.  I too have to attempt multiple times.  However, I did notice that while that one connection was active, I was much more likely to be able to establish a connection from another client on the first try.

I know that this information will not help you as such but it may be wise to watch each other's threads to see where things go.

I have actually decided to purchase a support contract and will be opening a case if I cannot figure this out.  At this point it seems unlikely that I will resolve myself.  I seem to have hit a brick wall due to my level of expertise it seems.

Good luck
Wayne

Try this method for making keys:
http://doc.pfsense.org/index.php/Easyrsa_for_pfSense

after speaking with some guys on irc, i did some tests and the tunnel it's active and the rutes are right, but i still can't access the lan behind the ovpn server :( any hints?

bravo83 may i ask which guide did you specifically follow to enable bridging on pfSense?
Thanks.