my 192.168.1.* is connect to 192.168.2.* via ipsec I need my openvpn user to connect to either 192.168.1.* or 192.168.2.* but have access to both networks with one vpn connection. What am i doing wrong?

If you are running the OpenVPN Client on a Windows Vista/7 OS then you need to run it  "as administrator" because without windows cannot configure the routes. Further you need to create an allow rule on the openvpn interface on pfsense.

@Darkk: Ok cool. :) I am paranoid about security so wanted to make sure it doesn't have any SSL certificate exploits that I've been hearing about lately. Darkk http://blog.pfsense.org/?p=633

Thanks Jim, I did some quick tests today using an existing site-to-site setup but the results were a little disappointing. At the client end I have a 40mbit WAN connection and a 100mbit connection at the server end. When I redirect the client gateway, I struggle to get over 10mbit on a speedtest.  If I remove the redirect-gateway option, the speedtest correctly reports 38mbit down. This was using no encryption.  The client is running off an Alix box, the server is a quad core Xeon. My initial thoughts are that the client hardware doesn't have enough horsepower to deliver throughput but on the other hand, with no encryption should this really matter? EDIT: Checked CPU using 'top' and the openvpn process peaks at around 40% when using AES-256 and 25% with no encryption  :-\

@focalguy: On Windows 7 you need to start OpenVPN as administrator or it doesn't have the permissions to update the routing table of the PC. That was the problem. Thank you very much. Everything works fine now.

Thanks for all the responses. I think that CMB hit it on the head. Preliminary testing gave me a gut feeling about the smb protocol. I had devised a set of tests to prove that the problem was with that, but never got a chance to implement them. I had to put the project on hold until I finish putting out some other fires….just not sure when that will be....At least now, I have a direction to get started in...

@jimp: there is also a bug in the 2.0 and 2.0.1 upgrade code for OpenVPN - if you did not have compression enabled before, it would show enabled after the upgrade. Disable compression, save, and reconnect. Compression being mismatched isn't enough for the connection to fail, but it will stop traffic from being passed. [Even if you re-create it by hand it would be easy to miss] Thank you!!! Took me several tries to get this stupid traffic pass working.  I togged the compression setting and volia it worked. Now everything is working like it should. Darkk

It sounds like you have 2 options: 1.  Configure a WINS server, add it to your DHCP scope and push it out to your VPN clients.  This way, each connected VPN client will be dynamically mapped to the WINS server and therefore resolvable by name from your LAN. 2.  Go to a bridged solution.

Hello jimp, Thank you very much, Now it works.

@mohanrao83: Dear all pfsense fan's and experts, can u pls give me some idea where i m wrong. because where i m try to ping from A psense to B Pfsense lan ip its pinging also same ping from B to A. but not able to ping lan IP'S sir awaiting for your positive and early response . Thanks Mohan Rao I had the same issue: did you check the personal firewall rules on your destination devices? Normally, they drop any packet coming from a not-trusted network (like the remote network). Try to add the entire remote network in your personal firewalls. Motaro

@cmb: OpenVPN traffic needs rules on the OpenVPN interface, maybe that's what you're missing. LAN rules are for outbound, OpenVPN rules for inbound. I found the issue: it was a firewall blocking any incoming packet from a network outside the trusted one (the local network). Adding the remote network in the personal firewall, OpenVPN works like a charm! Anyway, thank you for your reply!

An access point does require a default gateway if you're managing it from off-subnet.

you just need a port forward on the OpenVPN interface. Probably easier if you have proper routing on your VPS to the internal host on your network so it can just route it in, no need for additional NAT in between.

I dont think this is the problem either.  I had a rule under firewall rules - LAN allowing / to */1194.  All of my outbound traffic rules are defined similar to this on the lan tab (and the other traffic always originates from other local machines).  However, since this OpenVPN server actually sits on the same box as the WAN interface, I thought perhaps it was being dropped.  I tried adding a similar rule under WAN tab and the problem persists. I have logging of packets dropped by default turned on (I assume this checkbox applies to all interfaces) and the logs do not show anything being dropped on 1194. To verify its not a firewall issue, I disabled openvpn server and spun up netcat on udp/1194.  Connected to it from external network and could send text both ways no problem. Tried using TCP too with similar results.  We can see the tcp connection established but immediately reset before trying to auth. Sun Feb 19 14:01:09 2012 WARNING: Make sure you understand the semantics of –tls-remote before using it (see the man page). Sun Feb 19 14:01:09 2012 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables Sun Feb 19 14:01:09 2012 Re-using SSL/TLS context Sun Feb 19 14:01:09 2012 LZO compression initialized Sun Feb 19 14:01:09 2012 Attempting to establish TCP connection with WAN-IP:1194 [nonblock] Sun Feb 19 14:01:10 2012 TCP connection established with WAN-IP:1194 Sun Feb 19 14:01:10 2012 TCPv4_CLIENT link local: [undef] Sun Feb 19 14:01:10 2012 TCPv4_CLIENT link remote: WAN-IP:1194 Sun Feb 19 14:01:10 2012 Connection reset, restarting [0] Sun Feb 19 14:01:10 2012 SIGUSR1[soft,connection-reset] received, process restarting

Solved! Set rule generation to Manual in Firewall > NAT > Outbound Create rule (Interface: MYVPN, Protocol: any, Source: Network 10.0.0.0/24, Destination: Network 10.8.0.1/32) When I type 10.8.0.1 in my laptop's browser, I now see a webpage running on my home server, which was my goal. Thanks for the replies!

In order for broadcasts to traverse the VPN, it will need to be set up as a bridge.

I don't know if this will be of any help to you, I was having the exact same issues when trying to connect to pfsense from a windows openvpn client, I fixed it by changing from tap to tun and changing interface to any. I made the last change so I could test the tunnel from inside the network, it all worked fine, then I switched to my mobile broadband connection and it all worked! I also used the OpenVPN client export utility (you can install from packages) to export the configuration. Good luck.

@pfnewbie12: Hi, new to pf looking for some guidance, I have the following set up, office1 - 10.0.1/24 office2 - 10.20.1/24 office1 and office2 site to site is working using 10.0.9/30, i can traverse both ways i have just setup a road warrior vpn into office2 using 10.0.8/30 and i can access 10.20.1/24 fine.  what do i need to do to access office1 10.0.1/24 when i am on the vpn?  i have checked the firewall logs and allowed the blocked access but it looks like i'm missing a route configuration somewhere? just add on the OpenVPN server on office the following command in the advanced options: push "route 10.0.1.0 255.255.255.0"; Then the OpenVPN server send a static route to the OpenVPN Client (RoadWarrior). But you have to allow the traffic from the OpenVPN RoadWarrior Tunnel network on office2 and office1 - but I am sure you know that.

Your OpenVPN firewall rules are only allowing traffic on port 1194.  Remove that rule under OpenVPN, it's not doing anything productive (unless of course you are trying to establish a tunnel through the tunnel to somewhere inside the local network, then it would be doing something). Add a rule under OpenVPN with *'s across the board, this will allow all traffic through the tunnel.  Then you can tighten down from there if that is something you require.  Get it working first, then lock it down is usually my philosophy.