@GruensFroeschli:

Set the correct mode.
You're in PSK mode, but the fields you are talking about are only used in PKI mode.

Cheers Champ, that did the trick.

Can't believe it was so simple.

anyone?
btw. no matter what i enter/push, tracert command to LAN always ends at 10.0.8.1 at client …

my pfConfig:

mangeshgg: did you solve it? maybe with the help of my poster before?

If you are using the same subnet on both ends you results would be totally unpredictable.  Make sure that each remote network has their IP network.  That will correct your network connectivity issue.

Now if you are determined to use the same network on each end you would have to break that original subnet into pieces.  
Example:  4 subnets(4 networks of 64 addresses)
             That would be a subnet mask of 255.255.255.240(28 bit mask).

I have 7 VPN tunnels running from behind my PF-Sense each has there on unique 255.255.255.0(24 bit mask).  I even have IPsec VPN tunnels for remote VPN connectivity and OpenVPN connectivity.  Each one of those has their on unique subnet.

So in all my small home/business network has 7 active vpn tunnels, 5 internal subnets(business network, storage network(ISCSI), wireless subnet, IPsec VPN tunnels, OpenVPN tunnels)   I am actively using 5 class C (24 bit subnets) and accessing 7 class networks (24 bit networks)

I work very hard to implement as much technology in my home/business network that keeps my network and infrastructure skill strong.  I have gone totally virtual as well no real servers in my farm.  I am using XenServer Enterprise, with OpenFiler (ISCSI target service enable, SMB service enable, and NFS).  So that in a nut shell is what I am doing with my home network.

RC
.

I fixed the problem using the DNS forwarder and make their A record lookup for the mailserver they use to go to our A record.

Not very fail proof but for now it is working.

Bern,

Thanks so much for that post. After trying some of those steps, like trying to reach the remote subnet from the router, I was able to figure out the problem.

The remote machine with the DNS server has two NICs on different networks. The primary NIC, with the default gateway, is not the network that resolves back to the router. I was already aware of this from previous VPN setups, so I already had a persistent static route for my local subnet here back to pfSense router. This is what made me think it couldn't have been this kind of problem, because clients on this end could contact that machine without a problem.

It wasn't until after I tried to use the local router to connect to that machine that I realized that it couldn't, but it could connect to other machines on the remote end (which used the correct gateway by default). What I needed to do was add a persistent static route on that machine that routed the "internal" subnet of the VPN (172.whatever) back to the gateway, and all is well now.

Most users wouldn't run into this but hopefully this helps someone.

Thanks again!

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 ;)