You're the man! I had (in Shimo) Compression set to Disabled, and changed it to "Never" and somehow that fixed it…. go figure :-)

Thanks!

Has anyone else successfully created a bridged setup similar to this one?  We will be needing to create a production setup like this very soon and I wanted to be sure that DHCP and windows file shares could successfully traverse a site to site OpenVPN setup so long as the LAN and TUN interfaces were bridged.

I read a lot of old posts that said there were stability issues - have these been taken care of in recent releases/snapshots?

Also tried with TunnelBrick on Mac OS X.

When looking in the console i see the def gw being set but i can not trace out further then the first hop (10.0.50.1) in my case…

???

Routing tables Internet: Destination        Gateway            Flags    Refs      Use  Netif Expire 0/1                10.0.50.5          UGSc        5      12  tun0 default            192.168.1.254      UGSc      12      113    en1 10.0.50.1/32      10.0.50.5          UGSc        0        0  tun0 10.0.50.5          10.0.50.6          UH          5        0  tun0 [PFSENSE-WAN-IP]/32    192.168.1.254      UGSc        1        0    en1 127                localhost          UCS        0        0    lo0 localhost          localhost          UH          4    3888    lo0 128.0/1            10.0.50.5          UGSc        1        0  tun0

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