If you set up a PKI you can push routes for the OpenVPN interface. Just find out which IPs the website uses and push these IPs to the clients.

Are you running the Vista client as administrator?  Does it work from any other OS?

I created rule pass with source is any, destination is any and protocol is any too on both interface LAN and WAN. But i don't understand why i can't connect to Pfsense server on port 1194 ???????? ??? ??? ??? ??? ???

Any clue?

Comodo also needs to give you a clients key/certifacte pair. After all they are your CA.

Urr, pass "–script-security 2" to the client on the command line. Also, it's a NOTE, not an error.

@onhel: Take out "client" in the top of your config and replace it with "float" float dev tun proto udp remote xxx.xxx.x.x 1194; ping 10 resolv-retry infinite nobind persist-key persist-tun ca ca.crt cert xxx.crt key xxx.key ns-cert-type server comp-lzo verb 3 pull Thanks!  It worked.

It shouldn't be that complicated… 1: Add the management line from that forum post to your OpenVPN server config 2: Add a firewall rule to allow your workstation to access the management port (if coming in from the WAN) 3: Download an run one of the mangement programs, and point it to your IP/Port setup in step #1 I need to better document the process and add a howto to the wiki, but I don't have an OpenVPN client/server setup at the moment - only peer-to-peer tunnels.

There is some support for filtering OpenVPN in 1.2.3, but it's not very elegant. You can add an OpenVPN tunnel, bring it up, then assign the resulting tunx (likely tun0) interface as an opt interface. You can then enable that opt interface, name it OpenVPN, give it a (bogus?) ip address, and you'll get a tab on the firewall rules where you can control access. What I'm not so sure of is how reliable this is. In my testing, after making changes in OpenVPN which made tun0 leave and come back, I had to edit/save the rules again for things to work as expected. I may have misconfigured something along the way though.

Happy to help somebody who's willing to listen ;)

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.