See this thread:
http://forum.pfsense.org/index.php/topic,18801.msg97227.html

Also if you want to do bridging, you have to do more than add server-bridge to custom options (you actually leave server-bridge out if you want to use an existing DHCP server).

Seems like you would have to create a static route on every other machine for that to work. If a machine on your LAN gets an echo request from some IP (in this case let's a say a remote LAN IP of one of your clients), it will go to the default gateway, which will be pfSense. The traffic won't get to the openVPN server even though that's how it got into the network in the first place.

The problem with this is that if these are mobile clients (and it sounds like they are) you don't know what their remote subnets are going to be, so you can't add static routes for them, either on the clients or on the pfsense machine (not 100% on whether that would work anyway even if you knew the subnets).

I do exactly what you're doing with a few servers (openvpn server on a NAT'd IP) but it works for me because I only want the clients of those servers to have access to the IP of the server, so I haven't actually tried to solve the problem you're having.

Edit: maybe a bridged rather than routed setup would work better; it would also solve the problem of the possibility of overlapping subnets with your road warriors.

pfSense, as of at least 1.2.0, has OpenVPN server built in, and PPTP and IPsec.

Windows has PPTP built in, anything else will require a client to be installed.

Yes, you have to be able to connect to your server - if the network is blocking ports then you can't connect.

I dont think i'll have time to try anything today.. but i'll give that a shot over the weekend!

Thanks!

Change the default port from 1194 to something else should resolve your ISP from blocking your VPN connection

I got it working….had to fenaggle BGP but it is now working, and no route-flapping. WHooo Hoooo! :)

Yeah, you can leave off the "–" part of the command, which is for use when you call it from a command line.

local 1.2.3.4

Just putting that in the custom options should do it (remember to use a semicolon to separate multiple options if you have more). After you save it look in System Logs -> OpenVPN to make sure it's binding to the correct IP.

@joebarnhart:

I have two pfSense boxes and I want to route the openvpn traffic through the OPT1 interface at work to my system at home.  The work box is the "server" my home is the "client".  My home box is set to use the gateway connected to OPT1 at work, but there is no way to tell the server at work to send packets back through the OPT1 interface (instead of WAN).

Create a static route for the IP of the remote end and as gateway your OPT1 gateway.

@joebarnhart:

The static route suggestion leaves me confused.  I can set a default gateway, but it wants a "source" for the packets.  LAN, WAN, etc. don't seem to create a static route that OpenVPN respects or uses.  Nothing seems to affect it since it sits inside the pfSense box and does not seem to pay attention to any routing rules other than from it's openvpn page itself.
'

You're obviously in the wrong place.
You dont have to create a firewall-rule and set a gateway.
You have to create a static route in place i wrote above.

@joebarnhart:

Looking at my logs, I can see the client is connecting to the OPT1 interface at work, but the server at work is responding over its WAN interface.  I could just set "float" in my client, but it misses the point of having a T1 line for VPN use.

I've googled many many messages about this multi-homed madness and openvpn, but have found few who actually claimed to get it working.  99% of the messages never attract even a single response.  This is a big problem for anyone with multiple WANs and there isn't much to go on getting pfSense and openvpn to work.

I think you need to clarify something.
Do you want the pfSense to connect to a server?
In this case you need the static route above.

Do you want clients to connect to the pfSense on the OPT?
In this case you dont need a static route, but you need to set the correct commands in the "Custom options" field on the OpenVPN server page.
AFAIK something along the line of "–local host IP_of_OPTx".
Just to tell the OpenVPN instance that it should listen on the IP of the OPTx instead of the main WAN.

PS: Why do you think that "This is a big problem for anyone with multiple WANs and there isn't much to go on getting pfSense and openvpn to work." ?
It's not a problem of pfSense if you dont know how to handle OpenVPN....

Thanks Havok ill try this month :)

jigp

Problem fixed!

I forgot to add the route on the site B and C. Always add routes for the both directions.

Are the server certificates the same on both openvpn servers?  if different that might becausing you issue.
RC

I'm getting the same error, and so far as I've read and understand, all is config'd properly…  This is with internal CA, until I can get the import of cacert.org's keys to succeed...

Yes this is possible with the "Client-specific configuration" (client specific pushes)
and with OpenVPN firewall rules. (Although the firewalling of OpenVPN is currently quite a hack).

