So you actually have the roadwarriors on the same openVPN server instance than the site-to-site connection?

I wouldnt do that.
Keep them separate.

One instance in PSK setup for the site-to-site.
One instance in PKI setup for the roadwarriors.

Like this you can use routes for the site-to-site and pushes for the roadwarriors.

If you keep them together it gets nasty with client specific pushes and you'll never have satisfactory client separation.

This was a very recent similar problem:
http://forum.pfsense.org/index.php/topic,16028.0.html

My wife sat here with me, who knows nothing about computers, much less about networking and there she was reading what you said, pointing her finger and saying, "THAT will work!!" I told her that I tried it ALL, except that ofcourse and I expected the same results, but nooooooo, it worked perfectly earning me a crisp, tight cuff across my head with her saying "I told you so!!"

Two days trying to get this working and it's "easy like Sunday morning" for you.

THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU.

here is how i have it setup

i followed the guides that were listed above.

i have a birdge which connects one machine in MA to one machine in IN

the MA is the host server, while the IN is the client

on the IN network I can access all machines in the MA network.

in the MA network I can only access the pfsense machine in IN.

that is where i am having a problem.  Is it a firewall rule issue?

do you need me to list the actual configuration?

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