The fact they're marketing "full tunneling" as some big deal feature, something you've been able to do with pfSense since day 1 OpenVPN was implemented ~7 years ago, really shows how desperate they are for marketing material. Welcome to last decade, Untangle!

Has nothing to do with OpenVPN.  Most likely its your ISP's DHCP Server.  It can be safely blocked and a firewall rule created to surpress it from being logged.

Thanks jimp - I got it working with multiple server endpoints on the one pfsense box. When time allows I'll look into the method you've listed to see if it offers any advantages, and I'll report back here with a comparison.

@jimp: Perhaps, the real fix is of course to not use spaces in CA/cert names to begin with, but either way, it should work with the quotes I thought. I do agree. Not sure why that one cert of mine had a space in it, none of the others do. As a linux user I don't normally use spaces.

I found it… the problem is with the iphone app "Bria" it has an option for using with VPN and by default this was disabled. After enabling it .. everything works like magic :D

@heper: the command line is no longer needed for openvpn if you use pfsense 2.0.x (there is a client exporter package available to create a setup for windows/osx clients) So what do I do just install the open vpn package on my router and follow the promts to connect my laptop? If you could walk me through this that would be great.

Just tried this and the``` push "route 10.0.2.0 255.255.255.0" I can now reach both subnets from my client….. :-)

yes

I'm locking this thread as the promotion (mostly deleted, from users with only 1 post) is getting out of hand, smells fishy and this isn't a place for random consultant advertisements.

Issue is with the DD-wrt NAT, but DD-wrt forum is not the friendliest place on earth :-) So I was wondering if anyone here can give a helping hand with DD-WRT nat….

Hi Heper, You have found my error ! I forget to change de gateway in the firewall rule. Thx

<smacks head="">  Thank you!  Worked perfectly.</smacks>

Just to update. This does work, but there was a client configuration issue - I had –tls-client but this doesn't imply or --pull (--client does), which is required in order to pull routing information from the server. Adding --pull to the client connection command solved the problem.

OK, I think I found the problem - two of them actually, and theese have to be solved before the OpenVPN would work or further troubeshooting can be done. First issue turned out to be CentOS having a builtin firewall ( ::)) Quite embarrased I dind't catch that earlier actually. I've opened the ports now - atleast an easy solve. :P Next issue is way more major. It seems the entire Duo Auth Proxy service is not working. It was built and installed following a procedure from Duo Security (to the letter) and there were no errors - nevertheless, the service says it's running, but it's actually not listening. - There is nothing on the server listening on port 1812. Running "netstat -plant" shows nothing on port 1812 - and telnet'ing to the server on port 1812 - gets me no connection…. So actually the problem with VPN not authenticating is quite understandable, as the RADIUS is not listening for it's requests! :-\ I've sent an supportticket to Duo Security, and I'm awaiting their response.

For that, both sides would have to be in the same subnet, and you'd need to setup OpenVPN for a tap bridge. It's been discussed many times here on the forum, search a bit and you'll find it.

entering the remote an local networks on both ends should do the trick for simple site-2-site vpn's using openvpn. i've done this a dozen times without fail

You're not alone, but using Shared Key is a REALLY BAD IDEA.  Use Certs and create the tunnel that way.  On the openvpn server, allow the clients to contact each other. Another interesting question I have to ask is why Bridge?  It just causes unnecessary traffic.  If you need to Access Windows shares, either call them by IP or better yet, set up a NetBios Server. Bridging has it's uses, but you're eating bandwidth for absolutely no reason. Pre-shared key is a bad idea as there is no real way to transmit the preshared key successfully unless you pre-encrypt the file and that can be done with AES crypt. Remember Deep Packet Inspection will be able to see the key. (If they are monitoring for that).. If they have the key, they can snoop.  Not exactly secure.  Defeats the purpose of VPNs. Lots of VPN and cloud info. :) Read more on my blog about these issues:  http://swimminginthought.com Cheers.