But you missunderstand that you get an IP out of your 3 subnets. This wont happen. You connect from a different subnet to these private LANs.

Yes you can integrate this with active directory.
Read the stickies !
http://forum.pfsense.org/index.php/topic,14946.0.html

I got it!

My god.. all this hair pulling. The problem was that the tap0 interface on machine B did not have an IP address assigned to it. That was it. It works, wonderfully. I am way behind schedule on what I need this for, but with any kind of luck I'll have some time in a few weeks to write up a start to finish guide.

Until then, I'll try to check the thread as often as I can to answer any questions.

What is your IP and gateway for you external network, that is what it should be.  This is a example of the client configuration:

ovpn_client.txt

dev tun
proto udp
remote 63.162.xxx.xxx 1194
ping 10
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert ovpn_client1.crt
key ovpn_client1.key
ns-cert-type server
comp-lzo
pull
verb 3

This from my workstation that I use to connect openvpn with.
RC

It seems like it works somehow, strange but works.  ???
all works on vmware workstation 6.5
                                                      client                                                          server
vm1<–-lan--->vmnet3<----lan--->em1 pfs1 em0<---wan---->vmnet1<---wan---->em0 pfs2 em1<---lan---->vmnet4<---lan---->vm2
192.168.4.21/24            192.168.4.11/24  172.16.1.10/24                      172.16.1.11/24  192.168.4.10/24                192.168.4.20/24
gw 192.168.4.11            tap 192.168.4.2                                                                    tap 192.168.4.1                gw 192.168.4.10

I know that this seems to work on vmware, but I don't think that this would a standard network configuration.  I can see several potential issues, DNS, DHCP.  In most wide area networks you would have a core site with a 21 network or larger.  For your remotes they would some 24 networks or smaller.  It all depends on the size of your company.

So in that case you would extend your network either with secure VPN's, or metnet's, openvpn's.  When I mean extend your business network to 10 sites I would do the following and let's assume that the connections are ipsec or openvpn. We are also using windows 2003/2008 for servers.

Our core network has 200 users and each site has 32 users.  We will have a 510 addresses (23 bit mask) at the core(10.10.10.0- 10.10.11.254),  each site will have 64 addresses.
Core:10.10.10.0

Site 1: 10.10.20.1 - 10.10.20.64      GW:10.10.20.1
Site 2: 10.10.20.65 - 10.10.20.128  GW:10.10.20.66
Site 3: 10.10.20.129 - 10.10.20.193  GW:10.10.20.130
Site 4: 10.10.20.194 - 10.10.20.254  GW:10.10.20.195
Site 5: 10.10.21.1 - 10.10.21.64      GW:10.10.21.1
Site 6: 10.10.21.65 - 10.10.21.128    GW:10.10.21.66
Site 7: 10.10.21.129 - 10.10.21.193  GW:10.10.21.130
Site 8: 10.10.21.194 - 10.10.21.254  GW:10.10.21.195
Site 9: 10.10.22.1 - 10.10.22.64      GW:10.10.22.1
Site 10: 10.10.22.65 - 10.10.22.128  GW:10.10.22.65

So at the core site we would be building a main router so we would reserve the first 32 addresses for addresses for routers and vpn devices.  Then we would build out from there through our firewalls and start building out our tunnels (what every secure method that you would use, your choice).  So at the core we would then be looking at something like the following:

Core: 10.10.10.10 core router managment
Core: 10.10.10.1 Default gateway
Firewall Lan interface: 10.10.10.11
Firewall VPN interface 1:10.10.10.12 (5 vpn tunnels per interface)
Firewall VPN interface 2:10.10.10.13 (5 vpn tunnels per interface)
DHCP Server: 10.10.10.14 contains scopes for core site with all vpn sites
Baracuda: 10.10.10.15  (mail filtering)

We would build our VPN's with rules in place to allow DCHP, DNS services to extend over the vpn tunnels.  Our internet and other services would be provided from the core site.  Remote sites would have a file server and data would be replicated over the vpn tunnels for backup.  The local server would also run DNS services for local names resolution.  Other services could be provided via terminal services or citrix to conserve bandwidth.

I hope this helps.  I know it might draw more questions.
RC