No - unfortunately I was not with DD-WRT w/vpn.  However it seems like it may work with OpenWRT.  Others recommend Tomato firmware though it seems like a modified version of Tomato is required with OpenVPN support.  Am surprised no one else has requested this anywhere on the forum.  Have been searching Google and have yet to find a descriptive how-to.

@bachi: Create a LAN firewall rule which blocks access to pfsense wan address and port that openvpn listens. Action: block Protocol: UDP (or tcp if you running openvpn via tcp instead udp) Source: type > lan subnet Destination: type > Wan address Destination port range: openvpn's listening port Hope this helps. It worked. :) Thank you. I should have thought of it.

I tried to change the topology to a subnet one, so I configured the override with a blank tunnel network but with: push "topology subnet"; push "ifconfig 10.7.1.1 255.255.255.0"; in the advanced box, but on the logs I see this: PUSH: Received control message: 'PUSH_REPLY,route-gateway 10.7.0.1,topology subnet,ping 10,ping-restart 60,topology subnet,ifconfig 10.7.1.1 255.255.255.0,ifconfig 10.7.0.3 255.255.0.0' it STILL gets the ifconfig from the server, ignoring the override, so I put the checkbox on the override setting "Server Definitions: Prevent this client from receiving any server-defined client settings." and here is what I get: PUSH: Received control message: 'PUSH_REPLY,topology subnet,ifconfig 10.7.1.1 255.255.255.0,ifconfig 10.7.0.3 255.255.0.0' AGAIN the ifconfig from the server!! why? I told the override to prevent the client from recieving any server settings why it's still pushing the ifconfig and why the client is eating it? the client should take the overridden ifconfig only..

@cmb: Sounds like the return routing of the clients on the remote network is wrong (using something else as their default gateway maybe), or the clients have a firewall locally on them that only permits local subnet traffic. I guess when all else fails look for the obvious answer. Thank you, very much for the help. LOL maybe I banged my head too much. I turned off the firewall on the local machine on the server side and it pinged great. I just have to figure out a printer situation. I think it is a gateway problem. THANKS AGAIN.

1. The portabella boxes from Mushroom networks make a bonded VPN across multiple WANs back to their own network and use that, so your connections use bandwidth from all WANs but appear as a single IP address due to the way the bonding operates. But you run all of your traffic through their network, it doesn't use your WANs directly. I missed that part of your first post here Jim, (thought it was part of your sig).. Perhaps a bounty would be in order, if not just to gauge interest… At least the OP has some things to help him get going and hopefully can make it work.  I always tell anyone to never discount that a local ISP somewhere will get into supporting MLPPP if they only know a little more about it...  You may have to call several but can't hurt to try. :)

Awesome, I feel useful again! :-) Thank you. That was easy enough I should have dug into the code and submitted a patch to say I've actually done dev work :-)

After setting up OpenVPN on a pfSense 2.0 box (which was ridiculously easy using the wizard), I realise that it would be quite simple to set up a test internal OpenVPN on a pfSense box. Like I said above, all you would need are two interfaces. One could be the one you want to VPN to. The other where you will VPN from. Run OpenVPN on the network the VPN traffic will come from, and everything else stays the same. Simple.

Thank you for your reply, it gave me a new route to explore.  Sadly it wasn't as simple as messing with the Cisco config however it turned out to be an even simpler solution (and probably an oversight on my part). I ended up factory resetting several times over.  This cured my problem of the LAN not pinging clients however OPT1 was still a cause for concern. I finally stumbled across the solution more by luck than knowledge.  I added a gateway to the OPT1 interface which corresponded to 10.44.11.1 (My Cisco gateway via the switches).  Then everything started working. One very odd thing I did notice however was that in the course of factory resetting, my VPN connection was automatically pushing the route 10.44.0.0/255.255.0.0 to the clients.  On my last attempt though, the routes weren't being pushed so I also had to add push "route 10.44.0.0 255.255.0.0"; to the VPN config. Thanks again for the advice, I appreciate that getting through the mountain of text is not a 5 second job.

I had the same problem and added advansed options in the following command: push "route 192.168.2.0 255.255.255.0"; Look at this guide or introduction to the whole blog http://blog.stefcho.eu/?p=492

Hi, What you're doing might work, I never tried it but I think it's possible. But maybe you might choose a different path. What are you trying to accomplish? You could create a site-to-site VPN from the pfsense to the remote openvpn server. (the remote openvpn server does not have to be a complete subnet, it can be just 1 host) You could try disabling the rules for a short time to see if your OpenVPN connection stays stable. As for the log files, what do you see in your "system" log at the same time? Something else that looks different? Regards, Kristof.

@jimp: That should work, you might also try "push-reset" in your client config, that should make it stop taking the default gateway from the far side. I will give that a shot and report back!

That worked perfectly, thank you very much for your help! I'm slowly learning pfSense but it's clearly a fantastic Firewall OS.

actually, got it.  had the wrong port specificed in my firewall rules.  this post can be used for people having trouble setting up i guess.

Awesome thanks for the quick reply that worked! Just a note I added in a DHCP IP Range when configuring the OpenVPN server or else my client would not receive an local IP when connecting. Cheers!

The export utility is working fine. I tried it today on a VM with pfsense 2.0.1 amd64 - but without the wizard. Delete the OpenVPN server and try again with the wizard or without the wizard.

You'll need a routing protocol for that to work, and to exchange routes with the MPLS routers (usually via OSPF or BGP).

great ! this fixed the problem. thanks for all your help :)